Um dia depois da inundação

cristofe

Nesse artigo entenderemos uma das grandes dificuldades dos administradores de rede de computadores, que são as tentativas de acessos indevidos ou ataques investidos na rede. O interesse aqui é mostrar que a melhor defesa se faz quando se conhece a natureza do ataque.

[ Hits: 27.476 ]

Por: cristofe coelho lopes da rocha em 14/12/2008

2 0

Denuncie Favoritos Indicar Impressora

Defesa baseada no conhecimento

Bem, conforme havíamos combinado, agora temos que achar uma maneira de resolver este problema em nossos servidores. Há uma solução que é bastante utilizada, mas ela não é tão eficaz. É escrever em seu script firewall a seguinte regra contra ataques Dos:

# iptables -A FORWARD -p tcp -syn -m limit -limit 1/s -j accept

Porém existe uma outra maneira de fazer com que seu Kernel seja mais seguro. É o chamado tyne de Kernel apesar de ser pouco falado é muito eficaz e consiste em setar os arquivos do /proc utilizando o sysctl.

Os arquivos que modificaremos as variáveis se encontram dentro do diretório /proc/sys/net/ipv4/, onde os mesmos são responsáveis pelas filtragens de informações de entrada e as que passam pelo host.

O interessante é que os efeitos das configurações das variáveis dos arquivos dentro do diretório /proc são instantâneas, a partir do momento que o arquivo é salvo, ou seja, em real time, já que o /proc é um diretório virtual. Essa é uma das grandes vantagens de configurar o kernel através dos parâmetros do diretório /proc.

Coloque as seguintes linhas dentro do arquivo sysctl.conf:

net.ipv4ip_forward= 1
net.ipv4ip_default_ttl=255
net.ipv4.icmp_echo_ignore_broadcast=1
net.ipv4.icmp_ratelimit=150
net.ipv4.icmp_ratemask=6457
kernel.printk=0

net.ipv4..tcp_syscookies=1

Cabe aqui neste momento pesquisa para fortalecer o conhecimento de manipulação do Kernel a partir do /proc.

Espero ter colaborado com conhecimento de todos um abraco e até o próximo.

Bibliografia

Segurança de redes e sistemas. Escola Superior de redes, 2008;
Dominando Firewall com Iptables. Neto, Urubatan. Editora Ciência Moderna,2004;
Exploracão de redes TCP/IP 2 edição atualização.Editora Alta-books. Melo, Sandro, 2006;
BS7799 da tática a prática em servidores Linux. Editora Alta-books. Melo, Sandro, 2006.

Página anterior

Páginas do artigo

1. Ataque dinâmico com HPING
2. Defesa baseada no conhecimento

Outros artigos deste autor

Melhorando o nível de segurança com chflags

Varredura bruta com NMAP

Esgotando os recursos

Alta disponibilidade com CARP

Redes definidas por Software com Mininet e POX - Criando meu primeiro Controlador

Leitura recomendada

O que é ForceCommand

Código Aberto já não é uma questão de gosto

Utilização Segura do SSH

Segurança no Linux: Antivírus, Firewall, Wine - Mitos e Verdades

Pen-Test com ênfase em WLAN

Comentários

[1] Comentário enviado por calaff2 em 14/12/2008 - 22:15h

Muito bom cara ! gostei se tiver outros sistema para eu testar a falha de segurança e tiver como me mandar eu fico grato.

Att: Idalmo Junior
calaff2@hotmail.com

0 0

[2] Comentário enviado por info24hs em 15/12/2008 - 08:45h

Boa dica..

0 0

[3] Comentário enviado por elgio em 15/12/2008 - 09:45h

Chegaste a ler http://www.vivaolinux.com.br/artigo/Iptables-protege-contra-SYN-FLOOD/

Tem também uma RFC lançada em Agosto de 2007 que trata especificamente de Syn Flood: http://rfc-editor.org/rfc/rfc4987.txt

O fato é que este tipo de ataque (Syn Flood) não se pode evitar com regras de firewall. Tentar só agrava o problema, tornando a negação de serviço mais fácil.

Basicamente um atacante para realizar a negação por syn flood precisa (a) falsificar o seu Ip de origem e (b) ter condições de gerar muitos, mas muitos syn MESMO (dado a quantidade de memória que os servidores tem hoje).

O item (b) é hoje muito difícil de se obter com uma única máquina atacando, o que requer que o atacante tenha diversas máquinas escravinhas a seu comando (Negação de serviço distribuída).

Com regra de firewall limitando os Syns à taxa de 1 por segundo, esta tarefa ficou HIPER fácil: o atacante precisa agora apenas manter uma taxa igual ou maior que 1/s para derrubar o servidor. Sim, porque o segundo SYN no mesmo segundo pode ser de um cliente legítimo que será DROPADO. Agora é teu firewall quem tira o serviço do ar!!!

Por isto que sou crítico a esta falsa proteção e tenho me manifestado sobre isto sempre que alguém prega o firewall com solução para Syn flood.

Esta palestra: http://gravatai.ulbra.tche.br/tchelinux2008/Elgio-Negacao_de_servico_e_formas_de_defesa.pdf ilustra o ataque de syn flood e as formas de defesa (na verdade A FORMA: syn cookie)

0 0

[4] Comentário enviado por elgio em 15/12/2008 - 10:04h

esta regra de iptables torna ainda mais fácil derrubar o servidor. BARBADA!

0 0

[5] Comentário enviado por cristofe em 15/12/2008 - 11:53h

Caro Colega elgio,
Realmente a regra do IPTABLES nao é eficaz, contudo em seguida foi colocada uma proposta de solucao "NAO DEFINITIVA" que é melhore, este é o foco do artigo mostrar como se faz um ataque e qual seria a melhor solucao no caso o syn cookie e nao com IPTABLES. Nao sei se me fiz entender?

Abraco,

Cristofe Rocha

0 0

[6] Comentário enviado por elgio em 15/12/2008 - 12:01h

O problema é que a regra de iptables colocada está longe de ser uma solução. Ela agrava o problema.

0 0

[7] Comentário enviado por cristofe em 15/12/2008 - 12:19h

A solucao com IPTABLES foi citada no artigo como nao eficaz. Obrigado por ter editado sua postagem. Ficou mais ética agora.
E agradeco pela crítica agora construtiva.
Cristofe Rocha

0 0

[8] Comentário enviado por vagschubert em 15/12/2008 - 20:09h

Olá Cristofe,

De fato, como vc afirma no Artigo, a regra do IPTABLES não é a mais indicada, mas eu particularmente gostei e aprovei segunda solução, onde se altera o arquivo sysctl.conf.

É realmente uma ótima postagem.

Parabéns!!

0 0

[9] Comentário enviado por julianjedi em 15/12/2008 - 22:23h

Muito Interessante ... Bem didático mesmo ...

Parabéns

0 0

[10] Comentário enviado por lara2rocha em 16/12/2008 - 11:37h

Parabéns bem didático mesmo. Fazer Tyne de Kernel é a melhor solucao quando se fala de syn flood.
Muito Bom. Será que vc tem mais alguns ??? hein.
Abraco

0 0

[11] Comentário enviado por gilroque em 16/12/2008 - 13:18h

muito bom seu artigo, está de parabéns !!!! Abre os olhos de um Administrador de rede no que se diz respeito a implentar e identificar meios de segurança....

0 0

[12] Comentário enviado por reyfernandes em 16/12/2008 - 17:33h

Acho que o artigo poderia ser mais profundo, explicando cada um dos parâmetros do kernel alterados. Será que todos eles são realmente necessários para se proteger de syn-flood?
Fora alguns problemas de redação, parabéns pela iniciativa de compartilhar o conhecimento!

0 0

[13] Comentário enviado por cristofe em 17/12/2008 - 11:51h

Como foi falado no início do artigo

Nesse artigo entenderemos uma das grandes dificuldades dos administradores de rede de computadores, que são as TENTATIVAS DE ACESSO indevidos ou ataques investidos na rede. O interesse aqui é mostrar que a melhor defesa se faz quando se conhece a NATUREZA DO ATAQUE.
Fico te devendo parau m outro momento.
Abraco,
Por: cristofe coelho lopes da rocha

0 0

[14] Comentário enviado por cristofe em 17/12/2008 - 11:52h

<<< ERRATA >>>

net.ipv4..tcp_syncookies=1
Esta é a linha responsável por SYN FLOOD

Por: cristofe coelho lopes da rocha

0 0

[15] Comentário enviado por removido em 17/12/2008 - 15:39h

Ótimo artigo,muito bom mesmo

0 0

[16] Comentário enviado por isornberger em 21/10/2012 - 23:18h

Muito interessante, as redes são alvo de ataques, e ultimamente esse tipo tem sido constante ( por exemplo site da Petrobrás, IBGE, Detran entre outro do governo). E é necessário que a equipe de segurança busque a proteção de rede e faça a defesa conhecendo cada tipo de ataque e defendendo da maneira correta, para evitar futuras complicações.

0 0