Melhorando a Segurança com Filtros de Pacote
Por: Verdade @bsoluta
-
Introdução
-
Visão geral sobre filtros
-
TCP SYN (DoS)
-
UDP Portas de Diagnóstico (DoS)
-
Configurando TCP Intercept (Prevenção contra DoS)
-
TCP Loopback (DoS)
-
Smurfing (DoS)
1 - Introdução
Sabemos que existem várias formas de ataques, o estabelecimento
de filtros de pacotes pode ser uma boa medida para ajudar na proteção
de servidores internos de acessos indevidos. O uso de filtros é
recomendado em situações simples e como complemento de outros
mecanismos de segurança, que proporcionem maior flexibilidade e
controle. Os filtros de pacotes são muito úteis mas não
devem ser a única forma de defesa.
Este artigo trata em especial da implementação de filtros
em roteadores CISCO, mas acredito que a idéia básica pode
ser útil em outros tipos de roteadores (bay network, 3Com, etc).
Após a aplicação dos filtros é recomendável
que o administrador da rede fique atento ao desempenho da mesma que pode
sofre um pequeno impacto levando-se em conta alguns fatores como volume
do tráfego, número de filtros entre outros; o bom senso deve
prevalecer para achar a melhor medida que garanta um certo nível
de segurança e bom desempenho da rede.
2 - Visão geral sobre filtros
A filtragem de pacotes consiste na análise dos pacotes,
conforme o conteúdo de determinados campos que fazem parte do cabeçalho
do pacote, este análise permite a passagem ou descarte do pacote
conforme os filtros.
O filtro é composto de várias regras que levam em conta
principalmente:
-
Endereço IP de origem e destino - Todo pacote possui um endereço
de origem e um endereço de destino. O endereço de origem
é o da máquina (interface) que estabeleceu a comunicação,
enquanto o endereço de destino corresponde à máquina
de destino final. Quando o pacote trafega pela rede estes endereços
não são alterados. A filtragem por endereço pode ser
feita pela origem e/ou destino, no endereço completo (host) ou em
parte dele (net ou bloco).
-
Protocolo - As regras podem ser montadas para bloquear totalmente
um determinado protocolo (UDP, TCP, ICMP ou RCP) ou especificar um serviço,
que assume características diferentes dependendo da combinação
protocolo/porta.
-
Portas de origem e destino - O acesso a serviços Internet
é feito com base nos números de portas. Assim como os endereços
IP, as portas podem ser modificadas no caso de um ataque para tentar contornar
os filtros.
-
Outros campos dos cabeçalhos TCP/IP como Type-of-service (TOS)
e Flags (bit ACK), podem ser utilizados para as regras de filtragem.
Abordagens para aplicação de filtros:
-
Bloquear alguns acessos e permitir todos os demais - este tipo de
regra é simples de implementar, mas pode dar uma falsa sensação
de segurança, já que o mesmo serviço pode ser ativado
em uma porta completamente diferente.
-
Permitir alguns acesso e bloquear todos os demais - este tipo de
filtro possui uma implementação mais complexa e exige um
maior entendimento do funcionamento dos protocolos, mas oferece um maior
nível de segurança.
-
Sentido da aplicação do filtro - O sentido da aplicação
dos filtros é fundamental para seu funcionamento, e pode ser aplicados
na entrada da interface (inbound) ou saída (outbound).
Dependendo do sentido, os endereços IP e as portas mudam completamente.
Filtros em roteadores CISCO
-
A implementação de filtros de pacotes em roteadores CISCO
é feita por meio de listas de acesso (access-list). Existem
dois tipos de access-list:
-
standard: onde somente o endereço de origem é
informado, a identificação destas listas variam de 1 a 99.
- access-list # {deny/permit}
origem máscara
-
extended: onde o controle é feito levando-se em consideração
endereços, portas com algumas opções adicionais, a
identificação destas listas variam de 100 a 199. - access-list
# {deny/permit} protocolo origem máscara porta destino máscara
porta established log
3 - TCP SYN (DoS)
-
Visão geral - O "atacante" envia um grande número
de conexões que não podem ser completadas. Isso causa
um enfileiramento das conexões e consequentemente negação
de serviços para os os usuários legítimos.
Descrição do Problema
-
Quando uma conexão normal de TCP é iniciada, o hosts
destino recebe um pacote SYN (synchronize/start) do hosts
de origem e envia de volta um pacote SYN ACK (synchronize acknowledge).
O hosts de destino aguarda por uma pacote ACK (acknowledge)
em resposta ao pacote SYN ACK enviado, somente após o recebimento
do pacote ACK a conexão é estabelecida. Isso é referenciado
como TCP three-way handshake.
-
Enquanto o destino aguarda pelo pacote ACK começa a formação
de uma fila de pacotes :) que aguardam pelos pacotes SYN ACK para completarem
a conexão. Geralmente o pacote ACK chega após alguns milesegundos
do envio do pacote SYN ACK.
-
O ataque TCP SYN baseia-se nesta característica do protocolo, o
host
de origem geral uma série de pacotes com origem randomica e envia
para o host vitima. O host vitima envia pacotes SYC ACK para
os hosts de origem (gerados randomicamente) e adiciona uma entrada
na fila de conexões. Note que se um pacote SYN ACK é enviado
para um host incorreto ou inexistente, a ultima parte do
tree-way
handshake nunca será completada e a entrada fica na fila de
conexões até expirar por timeout, tipicamente um minuto.
Com a geração de centenas de pacotes randomicos é
possível lotar a fila de espera de conexões do
host
destino iniciando um processo de negação dos serviços
legítimos (e-mail, ftp ou WWW).
-
O rastreamento do originador dos pacotes não é um processo
muito fácil, uma vez que os pacotes de origem são gerados
de forma randomica ou seja são forjados.
-
A manifetação externa do problema inclui a impossibilidade
de pegar e-mail, impossibilidade de conexões a serviços WWW
ou FTP ou um grande número de conexões no seu host
com o status SYN_RCVD.
-
Defendendo-se do ataque
-
Hosts protegidos por firewall - O ataque TCP SYN é caracterizado
pelo envio de um grande número de pacotes SYN com IP de origem randomicos.
Qualquer host que esteja atraz de um firewall que bloqueia na entrada
(inbound) pacotes SYN estão protegidos desta modalidade de
ataque e nnbhuma providência é requerida.
-
Hosts que oferecem serviços públicos (servidor de e-mail,
servidor web público) - Prevenir o ataque TCP SYN em hosts
que estão atrás de um firewall é relativamente simples
uma vez que você pode implementar regras que limitam o acesso (inbound)
a um determinado range de IP. Mas no caso de servidores web públicos
ou servidores de e-mail, não há como determinar quais endereços
de origem são amigos ou inimigos. Então não existe
uma forma limpa de proteçãao contra IP gerado randomicamente.
Algumas medidas paliativas podem ser tomadas:
-
Aumente o tamanho da fila de conexões (SYN ACK queue).
-
Diminua o tempo de timeout do three-way handshake.
-
Adquira um programa que detecta o padrão do ataque e contorne o
problema.
-
Você deve entrar contato com o fornecedor do seu equipamento para
ver se ele desenvolveu algum patch para o ataque TCP SYN.
-
Note que filtrar o endereço IP torna-se ineficiente, pois o "atacante"
pode variar o IP de origem, e o endereço pode ser ou não
um endereço válido.
-
Prevenindo contra endereços inválidos - note que o
mecanismo primário deste tipo de ataque (DoS) é a geração
de trafego com origem randomica, uma medida seria a filtragem do tráfego
para a Internet. O conceito básico é impedir que pacotes
com endereços inválidos entrem na Internet. Isto não
impede um ataque de DoS a sua rede, mas ajuda a prevenir que alguém
de dentro da sua rede tente atacar usando endereços inválidos.E
consequentemente torna sua rede menos atrativa para a montagem de uma base
para este tipo de ataque.
-
Prevenindo-se contra o envio de endereços inválidos
- você pode colocar filtros que permitam somente a saída de
endereços válidos com destino a Internet. Por exemplo, se
sua sua rede for 172.16.0.0, e seu roteador conecta-se com seu ISP usando
a interface serial 0/1, você pode aplicar a seguinte lista de acesso:
-
access-list 111
permit ip 172.16.0.0 0.0.255.255 any
-
access-list 111
deny ip any any log
-
interface serial 0/1
-
ip access-group 111 out
-
Note que a última regra (access-list) bloquei o envio de
endereços inválidos para a Internet além de registra
a ação em arquivos de log (sobre como registar a ação
em arquivos de log utilizando o syslog do UNIX vou escrever/traduzir outro
artigo). A última regra não é fundamental, mas pode
ajudar na localização da origem no caso de um ataque.
-
Prevenindo-se contra a entrada de endereços inválidos
-
Para ISP que provêem serviço final de redes para clientes
é fortemente recomendável a validação
dos pacotes de entrada para os clientes através da utilização
de filtos na entrada (inbound) do seu roteador principal. Por
exemplo, se seu cliente tem um rang de IP conectados ao seu roteador via
interface serial 1/0, você pode criar a seguinte regra: ( Os números
de rede são 192.168.0.0 a 192.168.15.0 e 172.18.0.0 )
-
access-list 111
permit ip 192.168.0.0 0.0.15.255 any
-
access-list 111
permit ip 172.18.0.0 0.0.255.255 any
-
access-list 111
deny ip any any log
-
interface serial 1/0
-
ip access-group 111 in
-
Note que a última regra (access-list) bloquei a entrada de
endereços inválidos vindos da Internet além de registra
a ação em arquivos de log (sobre como registar a ação
em arquivos de log utilizando o syslog do UNIX vou escrever/traduzir outro
artigo). A última regra não é fundamental, mas pode
ajudar na localização da origem no caso de um ataque.
-
Prevenindo-se contra a entrada de endereços inválidos
RFC 1918 - Outra regra que pode ser aplica é a prevenção
contra a entrada de endereços das classes privadas RFC 1918 (vale
apena ler, é pequena são somente dez folhas), vamos direto
as regras:
-
access-list 111
deny ip 10.0.0.0 255.255.255.255 any
-
access-list 111
deny ip 172.16.0.0 0.15.255.255 any
-
access-list 111
deny ip 192.168.0.0 0.0.255.255 any
-
interface serial 0
-
ip access-group 111 in
4 - UDP Portas de Diagnóstico (DoS)
-
Visão geral - O "atacante" transmite um grande volume de
requisições UDP para o serviço de diagnósticos
do roteador, que consome todos os recursos da CPU tentando atender as requisições,
este tipo de ataque também é conhecido como ataque "pepsi".
Descrição do Problema
-
Por default, o roteador CISCO possui uma série de portas
de diagnóstico que permitem alguns serviços UDP e TCP inclusive
echo, chargen e discard. Quando um host conecta-se a estas
portas, uma pequena porção da CPU e comsumida para servir
a requisição .
-
Se um "atacante" enviar um grande volume de requisições com
endereço de IP origem gerado randomicamente, é possível
que o roteador CISCO sofra uma sobre carga e fique lento ou até
mesmo falhar.
-
A manifestação externa para este problema reflete-se na tabela
de processo que ficará cheia de mensagens de erro (%SYS-3
NOPROC) ou uma super utilização da CPU. O comando
show
process listará vários processo com o mesmo nome,
por exmplo, UDP Echo.
-
Defendendo-se do ataque
-
Desabilitando as portas UDP de diagnósticos - Qualquer dispositivo
de rede que possuem serviços de diagnóstico UDP e TCP
podem ser protegidos por um firewall ou desativando os serviços.
Em roteadores CISCO, isto pode ser feito usando-se os comandos globais
de configuração:
-
no service udp-small-servers
-
no service tcp-small-servers
-
Estes comandos estão disponíveis nas seguintes versções
do Cisco IOS: 10.2(9), 10.3(7), 11.0(2) e em todas as verções
posteriores a estas.
-
Descrição dos small servers - Os small servers
são servidores (no UNIX são daemons) que rodam no roteador
que são uteis para diagnósticos. E por default eles
estão ativos. Os comandos para TCP e UDP small servers são:
-
service udp-small-servers
-
service tcp-small-servers
-
Você pode desabilitar este serviços usando a sintaxe no
antes do comando, veja acima.
-
Os small servers TCP são:
-
Echo: Replica tudo que você digita. Para ver em funcionamento
entre com o seguinte comando: telnet x.x.x.x
echo .
-
Chargem: Gera um conjunto de caracteres ASCII. Para ver em funcionamento
entre com o seguinte comando: telnet x.x.x.x
chargem .
-
Discard: Joga fora tudo o que você digita. Para ver em funcionamento
entre com o seguinte comando: telnet x.x.x.x
discard .
-
Daytime: Retorna a data e hora do sistema, se estiver correta. Ela
está correta se você estiver rodando NTP ou tiver ajustado
manualmente a data e hora. Para ver em funcionamento entre com o seguinte
comando: telnet x.x.x.x daytime .
-
Os small servers UDP são:
-
Echo: Mostra o payload do datagrama que você enviar.
-
Discard: Silenciosamente descarta o datagrama que você enviar.
-
Chargem: Descarta o datagrama que você enviar e responde com
uma string de 72 caracteres ASCII os caracteres terminam com CR+LF.
5 - Configurando TCP Intercept (Prevenção
contra DoS)
6 - TCP Loopback (DoS)
7 - Smurfing (DoS)
Referências :
-
http://www.rnp.br/newsgen/9803/filtros.shtml (Autor: Carlos A. Campana
Pinheiro)
-
http://www.cisco.com
http://www.absoluta.org
---oOo--- verdade@absoluta.org
Copyright © 1998 - 1999 Verdade @bsoluta
|