Ver Feed RSS

The JEdi lair's

Mantendo e depurando regras do Netfilter/iptables com auxílio de fluxogramas

Avaliação: 5 votos, 5,00 média.
Como mostrado nos posts anteriores, o filtro de pacotes do Linux. o Ntfilter/iptables, é bastante robusto e poderoso. Porém, quando sua base de regras aumenta, a administração de tais regras pode ser tornar confusa e tediosa, levando muitas vezes a erros e a criação de brechas para ações maliciosas.

Tendo sua utilidade subestimada nas maiorias das situações, venho a mostras nesse post como o uso de fluxogramas pode auxiliar um administrador na tarefa de depuração e manutenção de regras de filtro de pacotes.

1 - Fluxogramas
Os fluxogramas são estruturas usadas na computação há muito tempo. Atualmente, esses são abordados rapidamente em cursos de construção de algoritmos e programação básica. Sua principal função se resume em gerar uma representação visual do processo ou algoritmo, de forma a facilitar seu entendimento por pessoas externas a análise.

Porém, até mesmo para um analista, a representação visual se torna mais "digerível". Não poderia ser diferente para um administrador de redes: um gráfico bem elaborado vale mais que 1000 linhas de registros do sistema.

No contexto do post, as seguintes estruturas dos fluxogramas são as mais importantes:

http://under-linux.org/fotos/pedroar...-flowchart.pngNome:      7291-flowchart.png
Visitas:     5077
Tamanho:  6,5 KB
Figura 1.0: Estruturas básicas dos fluxogramas

A primeira estrutura, a entrada e saída, será usada para representar a chegada de um pacote em uma tabela do Netfilter/iptables; A segunda, a tomada de decisão, representará as matchs das regras; os processos auxiliares representará as targets extensions (LOG, DNAT, SNAT); e por ultimo, mas não menos importante, os terminais representarão pontos onde a avaliação das regras terminarão, tais quais as targets padrão (ACCEPT, DROP).

1.1 - Exemplo Inicial: a travesia das tabelas
O primeiro ponto básico para a depuração e a manutenção de regras é entender claramente como os pacotes serão avaliados. Portanto, para começar e criar uma certa familiaridade com o modelo dos fluxogramas, iremos modelar a travesia dos pacotes por entre o Netfilter/iptables. Esse, está representado fluxograma da figura 1.1.

http://under-linux.org/fotos/pedroar...ttraversal.pngClique na imagem para uma versão maior

Nome:	         7292-packettraversal.jpg
Visualizações:	8759
Tamanho: 	47,3 KB
ID:      	9015
Figura 1.1: Travesia dos pacotes nas tabelas do Netfilter/iptables

Explicando em miudos, a estrutura nomeada como "Novo Pacote" representa a chegada de um pacote, seja ele vindo de uma inteface de rede ou de uma aplicação local; Já na estrutura de número 2, nomeada "Entrada/Saída", é feita uma tomada de decisão relacionada com a natureza do pacote. Caso esse seja gerado por uma aplicação no próprio host, esse será encaminhado para a vertente de Saída. Caso contrário, o pacote esteja chegando por alguma interface de rede, será encaminhado para a vertente de Entrada; As estruturas de processos auxiliares, elementos 3 e 4 da figura 1.1, estão representando as chains pelas quais os pacotes estão fluindo. Por exemplo, caso a tomada de decisão em 2 seja de Entrada, o pacote irá para chain PREROUTING da tabela raw. Caso seja Saída, o pacote irá para a chain OUTPUT da tabela raw; Continuando, o controle de fluxo de pacotes em tabelas decide em 5 se o pacote deve ser encaminhado a chain INPUT das tabelas mangle e filter, ou se o mesmo deve atravesar o filtro de pacotes, passando pelas chains de FORWARD e POSTROUTING. Veja também que a vertente de saída tem um ponto em comum com a vertente de entrada, caso essa ultima tenha que repassar os pacotes para outra interface: a chain POSTROUTING da tabela mangle e nat. Nesse modelo, tenham como implícito as targets pois sua presença adicionaria complexidade desnecessária nesse nível de detalhamento. Esperam que tenham achado esse fluxograma mais simples de entender que o texto com setinhas "maior que" do post anterior

Como dito anteriormente, nosso modelo inicial já se encontra de certa forma complexo, e adicionar os detalhes de cada chain só proporcionaria mais confusão. E isso justamente o que queremos evitar com essa técnica.

2 - Modelando regras nas tabelas
O primeiro passo para montar o fluxograma de uma tabela consiste em analisar quais caminhos um pacote pode seguir na mesma. Vamos pensar primeiramente em como diagramar a tabela filter.

A tabela filter possui três chain padrões, a saber: INPUT, OUTPUT e FORWARD. Por ser uma tabela padrão, implíca que todas elas possui uma política predefinida. Portanto, nosso modelo inicial para a tabela filter será como mostrado na figura 2.0.

http://under-linux.org/fotos/pedroar...luxogramas.png
Nome:      7080-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.png
Visitas:     4816
Tamanho:  14,6 KB

Figura 2.0: Fluxograma genérico da tabela filter.

Só para constar, a estrutura de número 1 representa a entrada de um pacote na tabela filter; A de número dois representa a decisisão de qual chain o pacote deve ser encaminhado, onde devemos levar em consideração qual caminho o pacote vem percorrendo, de acordo com o fluxo da figura 1.1; O bloco de número 3 e os seu semelhantes são as políticas de cada chain. Aqui já vale um pouco de boas práticas de criação de fluxogramas: agregar blocos com funções iguais, levando o nosso diagrama ao da figura 2.1.

http://under-linux.org/fotos/pedroar...luxogramas.pngNome:      7082-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.png
Visitas:     4316
Tamanho:  11,3 KB
Figura 2.1: Modelo inicial de um filtro de pacotes restritivo.

Existem casos também onde as boas práticas não são as melhores escolhas. Imagine por exemplo a geração de um fluxograma de um filtro restritivo (baseado na figura 2.1) usando as boas práticas de criação, contendo apenas as seguintes regras:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
Esse conjunto de regras está representado na figura 2.2a.

http://under-linux.org/fotos/pedroar...luxogramas.png
Nome:      7081-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.png
Visitas:     7191
Tamanho:  81,3 KB

Figura 2.2: (a) Filtro restritivo de duas regras segundo as boas práticas; (b) Mesmo filtro segundo as melhores práticas

Por esse exemplo podemos ver claramente que as boas práticas, nem sempre são as melhores práticas! A figura 2.2b é o mesmo filtro, porém com diversas estruturas idênticas repetidas de forma a favorecer ao entendimento do mesmo.

Apesar de mostrar uma organização condizente com a do Netfilter/iptables, a diagramação por tabelas pode se tornar bastante extensa. Imagine um fluxograma para um conjunto de regras constituido de 20 regras na chain INPUT, 10 regras na chain OUTPUT e mais 40 regras na chain FORWARD. Antes de pensar que isso não existe, imagine um filtro/roteador de perímetro em uma grande organização.

Então, de agora em diante, voltaremos aos blocos da figura 1.1. Cada fluxograma representará um processo daquele diagrama. Exemplo, teremos um fluxograma para a chain INPUT da tabela filter, um para a chain PREROUTING da tabela nat, e assim por diante.

2.1 - Exemplo: modelando um conjunto de regras da tabela filter
Para esse exemplo, vamos considerar um servidor LAMP, o qual aceitará conexões nas portas 21 (ftp), 22 (ssh), 80 (http), 443 (https) e 3306 (MySQL). A esse servidor também será permitido realizar conexões a um servidor de atualização que roda na porta 80 do endereço IP 10.2.0.10. Esse servidor também poderá resolver nomes e sincronizar seu relógio com o servidor do NTP.br. Primeiramente, vamos explicitar nosso conjunto de regras:


iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --syn --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --syn --dport 22 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --syn --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --syn --dport 443 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --syn --dport 3306 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED.RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 -d 10.2.0.10 -p tcp --syn --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o eth0 -d a.ntp.br -p udp --dport 123 -m state --state NEW -j ACCEPT


As três primeiras regras geram o filtro representado na figura 2.1.

Considerando i como a flag -i, p como a flag -p, syn como a flag --syn, dp como a flag --dport e state como o conjunto de flags -m state --state, a chain INPUT, após modelada, ficaria como representado na figura 2.3.

http://under-linux.org/fotos/pedroar...luxogramas.pngClique na imagem para uma versão maior

Nome:	         7077-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.jpg
Visualizações:	4727
Tamanho: 	63,2 KB
ID:      	9023
Figura 2.3: Filtro de pacotes restritivo populado

3 - Depurando nosso filtro de exemplo
Para depurar nosso filtro de exemplo, devemos tomar em consideração todo o caminho a ser percorrido desde a primeira estrutura de entrada da figura 1.1 até a modelagem de nossas regras, presentes na figura 2.3.

3.1 - Definindo casos de teste
O primeiro passo é definir um conjunto básico de casos de testes. Para um servidor LAMP, seriam os pacotes dos serviços que queremos prover, mais os casos onde ACHAMOS que a política deve prevalecer. Considerando o IP da interface eth0 como 10.2.0.15, podemos ter os seguintes exemplos:

Tabela 3.1: Casos de testes de pacotes de entrada para o filtro da figura 2.3

Veja que temos cinco casos distintos. Nos quatro primeiro exemplos, temos pacotes desejados, destinados aos serviços que provemos. Já no o quinto caso, temos um extremamente indesejado: o IP de destino não corresponde ao IP de nossa interface eth0 e a porta de destino também não tem nada a ver com nossos serviços.

Para manter a didática simples, definimos poucos casos. Porém, em ambientes reais e complexos, deve-se gerar uma quantidade significativa de casos de testes. Uma metodologia interessante é gerar em média quatro testes por regras, dois pacotes válidos e dois pacotes rejeitados. Vai da paciência e da corajem de cada um!

3.2 - Analisando o fluxo
Nessa etapa, iremos aplicar os casos criados aos fluxogramas modelados anteriormente. Devem ser considerados os fluxogramas de todas as chains pois muitas vezes podemos desviar o caminho de um pacote em uma chain anterior a qual criamos a regra, erro muito comum em caso de gateways. No meu caso, certa vez queria liberar o tráfego na porta 22 mas estava desviando-o pela tabela nat para outro host... Notem que para simplificar a didática, iremos desconsiderar as chains das tabelas raw, mangle e nat.

Então, deve-se primeiramente ter em vista o fluxograma da figura 1.1, pois esse será nosso guia por entre as chains.

Para os casos da tabela 3.1, teremos sempre pacotes de entrada, os quais tomarão a ramificação de entrada na estrutura 2 e a ramificação local da estrutura 5, ambas pertencentes a figura 1.1. Consequentemente, o caminho do pacote até a chain INPUT da tabela filter será

http://under-linux.org/fotos/pedroar...luxogramas.png
Nome:      7083-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.png
Visitas:     4055
Tamanho:  3,5 KB

Figura 3.2.1: Caminho dos casos de testes até a chain INPUT da tabela filter.

obs: lembrem-se que em casos reais devemos analisar todas as chain pois, como dito anteriormente, as tabelas raw, mangle e nat podem altera o fluxo dos pacotes!!! Depois não digam que a metodologia é furada!

Iniciemos nossa análise com o caso 1. Devemos considerar desde o inicio da conexão, portanto o caso 1 pode, e deve, ser desmenbrado com um pouco mais de detalhamento, que no caso abaixo são as flags da camada de transporte:

Tabela 3.2.1: Three way handshake do caso 1.

Acima, temos a troca de pacotes inicial, denominado Three Way Handshake. Aparti daqui, já podemos visualizar o fluxo.

O pacote 0 chegará a chain INPUT da tabela filter, não casará com a primeira regras pois a conexão está em estado novo; Apesar do pacote estar entrando na interface correta, com o estado novo, as regras 2 e 3 não casarão pois suas portas de destino são 21 e 22 respectivamente; Finalmente, nosso pacote atingirá a quarta regra, onde casa com todos os pacotes. Aqui, a target ACCEPT é acionada e o pacote é entregue aplicação, conforme figura 1.1; A utima regra não chega a ser validada pois a target ACCEPT é terminativa, portanto, o caminho do pacote termina nela.

Os pacotes 1 e 2, estarão no estado RELATED, portanto casarão com a primeira regra. Pacotes subsequentes estarão no estado ESTABLISHED e também casarão com a primeira regra.

Apesar de não detalhá-lo, o caso 2 também se mostra bastante interessante. A porta 21, em nosso exemplo, está relacionada com o serviço de FTP. Em sua RFC, o protocolo de transferência de arquivos define que uma porta dinâmica deve ser aberta no cliente (FTP ativo) ou no servidor (FTP passivo). No Linux, o Netfilter/iptables trabalha em conjunto como o sistema Conntrack para prover, de forma transparente, um mecanismo de liberação da porta negociada durante os pacotes iniciais da conexão FTP. Portanto, não necessitamos estar preocupados com problemas relativos ao protocolo FTP, apenas carregar o módulo de conntrack do FTP e liberar a porta 21 (Ou qualquer outra que o daemon FTP esteja escutando). Então, de forma breve, esse caso passaria por toda a parte do three way handshake, executando todos os passos do caso 1. Logo em seguida, o mecanismo de conntrack ira verificar o tráfego em busca de um informação PASV ou PORT (ambas do protocolo FTP) e liberar a porta negociada pelos interessados na conexão.

Os casos três e quato se enquandram no processo do caso 1, porém variando apenas as regras as quais os liberarão. Contudo, vale dar uma olhada no caso 5.

Se voltarmos um pouco, vemos que o caso 5 possui um endereço IP que não pertence a nossa máquina e uma porta que não desejamos prover serviço. Um IP que não pertence a nossa máquina? Isso é possível? Recomendo a leitura do post do Magnum sobre camada de rede e protocolo ARP. Logo em seguida leia http://en.wikipedia.org/wiki/ARP_spoofing.

Apesar de nossa política bloquear o pacote do caso 5, podemos ver em meio aos nosso fluxogramas que ele passará despercebido pela maioria das chains, de forma que se ele fosse direcionado a um serviço específico, ele seria aceito.

3.3 - Corrigindo o filtro
Em nossa depuração, conseguimos encontra uma falha. Então agora cabe a nós, administradores do filtro de pacotes, corrigí-la antes que a equipe de pen-test chegue!

Precisamos, no caso acima, gerar uma regra que permita a passagem apenas de pacotes com os IP de nossas interfaces:
iptables -I INPUT -i eth0 -d ! 10.2.0.15 -j DROP
O que nos levaria a adaptar nosso fluxograma para o seguinte:

http://under-linux.org/fotos/pedroar...luxogramas.png
Nome:      7079-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.png
Visitas:     5366
Tamanho:  16,7 KB

Figura 3.3: Chain input da tabela filter após inserção da regra (não totalmente detalhado)

Outra solução bastante simples, e que eu acredito ser a mais eficiente, é bloquear esse pacote na chain PREROUTING da tabela raw:
iptables -t raw -A PREROUTING -i eth0 -d ! 10.2.0.15 -j DROP
Bloqueando na tabela raw o kernel não aloca recursos para o mecanismo de conntrack, por isso eu acho mais eficiente, porém, são só teorias, preciso verificar com os desenvolvedores.

Então, de forma iterativa, após a correção do nosso fluxograma devemos voltar a fase de testes e depurá-lo ate que tenhamos uma confiabilidade maior no nosso conjunto de regras, sempre visando melhorá-lo.

4 - Estudo de caso: post do fórum do Under-Linux.org
Problemas com filtro de pacotes é um dos problemas mais recorrentes nos fóruns do Under-Linux.org. Portanto, vamos tentar pegar algum post e tentar depurá-lo como uma forma de exercitar a técnica descrita.

iptables -A INPUT -p tcp --destination-port 22 -j DROP

iptables -A INPUT -s ipA/24 -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -s ipB/24 -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -s ipC1/24 -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -s ipD/24 -p tcp --destination-port 22 -j ACCEPT
O sujeito postou as regras acima, e gostaria de saber por que não conseguia acessar por SSH.

4.1 - Modelando o conjunto de regras
Tomando essas regras como todo o conjunto de regras do mesmo, temos que o filtro de pacotes é permissivo (política padrão). Definindo sip como a flag -s, p como a flag -p e dport como a flah --destination-port, nosso fluxograma fica:

http://under-linux.org/fotos/pedroar...luxogramas.png
Nome:      7076-figura-usada-no-post-http-under-linux-org-b381-mantendo-e-depurando-regras-do-netfilter-ipt.jpg
Visitas:     4402
Tamanho:  36,1 KB

Figura 4.1: Modelo de filtro de pacote encontrado no fórum

Apenas com nosso modelo pronto, podemos ver claramente o problema desse conjunto de regras.

Vejam que a primeira regra do filtro bloqueia qualquer conexão que seja feita a porta 22. Portanto, aqui bastaria transferir a primeira regra para a utima posição e o problema estaria resolvido.

Outra coisa que podemos ver também é que mesmo com a regra na posição correta, esse filtro não se encontra muito otimizado. Todas as regras criadas visam liberar o tráfego, tarefa deveria se realizada pela política. Uma simples otimização seria trocar a política de ACCEPT para DROP. Nesse caso teriamos uma diminuição de apenas uma regra e um aumento maior em nossa segurança. Porém se objetivo era apenas filtrar o tráfego SSH e liberar TODO o resto, ele se encontra adequado.

5 - Considerações Finais
Além da depuração e manutenção, essa técnica de modelagem de regras de filtro de pacotes é util também para a documentação. Em ambientes com mais de um administrador de sistemas se torna uma forma simples e fácil de comunicar mudanças, além de ser uma forma mais amigável para contextualizar um novo colega de trabalho.

Enfim, espero que tenham achado util. Utilizo diariamente em meus sistemas e tem poupado muito tempo. De uma maneira empirica, posso dizer que reduz o tempo total de implantação pela metade pois possibilita um planejamento prévio, evitando assim constantes mudanças, características de uma administração mal planejada.

Mais uma vez, espero que tenham gostado do post e estamos aberto para críticas e sugestões! Vejam, o operador é o E, então não adianta crítica sem sugestão...

Até mais!

Atualizado 29-01-2010 em 01:42 por PEdroArthurJEdi (Recolocando as figuras...)

Categorias
Não Categorizado

Comentários

  1. Avatar de Magnun
    Cara! Simplesmente incrível! Parabens!
  2. Avatar de MarcusMaciel
    Show ainda deu uma alterada no visual do blog hahaha parabens
  3. Avatar de PEdroArthurJEdi
    @Magnum

    Obrigado cara, é bom saber que alguém está lendo!

    @Scorpion

    É massa esse recurso. A única coisa que não gostei é que o fundo do site, a parte que é comum em todo o Under não dá pra personalizar, fica constrastando um pouco.., Mas o Under tá show!
  4. Avatar de MarcusMaciel
    Valeu pela dica cara... vou ver oq posso fazer...
  5. Avatar de irado
    o artigo é simplesmente extraordinario, um grande auxilio na construção de regras. Já o aspecto, êsse azul sobre fundo preto foi muito usado pelos ráqueres de 1970 acho que até mais ou menos '75, só faltou aquela caveirinha idiota fumando. Depois dessa fase os ráqueres cresceram e se tornaram hacker's (alguns) e deixaram de lado essas coisas.


    mas claro.. NÃO DESMERECE O EXCELENTE ARTIGO.
  6. Avatar de MarcusMaciel
    irado, pior de tudo que quando eu tinha uns 11 anos eu tinha um site no geosites.. com essa caverinha fumando ahahhaha era o logo do site
  7. Avatar de Magal
    Excelente!!!
  8. Avatar de PEdroArthurJEdi
    Citação Postado originalmente por irado
    o artigo é simplesmente extraordinario, um grande auxilio na construção de regras.
    Valeu... realmente, em ambientes complexos fica realmente difícil trabalhar apenas com a saída do iptables...

    Citação Postado originalmente por irado
    Já o aspecto, êsse azul sobre fundo preto foi muito usado pelos ráqueres de 1970 acho que até mais ou menos '75, só faltou aquela caveirinha idiota fumando. Depois dessa fase os ráqueres cresceram e se tornaram hacker's (alguns) e deixaram de lado essas coisas.
    Putz... perdi essa fase... não era nascido...

    Quanto as cores, tenho problemas com luminosidade... Quanto mais escuro melhor... Não gosto muito de usar óculos de sol em frente ao PC... Nem todos foram abençoados com uma visão perfeita . E achava que era verde sobre preto, a história sempre perde alguns detalhes!
  9. Avatar de magrock
    Fantastico, dei até um CTRL-C/CTRL-V para estudar melhor (Tenho problema de vista com relação a monitores de CRT), Mas o material é simplesmente fantastico.
    Parabéns.
    É por isso que o Under-linux é o Under-linux. (Vida inteligente na internet)

+ Enviar Comentário