Servidor subitamente ficando sem entropia

Question

Desde a reinicialização ontem, um dos nossos servidores virtuais (Debian Lenny, virtualizado com o Xen) está constantemente ficando sem entropia, levando a tempos limites, etc., ao tentar se conectar através de protocolos habilitados para SSH / TLS. Existe alguma maneira de verificar qual (is) processo (s) está (ão) consumindo toda a entropia?

Editar:

O que eu tentei:

• Adicionando fontes de entropia adicionais: time_entropyd, rng-tools alimentando o urandom de volta em acessos aleatórios de arquivos pseudo-aleatórios - com cerca de 1 MiB de entropia adicional por segundo, os problemas ainda persistem
• Verificando atividade incomum via lsof, netstat e tcpdump - nada. Nenhuma carga perceptível ou qualquer coisa
• Interrompendo daemons, reiniciando sessões permanentes, reinicializando toda a VM - sem alteração no comportamento

O que no final funcionou:

• Esperando. Desde ontem ao meio-dia, não há mais problemas de conexão. A entropia ainda é um pouco baixa (pico de 128 bytes), mas as sessões TLS / SSH não têm mais nenhum atraso perceptível. Estou lentamente trocando nossos clientes de volta para o TLS (todos os cinco deles!), mas não espero nenhuma alteração no comportamento agora. Todos os clientes agora estão usando o TLS novamente, sem problemas. Realmente, muito estranho.

Answer 1

Com lsof out como uma fonte de utilitário de diagnóstico, configuraria algo usando o trabalho de auditoria? Não há como esgotar o pool de entropia sem abrir /dev/random , portanto, se você fizer auditoria no processamento de abertura /dev/random , o culpado (ou pelo menos o conjunto de candidatos para uma análise mais aprofundada) deve desistir rapidamente.

    

Answer 2

Normalmente, para um servidor voltado para o público que precisa de entropia 'suficiente', eu sugeriria algo como uma chave de entropia, um dispositivo de hardware (USB) adicionando bits aleatórios ao pool de entropia do Linux. Mas você não fala com o mundo exterior.

As máquinas virtuais podem ter um problema com a falta de aleatoriedade externa.

Sua observação "controlador de domínio de backup" adiciona um possível uso de entropia: os domínios do Windows usam números aleatórios em certificados.

    

Answer 3

Talvez lsof (lista de arquivos abertos) possa ajudar. Isso mostra, qual processo atualmente mantém quais arquivos abertos. No seu caso, isso só ajuda quando você pega o (s) seu (s) processo (s) drenando a entropia, se esse processo não mantiver a alça aberta por mais tempo.

$ 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

Apenas uma amostra da minha estação de trabalho. Mas mergulhar mais fundo no lsof pode ajudar.

    

Answer 4

Se não houver uma solução melhor, você pode colocar as armas grandes e envolver globalmente o syscall open () para registrar os processos que tentam abrir / etc / [u] aleatoriamente.

Apenas (tm) escreve uma lib definindo open () que é logs e depois chama a libc original open ().

Dica para isso: man ld.so e /etc/ld.so.preload .

Tivemos algo parecido aqui: link

CAVEAT: Nunca fiz isso sozinho. Pode quebrar o seu sistema desde que todo open () irá rodar através do seu lib. Possivelmente bem em ambientes de depuração ou se você é o R.M. Stallman.