CTRL+c

Nosso bom e velho CTRL+c talvez não funcionará. Ao executarmos o CTRL+c, enviaremos o sinal KILL apenas para alguns dos processos, não para todos. Com o passar do tempo, nos testes realizados aqui, perdemos o teclado, então CTRL+c está fora de questão. Ele funciona quando conseguimos no terminal enviar o sinal KILL para o processo pai destes scripts, ou seja, quando na linha de execução das réplicas, não utilizamos o caractere "&".

/etc/sysctl.conf

Podemos usar o sysctl.conf para limitar a atuação destes scripts, diminuindo os valores das seguintes variáveis do kernel:

• kernel.pid_max
• fs.file-nr
• fs.file-max
• fs.nr_open

O que considero problemático aqui é que estes parâmetros são globais e em geral não podemos alterá-los por conta de um único usuário.

lsof

Pode-se usar o lsof (man lsof) para encontrarmos o processo pai destes scripts. Fazemos:

lsof +D /home/user/virus/

Mas a replicação destes scripts é rápida e é provável que quando detectada a ação já não seja mais possível utilizar o lsof.

/etc/security/limits.conf

O arquivo /etc/security/limits.conf define os limites dos usuários do sistema. Este é uma boa opção para se contornar o problema. A estrutura deste arquivo é:

<domain>        <type>  <item>  <value>

Onde:

• <domain> pode ser um usuário, um grupo, * ou %;
• <type> pode ser soft ou hard.

Os itens que nos interessam aqui são o nofile e o nproc, que representam, respectivamente, o número máximo de arquivos abertos e o número máximo de processos do domínio em questão.

Uma configuração para evitar que estes scripts gerem um ataque DOS seria:


Em seguida, como root:

# ulimit -n

Os ajustes aqui devem ser feitos de acordo com as necessidades de cada serviço, sendo interessante uma avaliação minuciosa de cada caso.

Uma melhor seria usar os grupos de usuários como o domínio no limits.conf.

O problema aqui é que, se estes scripts são executados, temos um desperdício de recursos que em geral queremos evitar. Isto pode ser particularmente grave se a proporção do ataque for grande. Neste caso outra medida que não a configuração dos limites deve ser tomada.

Em muitas distribuições estes limites não estão configurados. Então é preciso estar atento a este tipo de questão de forma a evitarmos inconvenientes. Uma configuração simples, mas bastante eficiente, que pode economizar muita dor de cabeça para os administradores Linux.

Um outro fato sobre os limites é que eles apenas impedem que novos processos e arquivos sejam criados de uma maneira que não nos interessa muito aqui. É como se, quando o sistema atinja os limites, um novo processo seja apenas impedido de ser criado. Mas o script continua criando novos processos, e esta briga persiste indeterminadamente. Então, os limites ajudam mas não resolvem o problema.

kill

Combinado com o uso dos limites, uma solução para este problema seria utilizar o comando kill num processo chamado "-bash". Este processo é o pai de todos os processos bash. Matando ele, matamos todos os outros processos derivados dele. Então, precisamos fazer, como root:

# kill -9 `ps -ef | grep <usuário> | grep -e "-bash" | awk '{print $2}'`

Onde usuário é o usuário que executou o script. Podem haver processos remanescentes, o que pode ser resolvido utilizando-se uma estrutura de repetição:

# for i in `ps -ef | grep <usuário> | awk '{print $2}'`; do kill -9 ${i}; done

Se usarmos os limites, este usuário provavelmente ficará impedido de utilizar a máquina em questão.

Comentários

Vimos como é possível se executar um ataque DoS em uma máquina Linux mal configurada, partindo de um script bastante simples. Particularmente não considero a solução apresentada boa. Embora ela resolva o problema, pelo menos nos casos avaliados aqui, ela deixa a desejar, pois é necessária a intervenção direta do administrador. Levando em conta o fato de que um administrador não fica 100% do seu tempo monitorando os processos, isto introduz uma complicação a mais ao processo de administração. Outro ponto de destaque são os limites. Eles são muitas vezes deixados de lado e esta negligência pode vir a comprometer o sistema, como vimos aqui.

Outras soluções e comentários são sempre bem vindas.