fork bombs são códigos maliciosos, executados no sistema, que causam a negação do serviço ou denial of service.
Sua efeito é devastador, por consumir rapidamente os recursos de armazenamento na memória e/ou de processamento de informações, causando uma crescente deterioração do sistema.
O resultado de uma fork bomb é, quase sempre, um desktop ou servidor totalmente inoperante — neste caso, tudo o que resta a fazer é reiniciar a máquina, sob o risco de perder dados importantes e corromper arquivos fundamentais do sistema.
Veja o vídeo, ao final do artigo, demonstrativo da execução de uma fork bomb no meu sistema.
As fork bombs não são defeitos ou falhas na arquitetura do seu sistema operacional. Na verdade, cabe ao administrador configurar o sistema para que os processos não consumam todos os seus recursos.
Neste artigo, vamos demonstrar como é possível, com alguns procedimentos simples, limitar os recursos disponíveis aos usuários, que podem prevenir o uso malicioso do sistema.
Estabeleça limites para seus usuários com nproc
Uma fork bomb funciona criando uma quantidade exponencial e infindável de processos (muito rapidamente), com o objetivo de saturar o espaço disponível para outros processos — o que inclui os do próprio sistema operacional.
Uma fork bomb mata o seu sistema por inanição de recursos
Configure o arquivo /etc/security/limits.conf
para que este imponha limites aos usuários e processos.
Abra o arquivo, com privilégios administrativos e altere a quantidade de processos que usuários e grupos de usuários podem abrir simultaneamente.
Por exemplo, para estabelecer a quantidade máxima de processos do usuário ‘salsicha’ para 300, adicione o seguinte código:
salsicha hard nproc 300
Para limitar a quantidade de processos dos usuários pertencentes ao grupo ‘scoobydoo’ em 50, use o seguinte exemplo:
@scoobydoo hard nproc 50
Com esta configuração, o usuário ‘salsicha’ ou qualquer outro pertencente ao grupo ‘scoobydoo’ ficará impedido de derrubar o sistema com uma fork bomb.
Se tentarem, o sistema ficará indisponível apenas para eles — os usuários e grupos em questão.
Outros usuários no sistema não serão afetados.
É necessário reiniciar o sistema, depois de alterar o arquivo de configuração.
Como limitar a quantidade de processos em uma sessão com ulimit
Um método mais imediato de limitar o número de processos por sessão consiste no uso do comando ulimit.
ulimit -u 841
Conforme o resultado acima, o meu usuário está limitado a abrir até 841 processos simultaneamente.
Tome cuidado ao reduzir o número de processos. Um valor muito baixo pode simplesmente inviabilizar o uso.
Para reduzir o número máximo de processos abertos simultâneos para esta sessão para 30, faça assim:
ulimit -u 30
Se você tentar rodar uma fork bomb agora, ela irá ser executada, mas irá emitir um monte de mensagens:
-bash: fork: retry: recurso temporariamente indisponível
-bash: fork: retry: Não há processos filhos
Isto significa que seu sistema não permitiu que a bomba abrisse mais processos além do limite.
No final, a bomba é finalizada pelo sistema. Veja a imagem:
Leve em conta que cada sistema é único.
Se você usa um desktop KDE ou Gnome, precisa imaginar que eles tendem a abrir uma grande quantidade de processos para poder funcionar.
Demonstração real de uma fork bomb em execução
No vídeo abaixo, fica demonstrada execução de uma fork bomb sob controle do ulimit — pouco tempo depois de começar a agir, ela é neutralizada pelo sistema.
Eu usei uma máquina virtual, rodando o Debian 8.1 Jessie, para realizar a demonstração.
Se quiser saber como por no ar a sua própria máquina virtual, leia o artigo Como pôr no ar uma máquina virtual Debian, em 5 minutos.
Achou interessante? Compartilhe! 🙂
3 replies on “Como se prevenir de fork bombs no Linux, usando nproc e ulimit”
Excelente artigo. Eu tive problema há um tempo com o Java quando executando depuração de uma aplicação no Netbeans. O processo consumia muita memória e acabava travando o SO. Será que com o ulimit eu consigo estabelecer um limite de consumo de memória para matar o processo automaticamente? []’s.
Essa é a idéia! 😉
Há outros meios, talvez mais eficientes, para executar código “não confiável” com mais segurança — usar o Docker, usar uma máquina virtual etc.
[…] a quantidade máxima de processos abertos simultaneamente por usuário (max user processes), pode prevenir que código malicioso de uma fork bomb, por exemplo, replique processos indefinidamente até derrubar o seu sistema. Para aumentar a […]