После вчерашней перезагрузки на одном из наших виртуальных серверов (Debian Lenny, виртуализированный с помощью Xen) постоянно заканчивается энтропия, что приводит к тайм-аутам и т. Д. При попытке подключения по протоколам с поддержкой SSH / TLS. Есть ли способ проверить, какие процессы поглощают всю энтропию?
Редактировать:
Что пробовал:
Что в итоге сработало:
С участием lsof в качестве источника диагностической утилиты, будет ли установка чего-либо с помощью аудита работать? Невозможно исчерпать пул энтропии без открытия /dev/random, поэтому если вы проведете аудит обработки открытия /dev/random, виновник (или, по крайней мере, набор кандидатов для дальнейшего экзамена) должен довольно быстро выбыть.
Обычно для общедоступного сервера, нуждающегося в «достаточной» энтропии, я бы предложил что-то вроде энтропийного ключа, аппаратного устройства (USB), добавляющего случайные биты в пул энтропии Linux. Но вы не разговариваете с внешним миром.
У виртуальных машин может быть проблема с отсутствием внешней случайности.
Ваше замечание «резервный контроллер домена» действительно добавляет возможное использование энтропии: домены Windows действительно используют случайные числа в сертификатах.
Возможно 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 может помочь.
Если нет лучшего решения, вы можете использовать большие пушки и глобально обернуть системный вызов open () для регистрации процессов, которые пытаются открыть / etc / [u] random.
Просто (tm) напишите библиотеку, определяющую open (), которая ведет журналы, а затем вызывает исходную libc open ().
Подсказка для этого: мужчина ld.so и /etc/ld.so.preload.
У нас было нечто подобное: https://stackoverflow.com/questions/9614184/how-to-trace-per-file-io-operations-in-linux
CAVEAT: Сам никогда не делал этого. Может сломать вашу систему, так как каждый open () будет проходить через вашу библиотеку. Возможно, все в порядке в среде отладки или если вы R.M. Столмен.