Implementando um kernel GNU/Linux mais seguro

Nesse artigo iremos mostrar como é possível implementar pequenas filtragens através da compilação do kernel GNU/Linux utilizando o pseudo-sistema de arquivos /proc sem ter um conhecimento avançado de ferramentas específicas de firewalling, como o Netfilter/Iptables, Ipchains, Ipfwadm entre outras.

[ Hits: 65.469 ]

Por: Wagner M Queiroz em 03/02/2005


Implementado segurança no kernel



Agora que já sabemos como mudar as variáveis de alguns parâmetros do kernel, vamos implementar as filtragens para nos proteger contra algumas técnicas de ataque utilizando os arquivos dentro do diretório /proc/sys/net/ipv4/. Lembrando que o IP (Internet Protocol) versão 4 é ainda o protocolo mais usado em redes pelos mais diversos sistemas operacionais existentes hoje. Esse protocolo será trocado pela versão 6 daqui a algum tempo, porém continua sendo o protocolo padrão na Internet. A versão abordada nesse artigo será a 4.

Somente alguns arquivos encontrados dentro do diretório /proc/sys/net/ipv4/ será explicado conforme o comportamento da variável 1 (um) ou 0 (zero).

4.1) /proc/sys/net/ipv4/icmp_echo_ignore_all


Habilitando essa variável, ou seja, colocando 1 (um) como seu valor, faz com que o GNU/Linux ignore todas as mensagens ICMP (Internet Control Message Protocol) echo request, retornando a mensagem ICMP time exceeded para o requisitante, ou seja, a máquina com o bit ativo 1 (um) nesse parâmetro fará com que nenhuma interface de rede (ETH*) instalada e configurada nesse computador aceite comandos "pings". Por padrão, esse parâmetro é desativado quando o kernel é iniciado. Ativar esse serviço há vantagens e desvantagens. A vantagem é que o computador ficará imune a ataques do tipo Denial of Service (DoS) como Ping of Death (envio de mensagens ICMP echo request maiores que 65535 bytes para a máquina alvo), SSPing (envio de mensagens ICMP grandes altamente fragmentados) [7], mapeamentos da rede, hosts, portas, footprinting (coleta de informações do alvo) entre outras técnicas. A desvantagem é que com icmp_echo_ignore_all ativo pode prejudicar algum serviço que utilize o protocolo ICMP e outra desvantagem é que administrador da rede, não poderá mais utilizar comando ping para saber se o esse computador está realmente ativo ou não na rede.

4.2) /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts


O protocolo ICMP suporta tráfego broadcast, isto quer dizer que quando são enviadas mensagens ICMP echo request direcionadas a endereços broadcast e multicast de uma rede, todos os hosts que estiverem ativos responderão a esse estímulo, com isso é possível fazer um mapeamento em uma rede utilizando esse recurso do ICMP.

Um ataque bastante conhecido que utiliza de forma maliciosa essa característica do protocolo ICMP é a técnica de Smurf Attack, que seria o envio de pacotes ICMP direcionados ao broadcast de uma rede, onde o atacante possui um endereço forjado da vitima, com a intenção de ocasionar um possível DoS na máquina alvo. A máquina vítima irá receber todas as respostas vindas das máquinas ativas pertencentes a rede que o atacante enviou as mensagens ICMP, com isso ocasionando sobrecarga na máquina alvo. A rede utilizada nesse ataque também estará prejudicada, pois o seu desempenho cairá muito devido ao fato de que muitas mensagens ICMP estarão trafegando pela rede [8].

Por padrão esse parâmetro está desabilitado. Devemos habilitá-lo para que os tipos de ataques descritos acima sejam contidos.

4.3) /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses


Essa opção também vem desabilitada quando o kernel é iniciado. Algumas vezes um roteador envia em broadcast frames contendo respostas inválidas e como resultado, todos esses eventos são "logados" pelo kernel. Para evitar o armazenamento desnecessário de logs, é aconselhado habilitar esse parâmetro para que o kernel ignore essas mensagens inválidas [9]. Essa opção não evita ataques, porém ela é importante, pois o computador não irá perder performance por não ter que armazenar frames falsos.

4.4) /proc/sys/net/ipv4/ip_forward


Outro parâmetro que vem desabilitado ao início do kernel. Essa opção é muito utilizada em scripts de firewall Iptables, onde o mesmo computador que faz o papel de firewall também faz a função de gateway. Esse computador dispõe de mais de uma placa de rede, os pacotes são encaminhados de uma interface de rede para outra e devido a isso, esse parâmetro deve ser habilitado para que ocorra o NAT (Network Address Translation).

Se o computador possuir somente uma interface de rede, não há a necessidade desse parâmetro estar habilitado.

4.5) /proc/sys/net/ipv4/tcp_syncookies


É aconselhado que habilite esta variável para evitar ataques do tipo de ataque SynFlood, que seria o envio de requisições TCP com o flag SYN habilitado, onde o lado requisitado envia ao requisitante a resposta com os flags SYN e ACK setados esperando por um SYN do requisitante. O requisitante por sua vez ao invés de enviar o ACK para completar o estabelecimento da conexão (Three way handshake), é enviado mais requisições TCP com o flag SYN ativo, com isso a máquina requisitada recebe várias solicitações de pedido de conexão acarretando o uso de memória e a perca de performance, podendo deixar máquina atacada indisponível.

O Solaris e o Linux são exemplos de sistemas operacionais que possuem essa funcionalidade a ser implementada [7].

O TCP SYN Cookies faz o controle de requisições TCP, ou seja, quando é recebido um SYN e devolvido o SYN ACK, daí o requisitado fica em Open Passivo esperando pelo ACK do requisitante até que seja enviando e recebido o ACK para que a conexão se estabeleça. Esse processo não utiliza recursos de processamento e memória da máquina requisitada, pois a mesma o estado SYN_RECV está em listen. Quando o ACK é recebido e conferido a conexão é estabelecida [7].

Outros ataques contidos pelo TCP SYN Cookies são o DoS e o DDoS (Distributed Denial of Service), que seria o ataque DoS mais avançado e planejado, onde a vítima é atacada por várias origens de forma simultânea ou não.

Por default esse parâmetro vem desabilitado.

4.6) /proc/sys/net/ipv4/ip_always_defrag


Essa variável no kernel 2.4.20-8 que estou usando para fazer os testes conforme eu vou escrevendo esse artigo não existe, porém procurando informações na Internet e em revistas foi chegada a conclusão que esse parâmetro fornece recursos para remontar pacotes fragmentados e essa opção já vem habilitada pelo kernel em sua inicialização, não sendo necessária a sua configuração [1].

4.7) /proc/sys/net/ipv4/conf/all/accept_redirects


Antes de falarmos sobre esse parâmetro em específico, vamos comentar um pouco sobre o diretório /proc/sys/net/ipv4/conf/. Dentro desse diretório estão contidas todas as interfaces de rede instaladas na máquina (eth0, eth1, loopback e a placa de rede default) representadas por subdiretórios, onde dentro deles temos mais parâmetros de configurações das interfaces de rede que iremos estudar a seguir. Para configurar todas as placas de rede de uma única vez, existe o diretório /proc/sys/net/ipv4/conf/all/, que faz com que todas as interfaces de rede tenham uma configuração única. É possível substituir o /proc/sys/net/ipv4/conf/all/ por /proc/sys/net/ipv4/conf/*/. Caso precise configurar o parâmetro de uma específica interface de rede, entre no respectivo subdiretório e configure os parâmetros desejados.

Agora que já conhecemos um pouco do diretório /proc/sys/net/ipv4/conf/, vamos ao que interessa.

A variável accept_redirects já vem ativa por padrão pelo kernel. É interessante deixá-la ativa se o computador estiver fazendo a função de roteador, caso contrário é melhor desativá-la, pois assim fará com que alguns redirecionamentos ICMP sejam rejeitados, evitando assim a técnica de ataque ARP Spoofing (envenenamento da tabela ARP). ICMP redirects são utilizados para informar a um host que existe um caminho melhor para enviar pacotes a uma determinada rede ou host [9].

4.8) /proc/sys/net/ipv4/conf/all/accept_source_route


Deixando essa opção desabilitada evita que atacantes "spoofem" seu endereço IP.

O accept_source_route ativo permite estabelecer o caminho de sua origem ao seu destino e vice-versa feito por um pacote. Esta opção vem desabilitada por padrão.

4.9) /proc/sys/net/ipv4/conf/all/log_martians


Opção desabilitada pelo kernel por padrão.

Pacotes que possuem endereço de origem com nenhuma rota definida são chamados de "martians" [9].

Se habilitado essa variável, permite que pacotes de origem duvidosa ou desconhecida (pacotes forjados) sejam logados pelo kernel, sendo uma opção muito boa para se fazer auditoria na máquina e rede.

4.10) /proc/sys/net/ipv4/conf/all/rp_filter [9]


Caso o ip_forward esteja habilitado, é possível modificar o ajuste do rp_filter.

O rp_filter refeita pacotes de entrada caso o endereço de destino não seja o mesmo no qual o pacote esteja atingindo. Isso ajuda na prevenção do IP Spoofing (Forjar endereço IP). Habilitar essa opção tem suas conseqüências: se o host possuir mais de um endereço IP em diferentes interfaces de rede ou uma única interface de rede com múltiplos endereços IP, o kernel irá rejeitar todo o tráfego, inclusive o tráfego válido. É importante alertar que essa proteção aconteça contra endereços IP "spoofados" internos, endereços externos podem ainda ser forjados por endereços internos. Por default essa variável é desabilitada. É interessante habilitar essa opção.

4.11) /proc/sys/net/ipv4/conf/all/secure_redirects


Este parâmetro permite o redirecionamento seguro dos pacotes. Se não estiver habilitado, o kernel aceitará mensagens ICMP redirect vindos de qualquer host, mas se estiver habilitado, todos as mensagens ICMP redirects serão aceitos somente pelos gateways listados na lista de gateway default, com isso evitando redirecionamentos ilegais que podem ser maliciosos. Esse parâmetro pode ser sobrescrito através de outra variável chamada de shared_media, é interessante habilitar ambas essas variáveis [1].

4.12) /proc/sys/net/ipv4/conf/all/shared_media


O valor default dessa variável é verdadeiro. O principal objetivo dessa variável é informar ao kernel se deve realmente enviar mensagens ICMP redirects para uma rede específica ou não.

Essa variável informa ao kernel se a interface física está compartilhada ou não, ou seja, se diferentes redes IP com diferentes máscaras operam sobre uma mesma mídia ou não.

Página anterior     Próxima página

Páginas do artigo
   1. Resumo
   2. O pseudo-sistema de arquivos
   3. O sysctl
   4. Implementado segurança no kernel
   5. Conclusão
   6. Referências bibliográficas
   7. Sobre o autor
Outros artigos deste autor

VPN: IPSec vs SSL

Leitura recomendada

Ksplice - atualizando o kernel sem necessidade de reboot

Compilando kernel com suporte a POM (path-omatic) e Layer7 no Debian e Slackware

cpulimit - Limitando o uso da CPU por processo

Blu-ray: Reproduzindo, copiando, ripando e assistindo no GNU/Linux

Mitigando Erro de Kernel: Neighbour Table Overflow

  
Comentários
[1] Comentário enviado por errado em 03/02/2005 - 02:19h

Caramba! Eu tinha acabado de ler um texto sobre /proc e sysclt enão tinha entendido muito bem...Com esse artigo publicado, já dei um salto enorme no entendimento ;)

Parabéns!

[2] Comentário enviado por dark_slack em 03/02/2005 - 03:35h

Muito 10 seu artigo. Muito bom mesmo.

[3] Comentário enviado por reimassupilami em 03/02/2005 - 10:31h

cara, massa mesmo teu artigo viu... isso só ressalta a importância de cuidarmos da segurança dos servidores... nem conhecia todos esses ataques que você mencionou...

com certeza vou dar uma estudada no artigo e pôr tudo em prática...

só uma coisa que não ficou muito clara pra mim: o que eu devo fazer pra que as configurações sejam refeitas quando reinicio a máquina?

[4] Comentário enviado por wmqueiroz em 03/02/2005 - 23:58h

Antes de tudo, fico muito grato a todos pelos comentários e elogios! Vlw mesmo!!

Sobre a questão de reimassupilami... dê uma lida nesse artigo nas partes:

2. O pseudo-sistema de arquivos
3. O sysctl

[]´s
Wagner Queiroz

[5] Comentário enviado por Carlos_Cunha em 05/10/2012 - 14:43h

Olá!
Muito bom artigo, vi em outros post e sites as mesmas "proteção" so que menos eficientes e via regras de iptables....
Aprendi lendo seu artigo

:-D

Abraço

[6] Comentário enviado por px em 10/07/2013 - 21:44h

Grande referência para meus estudos, obg por compartilhar com a comunidade.

[7] Comentário enviado por wldnet1 em 08/09/2015 - 14:49h


Ótima contribuição amigo. Gostei muito auto explicativo.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts