Снижение нагрузки на процессорные ресурсы при использовании хелпера Kerberos-аутентификации (negotiate_kerberos_auth) для прокси-сервера Squid 3

imageПри начале эксплуатации обновлённой версии Squid можно, как и в прошлый раз, столкнуться с проблемой высокой утилизации процессорных ресурсов прокси-сервера, вызванной процессами хелпера Kerberos-аутентификации — negotiate_kerberos_auth. При изучении данной проблемы, с удивлением для себя обнаружил, что её решение всё это время было у меня в буквальном смысле слова “под носом”.

В документации к хелперу можно найти такую информацию:

Kerberos can keep a replay cache to detect the reuse of Kerberos tickets (usually only possible in a 5 minute window). If squid is under high load with Negotiate(Kerberos) proxy authentication requests the replay cache checks can create high CPU load. If the environment does not require high security the replay cache check can be disabled for MIT based Kerberos implementations by adding the following to the startup script:

KRB5RCACHETYPE=none export KRB5RCACHETYPE

Получается, что по умолчанию хелпер использует replayкэш как своего рода защиту от replayатак. То есть если есть атакующий, который записывает трафик от клиента и потом воспроизводит ответы клиента, чтобы успешно пройти аутентификацию на стороне сервера. Однако есть мнение, что использование replay-кэша не идеальная защита, так как если атакующий встанет между клиентом и сервером, и будет играть роль сервера для клиента и клиента для сервера, то этот кэш не спасёт. К тому же подразумевается, что аутентификация используется внутри локальной сети, где уровень риска подобного рода атак не велик.

Учитывая также замечания в разделе Performance issues документа MIT Kerberos Documentation- replay cache использование replay-кэша на системах с большой нагрузкой (большое количество пользователей выполняющих аутентификацию) может привести к существенным нагрузкам на дисковую подсистему. Наряду с этим, как показывает практика, при использовании конфигурации хелпера “по умолчанию” ощутимо нагружаются и процессорные ресурсы.

С учётом вышеизложенных аргументов мы добавили в файл /etc/default/squid3 (создание такого файла упоминалось ранее) инструкцию, отключающую использование replay-кэша. В конечном итоге в нашем случае файл принял следующий вид:

KRB5_KTNAME=/etc/squid3/PROXY.keytab
export KRB5_KTNAME
KRB5RCACHETYPE=none
export KRB5RCACHETYPE

После этих изменений необходимо перезапустить Squid:

sudo service squid3 restart

В результате процессорная нагрузка на нашем прокси-сервере ощутимо упадёт, что само по себе сделает его работу более стабильной.

Всего комментариев: 7 Комментировать

  1. Андрей /

    Алексей, kerberos, конечно, хорошо — в последних версиях, кстати, похоже, беда с ним исправлена — во всяком случае, той жуткой загрузки нет. Но вопрос в другом — а стоит ли так заморачиваться с kerberos, если NTLM работает как часы? У kerberos есть один момент, который мне жутко не нравится — привязка к именам — NTLM ее лишен. Пример простой — два сквида — основной/резервный на разных линуксах — в случае возникновения проблем с основным перекинуться на резервный — секундное дело (сменить адреса), а с kerberos такая вещь не прокатит. В чем такой интерес именно к kerberos?

    1. Алексей Максимов / Автор записи

      а с kerberos такая вещь не прокатит

      Отнюдь. Просто вместо того, чтобы использовать для Kerberos-аутентификации учётные записи прокси-серверов как доменных компьютеров, можно использовать на двух (и более) серверах одну и туже выделенную сервисную учётную запись доменного пользователя. Об этом писалось ранее. Объяснять преимущества Kerberos перед NTLM смысла думаю особого нет. Это, грубо говоря, тоже самое, что пользоваться Telnet в то время, как есть возможность использовать SSH.

      1. Андрей /

        Насчет одной сервисной — упустил. Но опять же с kerberos возникает гораздо больше проблем, а что на выходе? На NTLM (через самбу) сквид (на чистой виртуалке) заливается одним скриптом. Секьюрность? Ну тут сравнение с telnet и ssh на мой взгляд, не совсем корректно. Вопрос не праздный — Алексей, но вот не вижу я никакого смысла так упираться в этот самый керберос сейчас (что совсем не означает иметь его, как запасной вариант на тот случай, если MS отрубит NTLM).

  2. Сергей /

    На сколько сильно падает нагрузка на процессор при отключении replay-кеша ?

    1. Алексей Максимов / Автор записи

      Существенно. Приблизительно с 70-80% на всех ядрах до 10-15%. Самое главное то, что теперь нет 100% пиков, когда кратковременно прокси даже перестаёт отвечать клиентам.

      1. Сергей /

        Спасибо, это действительно существенное снижение. Надо проверить как у меня это будет работать. Еще раз огромное спасибо.

  3. Юмашка из Простоквашки /

    Спасибо тебе, мил человек. А то я тут запустил прокси на новом микро-сервере и чуть не упал, когда обнаружилось, что на двух ядрах loadaverage ниже 3.5 не опускался вообще в течение дня.

    А про «NTLM как часы»… Пока я сидел на старом сервере на Squid2, да все работало как часы. Но с переходом на Squid3 у меня появился список URLов на которых при использовании NTLM аутентификации в Firefox обязательно вылетал диалог с запросом логина и пароля для прокси. При этом в Хроме и IE все действительно работало как часы. В чем причина, пока не знаю, баг репорт пока не писал: не понятно на тему чего писать, нужно еще поисследовать, что сложно, потому что у них всех был https и трафик просто так не посмотришь.

Добавить комментарий