Construção de Firewall - 6

Conferindo com o tempo de vida do pacote

            O módulo ttl pode ser usado junto com as seguintes opções para conferir com o tempo de vida (TTL) de um pacote:

·       --ttl-eq [num]

·       --ttl-lt [num]

·       --ttl-gq [num]

Veja alguns exemplos:

     # Confere com todos os pacotes que tem o TTL maior que 100

     iptables -A INPUT -m ttl --ttl-gt 100 -j LOG --log-prefix "TTL alto"

    

     # Confere com todos os pacotes que tem o TTL igual a 1

     iptables -A INPUT -m ttl --ttl-eq 1 -j DROP

OBS: Tenha um especial cuidado durante a programação de regras que usem TTL, como elas estão especialmente associadas com o estado da comunicação estabelecida entre as duas pontas e o tipo de protocolo, cuidados especiais devem ser tomados para que seu firewall não manipule de forma incorreta tráfego válido.

Conferindo com números RPC

            O módulo rpc permite um controle especial sobre o tráfego RPC que chega até a sua máquina. Um uso útil é restringir a chamada a determinados números RPC e permitir outros (por exemplo, permitindo somente o serviço keyserv e bloqueando outros como o ypserv ou portmapper). As seguintes opções podem ser usadas com o módulo nfs:

·       --rpcs [procedimentos] - Confere com a lista de chamadas RPC especificadas. Mais de um procedimento RPC pode ser especificado como nome ou número separando-os com vírgulas. Um arquivo útil que contém esta lista é o /etc/rpc.

·       --strict - Ignora serviços RPC que não contenham a chamada get do portmapper. Em situações normais, o inicio de qualquer solicitação RPC.

Veja alguns exemplos:

     # Para conferir com todas as chamadas RPC referentes a conexões iniciadas

     # para o portmapper

     iptables -A INPUT -m rpc --rpcs portmapper --strict -j DROP

    

     # Para permitir que somente as chamadas para status e statmon sejam

     # aceitas

     iptables -A INPUT -m rpc --rpcs 100023,100024 -j ACCEPT

Conferindo com tipo de pacote

O módulo pkttype permite identificar um pacote do tipo unicast (direcionado a você), broadcast (direcionado a uma determinada rede, definida pela netmask) ou multicast (destinado a grupos de redes) e desta forma realizar ações em cima destes. O tipo de pacote é identificado logo após a opção --pkt-type. Veja alguns exemplos:

     # Bloqueia a passagem de pacotes multicast de uma rede para outra

     iptables -A FORWARD -i eth0 -o eth0 -m pkttype --pkt-type multicast -j DROP

    

     # Como deve ter notado, é possível fazer a associação com diversas especificações

     # de módulos, bastando apenas especificar uma opção "-m" para cada módulo

     # adicional:

     # Permite a passagem de pacotes broadcast de uma rede para outra com

     # limitação de 5/s.

     iptables -A FORWARD -i eth0 -o eth0 -m pkttype --pkt-type broadcast -m limit --limit 5/s -j ACCEPT

Conferindo com o tamanho do pacote

O tamanho do pacote pode ser usado como condição de filtragem através do módulo length. O tamanho do pacote é especificado através da opção --length e o argumento segue a mesma sintaxe da especificação de portas no iptables sendo separados por :. Veja alguns exemplos:

     # Bloqueia qualquer pacote ICMP maior que 30Kb

     iptables -A INPUT -i eth0 -m length --length 30000: -j DROP

    

     # Bloqueia qualquer pacote com o tamanho entre 20 e 2000 bytes

     iptables -A INPUT -i eth0 -m length --length 20:2000 -j DROP


Caminho percorrido pelos pacotes nas tabelas e chains

 

            É MUITO importante entender a função de cada filtro e a ordem de acesso dos chains de acordo com o tipo de conexão e interface de origem/destino. Esta seção explica a ordem que as regra são atravessadas, isso lhe permitirá planejar a distribuição das regras nos chains, e evitar erros de localização de regras que poderia deixar seu firewall com sérios problemas de segurança, ou um sistema de firewall totalmente confuso e sem lógica.

Nos exemplos abaixo assumirei a seguinte configuração:

·       A máquina do firewall com iptables possui o endereço IP 192.168.1.1 e conecta a rede interna ligada via interface eth0 a internet via a interface ppp0.

·       Rede interna com a faixa de endereços 192.168.1.0 conectada ao firewall via interface eth0

·       Interface ppp0 fazendo conexão com a Internet com o endereço IP 200.217.29.67.

·       A conexão das máquinas da rede interna (eth0) com a rede externa (ppp0) é feita via Masquerading.

Também utilizarei a sintaxe CHAIN-tabela para fazer referência aos chains e tabelas dos blocos ASCII: INPUT-filter - chain INPUT da tabela filter.

ATENÇÃO: A ordem de processamento das regras do iptables, é diferente do ipchains devido a inclusão do novo sistema de nat e da tabela mangle.

Ping de 192.168.1.1 para 192.168.1.1

·       Endereço de Origem: 192.168.1.1

·       Endereço de Destino: 192.168.1.1

·       Interface de Entrada: lo

·       Interface de Saída: lo

·       Protocolo: ICMP

·       Descrição: Ping para o próprio firewall

     SAÍDA DE PACOTES (envio do ping para 192.168.1.1):

     +-------------+    +----------+    +-------------+   +------------------+  +----------------+

     |OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| =>|POSTROUTING-mangle|=>|POSTROUTING-nat |

     +-------------+    +----------+    +-------------+   +------------------+  +----------------+

    

     ENTRADA DOS PACOTES (Retorno da resposta ping acima):

     +-----------------+   +------------+  +------------+

     |PREROUTING-mangle| =>|INPUT-mangle|=>|INPUT-filter|

     +-----------------+   +------------+  +------------+

            Quando damos o ping (echo request) os pacotes seguem o caminho em SAÍDA DE PACOTES percorrendo os chains na ordem especificada e retornam via ENTRADA DOS PACOTES (echo reply). No envio da resposta da requisição de ping, o caminho de saída do pacote ignora os chains OUTPUT-nat e POSTROUTING-nat (já que não é necessário nat) mas sempre processa os chains correspondentes da tabela mangle na ordem indicada acima.

OBS1: Para conexões com destinos na própria máquina usando um endereço IP das interfaces locais, a interface será ajustada sempre para lo (loopback).

OBS2: Em qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar outros aspectos especiais dos pacotes que atravessam os filtros.

OBS3: O chain OUTPUT da tabela filter é consultado sempre quando existem conexões se originando em endereços de interfaces locais.

Conexão FTP de 192.168.1.1 para 192.168.1.1

·       Endereço de Origem: 192.168.1.1

·       Endereço de Destino: 192.168.1.1

·       Interface de Origem: lo

·       Interface de Destino: lo

·       Porta Origem: 1404

·       Porta Destino: 21

·       Protocolo: TCP

·       Descrição: Conexão ftp (até o prompt de login, sem transferência de arquivos).

     SAÍDA DOS PACOTES (envio da requisição para 192.168.1.1):

     +-------------+    +----------+    +-------------+    +------------------+    +---------------+

     |OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => +POSTROUTING-mangle| => |POSTROUTING-nat|

     +-------------+    +----------+    +-------------+    +------------------+    +---------------+

    

     ENTRADA DE PACOTES (respostas da requisição vindas de 192.168.1.1):

     +-----------------+    +------------+    +------------+

     |PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +------------+    +------------+

            A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES e retorna por ENTRADA DE PACOTES. Após a conexão ser estabelecida, o caminho de SAÍDA DE PACOTES será:

     +-------------+    +-------------+    +------------------+

     |OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|

     +-------------+    +-------------+    +------------------+

pois os dados de entrada que vem da interface externa, são passados diretamente a máquina do firewall, não necessitando de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat são processado somente uma vez a procura de regras que conferem, principalmente para fazer SNAT). Note novamente que mesmo não sendo necessário NAT, o chain POSTROUTING-mangle é checado.

OBS1: Para conexões com destinos na própria máquina usando um endereço IP das interfaces locais, a interface será ajustada sempre para lo (loopback).

OBS2: Em qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar outros aspectos especiais dos pacotes que atravessam os filtros.

Conexão FTP de 192.168.1.1 para 192.168.1.4

·       Endereço de Origem: 192.168.1.1

·       Endereço de Destino: 192.168.1.4

·       Interface de Origem: eth0

·       Interface de Destino: eth0

·       Porta Origem: 1405

·       Porta Destino: 21

·       Protocolo: TCP

·       Descrição: Conexão ftp (até o prompt de login, sem transferência de arquivos).

     SAÍDA DOS PACOTES (envio da requisição para 192.168.1.4):

     +-------------+    +----------+    +-------------+    +------------------+    +---------------+

     |OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => +POSTROUTING-mangle| => |POSTROUTING-nat|

     +-------------+    +----------+    +-------------+    +------------------+    +---------------+

    

     ENTRADA DE PACOTES (respostas da requisição de 192.168.1.4):

     +-----------------+    +------------+    +------------+

     |PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +------------+    +------------+

            A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES com o destino 192.168.1.4 porta 21 e retorna por ENTRADA DE PACOTES para 192.168.1.1 porta 1405. Após a conexão ser estabelecida, o caminho de SAÍDA DE PACOTES será:

     +-------------+    +-------------+    +------------------+

     |OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|

     +-------------+    +-------------+    +------------------+

pois os dados não precisam de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat são processado somente uma vez a procura de regras que conferem, principalmente para fazer SNAT).

OBS: Em qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar outros aspectos especiais dos pacotes que atravessam os filtros.

Conexão FTP de 200.217.29.67 para a máquina ftp.debian.org.br

·       Endereço de Origem: 200.217.29.67

·       Endereço de Destino: 200.198.129.162

·       Interface de Origem: ppp0

·       Interface de Destino: ppp0

·       Porta Origem: 1407

·       Porta Destino: 21

·       Protocolo: TCP

·       Descrição: Conexão ftp (até o prompt de login, sem transferência de arquivos).

     SAÍDA DOS PACOTES (envio da requisição para 200.198.129.162):

     +-------------+    +----------+    +-------------+    +------------------+    +---------------+

     |OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => +POSTROUTING-mangle| => |POSTROUTING-nat|

     +-------------+    +----------+    +-------------+    +------------------+    +---------------+

    

     ENTRADA DE PACOTES (respostas da requisição vindas de 200.198.129.162):

     +-----------------+    +------------+    +------------+

     |PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +------------+    +------------+

            A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES com o destino 200.198.129.162 porta 21 (após a resolução DNS de www.debian.org.br) e retorna por ENTRADA DE PACOTES para 200.217.29.67 porta 1407. Após a conexão ser estabelecida, o caminho de saída de pacotes é:

     +-------------+    +-------------+    +------------------+

     |OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|

     +-------------+    +-------------+    +------------------+

pois os dados não precisam de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat são processado somente uma vez a procura de regras que conferem, principalmente para fazer SNAT).

            E após a conexão estabelecida, o caminho de entrada de pacotes passa a ser:

     +-----------------+    +------------+    +------------+

     |PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +------------+    +------------+

pois os dados não precisam de tratamento DNAT (o chain PREROUTING-nat é processado somente uma vez a procura de regras que conferem, principalmente para fazer DNAT).

OBS: Para qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar outros aspectos especiais dos pacotes que atravessam os filtros.

Ping de 192.168.1.4 para 192.168.1.1

·       Endereço de Origem: 192.168.1.4

·       Endereço de Destino: 192.168.1.1

·       Interface de Entrada: eth0

·       Interface de Saída: eth0

·       Protocolo: ICMP

·       Descrição: Ping de 192.168.1.4 para a máquina do firewall.

     ENTRADA DE PACOTES (recebimento da requisição, vinda de 192.168.1.4):

     +-----------------+    +--------------+    +------------+    +------------+

     |PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +--------------+    +------------+    +------------+

    

     SAÍDA DE PACOTES (envio da resposta a 192.168.1.4)

     +-------------+    +-------------+    +------------------+

     |OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|

     +-------------+    +-------------+    +------------------+

            Quando damos o ping (echo request) os pacotes seguem o caminho em ENTRADA DE PACOTES percorrendo os chains na ordem especificada e retornam via SAÍDA DOS PACOTES (echo reply).

OBS1: Para qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar outros aspectos especiais dos pacotes que atravessam os filtros.

Conexão FTP de 192.168.1.4 para 192.168.1.1

·       Endereço de Origem: 192.168.1.4

·       Endereço de Destino: 192.168.1.1

·       Interface de Origem: eth0

·       Interface de Destino: eth0

·       Porta Origem: 1030

·       Porta Destino: 21

·       Protocolo: TCP

·       Descrição: Conexão ftp (até o prompt de login, sem transferência de dados).

     ENTRADA DOS PACOTES (envio da requisição vindas de 192.168.1.4):

     +-----------------+    +--------------+    +------------+    +------------+

     |PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +--------------+    +------------+    +------------+

    

     SAÍDA DE PACOTES (respostas da requisição acima para 192.168.1.4):

     +-------------+    +-------------+    +------------------+

     |OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|

     +-------------+    +-------------+    +------------------+

            A requisição ftp passa através dos chains especificados em ENTRADA DOS PACOTES com o destino 192.168.1.1 porta 21 e retorna por SAÍDA DE PACOTES para 192.168.1.4 porta 1030. Após a conexão ser estabelecida, o caminho de entrada de pacotes é:

     +-----------------+    +------------+    +------------+

     |PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +------------+    +------------+

pois os dados não precisam de tratamento DNAT (o chain PREROUTING-nat é processado somente uma vez a procura de regras que conferem, principalmente para fazer DNAT).

OBS: O roteamento é sempre realizado após o processamento do chain PREROUTING da tabela nat.

Conexão FTP de 192.168.1.4 para ftp.debian.org.br

·       Endereço de Origem: 192.168.1.4

·       Endereço de Destino: 200.198.129.162

·       Interface de Origem: eth0

·       Interface de Destino: ppp0

·       Porta Origem: 1032

·       Porta Destino: 21

·       Protocolo: TCP

·       Descrição: Conexão ftp (até o prompt de login, sem transferência de dados).

     SAÍDA DOS PACOTES (requisição vindas de 192.168.1.4):

     +-----------------+    +--------------+    +--------------+  

     |PREROUTING-mangle| => |PREROUTING-nat| => |FORWARD-mangle| => (continua abaixo)

     +-----------------+    +--------------+    +--------------+  

     +--------------+    +------------------+    +---------------+

     |FORWARD-filter| => |POSTROUTING-mangle| => |POSTROUTING-nat|

     +--------------+    +------------------+    +---------------+

    

     ENTRADA DE PACOTES (respostas da requisição acima, enviadas para 192.168.1.4):

     +-----------------+    +--------------+    +--------------+    +------------------+

     |PREROUTING-mangle| => |FORWARD-mangle| => |FORWARD-filter| => |POSTROUTING-mangle|

     +-----------------+    +--------------+    +--------------+    +------------------+

            A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES com o destino 200.198.129.162 porta 21 (após a resolução DNS de ftp.debian.org.br) e retorna por ENTRADA DE PACOTES para 192.168.1.4 porta 1032.

            Note que o Masquerading regrava os pacotes; para a máquina 200.198.129.162 a conexão está sendo feita para 200.217.29.67. As respostas de conexões vindas de 200.198.129.162 e indo para 200.217.29.67 são regravadas no firewall com o destino 192.168.1.4 e enviadas para a máquina correspondente. Após a conexão ser estabelecida, o caminho de saída de pacotes para 200.198.129.163 é:

     +-----------------+    +--------------+    +--------------+    +------------------+

     |PREROUTING-mangle| => |FORWARD-mangle| => |FORWARD-filter| => |POSTROUTING-mangle|

     +-----------------+    +--------------+    +--------------+    +------------------+

Após a conexão estabelecida, o caminho da entrada de pacotes vindos de 200.198.129.163 é:

     +-----------------+    +--------------+    +--------------+    +------------------+

     |PREROUTING-mangle| => |FORWARD-mangle| => |FORWARD-filter| => |POSTROUTING-mangle|

     +-----------------+    +--------------+    +--------------+    +------------------+

            Isto acontece porque após feita a conexão Masquerading (via PREROUTING-nat), o firewall já sabe como reescrever os pacotes para realizar a operação de Masquerading, reescrevendo todos os pacotes que chegam de www.debian.org.br para 192.168.1.4.

OBS: As conexões Masquerading feitas através da rede interna, são enviadas para 200.198.129.162 tem o endereço de origem ajustado para 200.217.29.67 que é o IP de nossa interface ppp0. Quando as respostas atravessam o firewall, os pacotes são checados pra saber se são uma resposta a uma conexão masquerading e fará a regravação dos pacotes substituindo o endereço de destino para 192.168.1.4. Caso uma operação de Masquerading falhe, os pacotes serão Bloqueados.

Conexão FTP de 200.198.129.162 para 200.217.29.167

·       Endereço de Origem: 200.198.129.162

·       Endereço de Destino: 200.217.29.67

·       Interface de Origem: ppp0

·       Interface de Destino: ppp0

·       Porta Origem: 3716

·       Porta Destino: 21

·       Protocolo: TCP

·       Descrição: Conexão ao serviço ftp do firewall

     ENTRADA DOS PACOTES (requisição vinda de 200.198.129.162):

     +-----------------+    +--------------+    +-------------+    +------------+

     |PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-mangle | => |INPUT-filter|

     +-----------------+    +--------------+    +-------------+    +------------+

    

     SAÍDA DE PACOTES (respostas da requisição de 200.198.129.162):

     +-------------+    +-------------+    +------------------+

     |OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|

     +-------------+    +-------------+    +------------------+

            A requisição ftp passa através dos chains especificados em ENTRADA DOS PACOTES com o destino 200.217.29.67 (nossa interface ppp0 local) porta 21 e retorna por SAÍDA DE PACOTES para 200.198.129.162 porta 3716 (também via ppp0). Após a conexão ser estabelecida, o caminho de entrada de pacotes é:

     +-----------------+    +------------+    +------------+

     |PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|

     +-----------------+    +------------+    +------------+

            Isto acontece porque após feita a análise do chain PREROUTING (para necessidade de DNAT), a máquina já saberá tomar a decisão apropriada para gerenciar aquela conexão.

Adonel  Bezerra

Pós-graduado em Teoria em Educação a Distância e Docência do Ensino Superior;

MBA Executivo em Coaching;

Coordenador de cursos de pós-graduação.

Experiência em Gestão de Negócios, envolvendo-se com as áreas administrativa, financeira, comercial, produção e logística;

Experiência de mais de 20 anos como professor conferencista na área de segurança da informação;

Sólida experiência na gestão de negócios e tecnologia da informação;

Sólida experiência no meio acadêmico; 

Consultor de Segurança da informação com mais de vinte anos de experiência;

Treinamentos e palestras ministrados para milhares de profissionais em todo o Brasil;

Livro publicado pela Editora Ciência Moderna e diversos artigos publicados.

 

ALGUMAS PARTICIPAÇÕES COMO CONFERENCISTA OU PALESTRANTE

Centro Universitário do Maranhão – UniCeuma/2009 – Apresentação “O MERCADO DE CONSULTORIA EM SEGURANÇA DE INFORMAÇÃO. 

Universidade de Fortaleza|UNIFOR – Apresentação “TÉCNICAS HACKERS PARA TESTES DE INVASÃO”.

Faculdades Integradas do Ceará – FIC/2010 – Apresentação “ SEGURANÇA DA INFORMAÇÃO”.

Escola de Gestão Pública do Estado do Ceará – /2012 – Apresentação “ SEGURANÇA DA INFORMAÇÃO COM SOFTWARE LIVRE”.

Faculdade La Salle – 2013 – Apresentação “ESPIONAGEM INTERNACIONAL”.

Estácio|FIC/2013 – Apresentação “ ANÁLISE DE VULNERABILIDADES COMO FATOR PRIMORDIAL NAS ORGANIZAÇÕES”.

Estácio|FIC/2015 – Apresentação “PROVA DE CONCEITO”.

Devry Brasil|FANOR Salvador/BA, Fortaleza/CE, Belém/PA, Caruaru/PE, Recife/PE, Teresina/PI    - Apresentação “ VULNERABILIDADES DE SISTEMAS COMPUTACIONAIS”.

 

PROJETO PESSOAL – 1998 – Até o momento

- Fundador e Mantenedor de um dos maiores portais de Segurança de sistema do Brasil, o portal Clube do Hacker; www.clubedohacker.com.br

Fundador e mantenedor da Academia Linux www.academialinux.com.br

Fundador da BUCOIN – www.bucoin.com.br