Сервер внезапно исчерпал энтропию

Question

Сервер внезапно исчерпал энтропию

Со вчерашней перезагрузки один из наших виртуальных серверов (Debian Lenny, виртуализированный с Xen) постоянно исчерпывает энтропию, приводя к тайм-аутам и т. Д. При попытке подключения по протоколам с поддержкой SSH / TLS. Есть ли способ проверить, какой процесс (ы) поглощает всю энтропию?

Редактировать:

Что я пробовал:

Добавление дополнительных источников энтропии: time_entropyd, rng-tools возвращают случайный случайный случай, псевдослучайные обращения к файлам - дополнительная энтропия составляет около 1 МБ в секунду, проблемы все еще сохраняются
Проверка на необычную активность с помощью lsof, netstat и tcpdump - ничего. Нет заметной нагрузки или что-то
Остановка демонов, перезапуск постоянных сеансов, перезагрузка всей виртуальной машины - без изменений в поведении

Что в итоге сработало:

Ожидание. Со вчерашнего полудня проблем с подключением больше нет. Энтропия все еще несколько низкая (пик 128 байт), но у сеансов TLS/SSH больше нет заметной задержки. Я медленно переключаю наших клиентов обратно на TLS (все пять!), Но сейчас я не ожидаю каких-либо изменений в поведении. Все клиенты теперь используют TLS снова, без проблем. Действительно, действительно странно.

5

linux tls entropy-pool

Источник

Creshal 09 июл '12 в 13:40

4 ответа

Другие вопросы по тегам linux tls entropy-pool

womble 09 июл '12 в 14:53 2012-07-09 14:53 · Answer 1 · 2012-07-09 14:53

С lsof как источник диагностической утилиты, будет ли что-то настраиваться с помощью аудита? Нет никакого способа истощить пул энтропии без открытия /dev/random, так что если вы проверяете на открытие обработки /dev/randomвиновник (или хотя бы набор кандидатов для дальнейшего экзамена) должен уйти довольно быстро.

Koos van den Hout 25 сен '12 в 12:21 2012-09-25 12:21 · Answer 2 · 2012-09-25 12:21

Обычно для общедоступного сервера, которому нужна "достаточная" энтропия, я бы предложил что-то вроде энтропийного ключа, аппаратного устройства (USB), добавляющего случайные биты в пул энтропии linux. Но вы не говорите с внешним миром.

Виртуальные машины могут иметь проблемы с отсутствием внешней случайности.

Ваше замечание "резервный контроллер домена" добавляет возможность использования энтропии: домены Windows используют случайные числа в сертификатах.

Michuelnik 09 июл '12 в 14:06 2012-07-09 14:06 · Answer 3 · 2012-07-09 14:06

Возможно, lsof (список открытых файлов) может помочь. Это показывает, какой процесс в настоящее время содержит какие файлы открыты. В вашем случае это помогает, только когда вы улавливаете процесс (ы), истощающий энтропию, если этот процесс не держит ручку открытой дольше.

$ lsof /dev/urandom
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
xfce4-ses  1787   to   15r   CHR    1,9      0t0 8199 /dev/urandom
applet.py  1907   to    9r   CHR    1,9      0t0 8199 /dev/urandom
scp-dbus-  5028   to   10r   CHR    1,9      0t0 8199 /dev/urandom
firefox    6603   to   23r   CHR    1,9      0t0 8199 /dev/urandom
thunderbi 12218   to   23r   CHR    1,9      0t0 8199 /dev/urandom

Просто образец с моей рабочей станции. Но погружение глубже в lsof может помочь.

Michuelnik 10 июл '12 в 18:15 2012-07-10 18:15 · Answer 4 · 2012-07-10 18:15

Если нет лучшего решения, вы можете ввести большие инструменты и глобально обернуть системный вызов open() для регистрации процессов, которые пытаются открыть /etc/[u] случайным образом.

Просто (tm) напишите lib, определяющую open(), которая регистрирует журналы, а затем вызывает исходную libc open().

Подсказка для этого: man ld.so и /etc/ld.so.preload.

У нас было нечто подобное здесь: https://stackoverflow.com/questions/9614184/how-to-trace-per-file-io-operations-in-linux

ПРЕДУПРЕЖДЕНИЕ: никогда не делал этого сам. Может сломать вашу систему, так как каждый open() будет проходить через вашу библиотеку. Возможно, это нормально в среде отладки или если вы RM Stallman.