Introdu\u00e7\u00e3o
\nO Firewall \u00e9 um programa que como objetivo proteger a m\u00e1quina contra acessos indesejados,
\ntr\u00e1fego indesejado, proteger servi\u00e7os que estejam rodando na m\u00e1quina e bloquear a passagem de
\ncoisas que voc\u00ea n\u00e3o deseja receber (como conex\u00f5es vindas da Internet para sua segura rede local,
\nevitando acesso aos dados corporativos de uma empresa ou a seus dados pessoais). No kernel do
\nLinux 2.4, foi introduzido o firewall iptables (tamb\u00e9m chamado de netfilter) que substitui o
\nipchains dos kernels da s\u00e9rie 2.2. Este novo firewall tem como vantagem ser muito est\u00e1vel
\n(assim como o ipchains e ipfwadm), confi\u00e1vel, permitir muita flexibilidade na programa\u00e7\u00e3o de
\nregras pelo administrador do sistema, mais op\u00e7\u00f5es dispon\u00edveis ao administrador para controle de
\ntr\u00e1fego, controle independente do tr\u00e1fego da rede local\/entre redes\/interfaces devido a nova
\norganiza\u00e7\u00e3o das etapas de roteamento de pacotes.
\nO iptables \u00e9 um firewall em n\u00edvel de pacotes e funciona baseado no endere\u00e7o\/porta de
\norigem\/destino do pacote, prioridade, etc. Ele funciona atrav\u00e9s da compara\u00e7\u00e3o de regras para saber
\nse um pacote tem ou n\u00e3o permiss\u00e3o para passar. Em firewalls mais restritivos, o pacote \u00e9 bloqueado
\ne registrado para que o administrador do sistema tenha conhecimento sobre o que est\u00e1 acontecendo
\nem seu sistema.
\nEle tamb\u00e9m pode ser usado para modificar e monitorar o tr\u00e1fego da rede, fazer NAT (masquerading,
\nsource nat, destination nat), redirecionamento de pacotes, marca\u00e7\u00e3o de pacotes, modificar a
\nprioridade de pacotes que chegam\/saem do seu sistema, contagem de bytes, dividir tr\u00e1fego entre
\nm\u00e1quinas, criar prote\u00e7\u00f5es anti-spoofing, contra syn flood, DoS, etc. O tr\u00e1fego vindo de m\u00e1quinas
\ndesconhecidas da rede pode tamb\u00e9m ser bloqueado\/registrado atrav\u00e9s do uso de simples regras. As
\npossibilidades oferecidas pelos recursos de filtragem iptables como todas as ferramentas UNIX
\nmaduras dependem de sua imagina\u00e7\u00e3o, pois ele garante uma grande flexibilidade na manipula\u00e7\u00e3o
\ndas regras de acesso ao sistema, precisando apenas conhecer quais interfaces o sistema possui, o
\nque deseja bloquear, o que tem acesso garantido, quais servi\u00e7os devem estar acess\u00edveis para cada
\nrede, e iniciar a constru\u00e7\u00e3o de seu firewall.
\nO iptables ainda tem a vantagem de ser modulariz\u00e1vel, fun\u00e7\u00f5es podem ser adicionadas ao
\nfirewall ampliando as possibilidades oferecidas. Usei por 2 anos o ipchains e afirmo que este \u00e9
\num firewall que tem possibilidades de gerenciar tanto a seguran\u00e7a em m\u00e1quinas isoladas como
\nroteamento em grandes organiza\u00e7\u00f5es, onde a passagem de tr\u00e1fego entre redes deve ser
\nminuciosamente controlada.
\nUm firewall n\u00e3o funciona de forma autom\u00e1tica (instalando e esperar que ele fa\u00e7a as coisas por
\nvoc\u00ea), \u00e9 necess\u00e1rio pelo menos conhecimentos b\u00e1sicos de rede tcp\/ip, roteamento e portas para criar
\nas regras que far\u00e3o a seguran\u00e7a de seu sistema. A seguran\u00e7a do sistema depende do controle das
\nregras que ser\u00e3o criadas por voc\u00ea, as falhas humanas s\u00e3o garantia de mais de 95% de sucesso nas
\ninvas\u00f5es.
\nEnfim o iptables \u00e9 um firewall que agradar\u00e1 tanto a pessoas que desejam uma seguran\u00e7a b\u00e1sica
\nem seu sistema, quando administradores de grandes redes que querem ter um controle minucioso
\nsobre o tr\u00e1fego que passam entre suas interfaces de rede (controlando tudo o que pode passar de
\numa rede a outra), controlar o uso de tr\u00e1fego, monitora\u00e7\u00e3o, etc.
\n10.1.1 Vers\u00e3o
\n\u00c9 assumido que esteja usando a vers\u00e3o 1.2.3 do iptables e baseadas nas op\u00e7\u00f5es do kernel 2.4.16
\n(sem o uso de m\u00f3dulos experimentais). As explica\u00e7\u00f5es contidas aqui podem funcionar para vers\u00f5es
\nposteriores, mas \u00e9 recomend\u00e1vel que leia a documenta\u00e7\u00e3o sobre modifica\u00e7\u00f5es no programa
\n(changelog) em busca de mudan\u00e7as que alterem o sentido das explica\u00e7\u00f5es fornecidas aqui.
\n10.1.2 Um resumo da hist\u00f3ria do iptables
\nO iptables \u00e9 um c\u00f3digo de firewall das vers\u00f5es 2.4 do kernel, que substituiu o ipchains
\n(presente nas s\u00e9ries 2.2 do kernel). Ele foi inclu\u00eddo no kernel da s\u00e9rie 2.4 em meados de
\nJunho\/Julho de 1999.
\nA hist\u00f3ria do desenvolvimento (desde o porte do ipfw do BSD para o Linux at\u00e9 o iptables
\n(que \u00e9 a quarta gera\u00e7\u00e3o de firewalls do kernel) est\u00e1 dispon\u00edvel no documento, Netfilterhowto.
\n10.1.3 Caracter\u00edsticas do firewall iptables
\n\u2022 Especifica\u00e7\u00e3o de portas\/endere\u00e7o de origem\/destino
\n\u2022 Suporte a protocolos TCP\/UDP\/ICMP (incluindo tipos de mensagens icmp)
\n\u2022 Suporte a interfaces de origem\/destino de pacotes
\n\u2022 Manipula servi\u00e7os de proxy na rede
\n\u2022 Tratamento de tr\u00e1fego dividido em chains (para melhor controle do tr\u00e1fego que entra\/sai da
\nm\u00e1quina e tr\u00e1fego redirecionado.
\n\u2022 Permite um n\u00famero ilimitado de regras por chain
\n\u2022 Muito r\u00e1pido, est\u00e1vel e seguro
\n\u2022 Possui mecanismos internos para rejeitar automaticamente pacotes duvidosos ou mal
\nformados.
\n\u2022 Suporte a m\u00f3dulos externos para expans\u00e3o das funcionalidades padr\u00f5es oferecidas pelo
\nc\u00f3digo de firewall
\n\u2022 Suporte completo a roteamento de pacotes, tratadas em uma \u00e1rea diferente de tr\u00e1fegos
\npadr\u00f5es.
\n\u2022 Suporte a especifica\u00e7\u00e3o de tipo de servi\u00e7o para priorizar o tr\u00e1fego de determinados tipos de
\npacotes.
\n\u2022 Permite especificar exce\u00e7\u00f5es para as regras ou parte das regras
\n\u2022 Suporte a detec\u00e7\u00e3o de fragmentos
\n\u2022 Permite enviar alertas personalizados ao syslog sobre o tr\u00e1fego aceito\/bloqueado.
\n\u2022 Redirecionamento de portas
\n\u2022 Masquerading
\n\u2022 Suporte a SNAT (modifica\u00e7\u00e3o do endere\u00e7o de origem das m\u00e1quinas para um \u00fanico IP ou
\nfaixa de IP’s).
\n\u2022 Suporte a DNAT (modifica\u00e7\u00e3o do endere\u00e7o de destino das m\u00e1quinas para um \u00fanico IP ou
\nfixa de IP’s)
\n\u2022 Contagem de pacotes que atravessaram uma interface\/regra
\n\u2022 Limita\u00e7\u00e3o de passagem de pacotes\/confer\u00eancia de regra (muito \u00fatil para criar prote\u00e7\u00f5es
\ncontra, syn flood, ping flood, DoS, etc).
\n10.1.4 Ficha t\u00e9cnica
\nPacote: iptables
\n\u2022 iptables – Sistema de controle principal para protocolos ipv4
\n\u2022 ip6tables – Sistema de controle principal para protocolos ipv6
\n\u2022 iptables-save – Salva as regras atuais em um arquivo especificado como argumento.
\nEste utilit\u00e1rio pode ser dispensado por um shell script contendo as regras executado na
\ninicializa\u00e7\u00e3o da m\u00e1quina.
\n\u2022 iptables-restore – Restaura regras salvas pelo utilit\u00e1rio iptables-save.
\n10.1.5 Requerimentos
\n\u00c9 necess\u00e1rio que o seu kernel tenha sido compilado com suporte ao iptables (veja Habilitando o
\nsuporte ao iptables no kernel, Se\u00e7\u00e3o 10.1.15. O requerimento m\u00ednimo de mem\u00f3ria necess\u00e1ria para a
\nexecu\u00e7\u00e3o do iptables \u00e9 o mesmo do kernel 2.4 (4MB). Dependendo do tr\u00e1fego que ser\u00e1
\nmanipulado pela(s) interface(s) do firewall ele poder\u00e1 ser executado com folga em uma m\u00e1quina
\n386 SX com 4MB de RAM.
\nComo as configura\u00e7\u00f5es residem no kernel n\u00e3o \u00e9 necess\u00e1rio espa\u00e7o extra em disco r\u00edgido para a
\nexecu\u00e7\u00e3o deste utilit\u00e1rio.
\n10.1.6 Arquivos de logs criados pelo iptables
\nTodo tr\u00e1fego que for registrado pelo iptables \u00e9 registrado por padr\u00e3o no arquivo
\n\/var\/log\/kern.log.
\n10.1.7 Instala\u00e7\u00e3o
\napt-get install iptables
\nO pacote iptables cont\u00e9m o utilit\u00e1rio iptables (e ip6tables para redes ipv6) necess\u00e1rios
\npara inserir suas regras no kernel. Se voc\u00ea n\u00e3o sabe o que \u00e9 ipv6, n\u00e3o precisar\u00e1 se preocupar com o
\nutilit\u00e1rio ip6tables por enquanto.
\n10.1.8 Enviando Corre\u00e7\u00f5es\/Contribuindo com o projeto
\nA p\u00e1gina principal do projeto \u00e9 http:\/\/netfilter.filewatcher.org. Sugest\u00f5es podem
\nser enviadas para a lista de desenvolvimento oficial do iptables:
\nhttp:\/\/lists.samba.org.
\n10.1.9 O que aconteceu com o ipchains e ipfwadm?
\nO iptables faz parte da nova gera\u00e7\u00e3o de firewalls que acompanha o kernel 2.4, mas o suporte ao
\nipchains e ipfwadm ainda ser\u00e1 mantido atrav\u00e9s de m\u00f3dulos de compatibilidade do kernel at\u00e9
\n2004. Seria uma grande falta de considera\u00e7\u00e3o retirar o suporte a estes firewalls do kernel como
\nforma de obrigar a “aprenderem” o iptables (mesmo o suporte sendo removido ap\u00f3s este
\nper\u00edodo, acredito que criar\u00e3o patches “externos” para futuros kernels que n\u00e3o trar\u00e3o mais este
\nsuporte). Se precisa do suporte a estes firewalls antes de passar em definitivo para o iptables
\nleia Habilitando o suporte ao iptables no kernel, Se\u00e7\u00e3o 10.1.15.
\nSe voc\u00ea \u00e9 um administrador que gosta de explorar todos os recursos de um firewall, usa todos os
\nrecursos que ele oferece ou mant\u00e9m uma complexa rede corporativa, tenho certeza que gostar\u00e1 do
\niptables.
\n10.1.10 Tipos de firewalls
\nExistem basicamente dois tipos de firewalls:
\n\u2022 n\u00edvel de aplica\u00e7\u00e3o – Este tipo de firewall analisam o conte\u00fado do pacote para tomar
\nsuas decis\u00f5es de filtragem. Firewalls deste tipo s\u00e3o mais intrusivos (pois analisam o
\nconte\u00fado de tudo que passa por ele) e permitem um controle relacionado com o conte\u00fado do
\ntr\u00e1fego. Alguns firewalls em n\u00edvel de aplica\u00e7\u00e3o combinam recursos b\u00e1sicos existentes em
\nfirewalls em n\u00edvel de pacotes combinando as funcionalidade de controle de tr\u00e1fego\/controle
\nde acesso em uma s\u00f3 ferramenta. Servidores proxy, como o squid, s\u00e3o um exemplo deste
\ntipo de firewall.
\n\u2022 n\u00edvel de pacotes – Este tipo de firewall toma as decis\u00f5es baseadas nos par\u00e2metros do
\npacote, como porta\/endere\u00e7o de origem\/destino, estado da conex\u00e3o, e outros par\u00e2metros do
\npacote. O firewall ent\u00e3o pode negar o pacote (DROP) ou deixar o pacote passar (ACCEPT).
\nO iptables \u00e9 um excelente firewall que se encaixa nesta categoria.
\nFirewall em n\u00edvel de pacotes \u00e9 o assunto explicado nesta se\u00e7\u00e3o do guia mas ser\u00e1 apresentada
\numa explica\u00e7\u00e3o breve sobre o funcionamento de an\u00e1lise de strings do iptables.
\nOs dois tipos de firewalls podem ser usados em conjunto para fornecer uma camada dupla de
\nseguran\u00e7a no acesso as suas m\u00e1quinas\/m\u00e1quinas clientes.
\n10.1.11 O que proteger?
\nAntes de iniciar a constru\u00e7\u00e3o do firewall \u00e9 bom pensar nos seguintes pontos:
\n\u2022 Quais servi\u00e7os precisa proteger. Servi\u00e7os que devem ter acesso garantido a usu\u00e1rios externos
\ne quais ser\u00e3o bloqueados a todas\/determinadas m\u00e1quinas. \u00c9 recomend\u00e1vel bloquear o acesso
\na todas portas menores que 1024 por executarem servi\u00e7os que rodam com privil\u00e9gio de
\nusu\u00e1rio root, e autorizar somente o acesso as portas que realmente deseja (configura\u00e7\u00e3o
\nrestritiva nesta faixa de portas).
\n\u2022 Que tipo de conex\u00f5es eu posso deixar passar e quais bloquear. Servi\u00e7os com autentica\u00e7\u00e3o
\nem texto plano e potencialmente inseguros como rlogin, telnet, ftp, NFS, DNS, LDAP,
\nSMTP RCP, X-Window s\u00e3o servi\u00e7os que devem ser ter acesso garantido somente para
\nm\u00e1quinas\/redes que voc\u00ea confia. Estes servi\u00e7os podem n\u00e3o ser s\u00f3 usados para tentativa de
\nacesso ao seu sistema, mas tamb\u00e9m como forma de atacar outras pessoas aproveitando-se de
\nproblemas de configura\u00e7\u00e3o.
\nA configura\u00e7\u00e3o do firewall ajuda a prevenir isso, mesmo se um servi\u00e7o estiver mal
\nconfigurado e tentando enviar seus pacotes para fora, ser\u00e1 impedido. Da mesma forma se
\numa m\u00e1quina Windows de sua rede for infectada por um trojan n\u00e3o haver\u00e1 p\u00e2nico: o firewall
\npoder\u00e1 estar configurado para bloquear qualquer tentativa de conex\u00e3o vinda da internet
\n(cracker) para as m\u00e1quinas de sua rede.
\nPara c\u00f3pia de arquivos via rede insegura (como atrav\u00e9s da Internet), \u00e9 recomendado o uso de
\nservi\u00e7os que utilizam criptografia para login e transfer\u00eancia de arquivos (veja Servidor ssh,
\nCap\u00edtulo 15) ou a configura\u00e7\u00e3o de uma VPN.
\n\u2022 Que m\u00e1quinas ter\u00e3o acesso livre e quais ser\u00e3o restritas.
\n\u2022 Que servi\u00e7os dever\u00e3o ter prioridade no processamento.
\n\u2022 Que m\u00e1quinas\/redes NUNCA dever\u00e3o ter acesso a certas\/todas m\u00e1quinas.
\n\u2022 O volume de tr\u00e1fego que o servidor manipular\u00e1. Atrav\u00e9s disso voc\u00ea pode ter que balancear o
\ntr\u00e1fego entre outras m\u00e1quinas, configurar prote\u00e7\u00f5es contra DoS, syn flood, etc.
\n\u2022 O que tem permiss\u00e3o de passar de uma rede para outra (em m\u00e1quinas que atuam como
\nroteadores\/gateways de uma rede interna).
\n\u2022 Etc.
\nA an\u00e1lise destes pontos pode determinar a complexidade do firewall, custos de implementa\u00e7\u00e3o,
\nprazo de desenvolvimento e tempo de maturidade do c\u00f3digo para implementa\u00e7\u00e3o. Existem muitos
\noutros pontos que podem entrar na quest\u00e3o de desenvolvimento de um sistema de firewall, eles
\ndependem do tipo de firewall que est\u00e1 desenvolvendo e das pol\u00edticas de seguran\u00e7a de sua rede.
\n10.1.12 O que s\u00e3o regras?
\nAs regras s\u00e3o como comandos passados ao iptables para que ele realize uma determinada a\u00e7\u00e3o
\n(como bloquear ou deixar passar um pacote) de acordo com o endere\u00e7o\/porta de origem\/destino,
\ninterface de origem\/destino, etc. As regras s\u00e3o armazenadas dentro dos chains e processadas na
\nordem que s\u00e3o inseridas.
\nAs regras s\u00e3o armazenadas no kernel, o que significa que quando o computador for reiniciado tudo
\no que fez ser\u00e1 perdido. Por este motivo elas dever\u00e3o ser gravadas em um arquivo para serem
\ncarregadas a cada inicializa\u00e7\u00e3o.
\nUm exemplo de regra: iptables -A INPUT -s 123.123.123.1 -j DROP.
\n10.1.13 O que s\u00e3o chains?
\nOs Chains s\u00e3o locais onde as regras do firewall definidas pelo usu\u00e1rio s\u00e3o armazenadas para
\nopera\u00e7\u00e3o do firewall. Existem dois tipos de chains: os embutidos (como os chains INPUT,
\nOUTPUT e FORWARD) e os criados pelo usu\u00e1rio. Os nomes dos chains embutidos devem ser
\nespecificados sempre em mai\u00fasculas (note que os nomes dos chains s\u00e3o case-sensitive, ou seja, o
\nchain input \u00e9 completamente diferente de INPUT).
\n10.1.14 O que s\u00e3o tabelas?
\nTabelas s\u00e3o os locais usados para armazenar os chains e conjunto de regras com uma determinada
\ncaracter\u00edstica em comum. As tabelas podem ser referenciadas com a op\u00e7\u00e3o -t tabela e existem 3
\ntabelas dispon\u00edveis no iptables:
\n\u2022 filter – Esta \u00e9 a tabela padr\u00e3o, cont\u00e9m 3 chains padr\u00f5es:
\n\u2022 INPUT – Consultado para dados que chegam a m\u00e1quina
\n\u2022 OUTPUT – Consultado para dados que saem da m\u00e1quina
\n\u2022 FORWARD – Consultado para dados que s\u00e3o redirecionados para outra interface de
\nrede ou outra m\u00e1quina.
\nOs chains INPUT e OUTPUT somente s\u00e3o atravessados por conex\u00f5es indo\/se originando de
\nlocalhost.
\nOBS: Para conex\u00f5es locais, somente os chains INPUT e OUTPUT s\u00e3o consultados na tabela
\nfilter.
\n\u2022 nat – Usada para dados que gera outra conex\u00e3o (masquerading, source nat, destination nat,
\nport forwarding, proxy transparente s\u00e3o alguns exemplos). Possui 3 chains padr\u00f5es:
\n\u2022 PREROUTING – Consultado quando os pacotes precisam ser modificados logo que
\nchegam. \u00c9 o chain ideal para realiza\u00e7\u00e3o de DNAT e redirecionamento de portas
\n(Fazendo DNAT, Se\u00e7\u00e3o 10.4.4).
\n\u2022 OUTPUT – Consultado quando os pacotes gerados localmente precisam ser
\nmodificados antes de serem roteados. Este chain somente \u00e9 consultado para conex\u00f5es
\nque se originam de IPs de interfaces locais.
\n\u2022 POSTROUTING – Consultado quando os pacotes precisam ser modificados ap\u00f3s o
\ntratamento de roteamento. \u00c9 o chain ideal para realiza\u00e7\u00e3o de SNAT e IP
\nMasquerading (Fazendo SNAT, Se\u00e7\u00e3o 10.4.3).
\n\u2022 mangle – Utilizada para altera\u00e7\u00f5es especiais de pacotes (como modificar o tipo de servi\u00e7o
\n(TOS) ou outros detalhes que ser\u00e3o explicados no decorrer do cap\u00edtulo. Possui 2 chains
\npadr\u00f5es:
\n\u2022 INPUT – Consultado quando os pacotes precisam ser modificados antes de serem
\nenviados para o chain INPUT da tabela filter.
\n\u2022 FORWARD – Consultado quando os pacotes precisam ser modificados antes de serem
\nenviados para o chain FORWARD da tabela filter.
\n\u2022 PREROUTING – Consultado quando os pacotes precisam ser modificados antes de
\nser enviados para o chain PREROUTING da tabela nat.
\n\u2022 POSTROUTING – Consultado quando os pacotes precisam ser modificados antes de
\nserem enviados para o chain POSTROUTING da tabela nat.
\n\u2022 OUTPUT – Consultado quando os pacotes precisam ser modificados antes de serem
\nenviados para o chain OUTPUT da tabela nat.
\nVeja A tabela mangle, Se\u00e7\u00e3o 10.5 para mais detalhes sobre a tabela mangle.
\n10.1.15 Habilitando o suporte ao iptables no kernel
\nPara usar toda a funcionalidade do firewall iptables, permitindo fazer o controle do que tem ou
\nn\u00e3o permiss\u00e3o de acessar sua m\u00e1quina, fazer Masquerading\/NAT em sua rede, etc., voc\u00ea precisar\u00e1
\ndos seguintes componentes compilados em seu kernel (os m\u00f3dulos experimentais fora ignorados
\nintencionalmente):
\n*
\n* Network Options:
\n*
\nNetwork packet filtering (replaces ipchains) [Y\/m\/n\/?]
\nNetwork packet filtering debugging [Y\/m\/n\/?]
\ne na Subse\u00e7\u00e3o:
\n*
\n* IP: Netfilter Configuration
\n*
\nConnection tracking (required for masq\/NAT) (CONFIG_IP_NF_CONNTRACK)
\n[M\/n\/y\/?]
\nFTP protocol support (CONFIG_IP_NF_FTP) [M\/n\/?]
\nIRC protocol support (CONFIG_IP_NF_IRC) [M\/n\/?]
\nIP tables support (required for filtering\/masq\/NAT) (CONFIG_IP_NF_IPTABLES)
\n[Y\/m\/n\/?]
\nlimit match support (CONFIG_IP_NF_MATCH_LIMIT) [Y\/m\/n\/?]
\nMAC address match support (CONFIG_IP_NF_MATCH_MAC) [M\/n\/y\/?]
\nnetfilter MARK match support (CONFIG_IP_NF_MATCH_MARK) [M\/n\/y\/?]
\nMultiple port match support (CONFIG_IP_NF_MATCH_MULTIPORT) [M\/n\/y\/?]
\nTOS match support (CONFIG_IP_NF_MATCH_TOS) [M\/n\/y\/?]
\nLENGTH match support (CONFIG_IP_NF_MATCH_LENGTH) [M\/n\/y\/?]
\nTTL match support (CONFIG_IP_NF_TTL) [M\/n\/y\/?]
\ntcpmss match support (CONFIG_IP_NF_MATCH_TCPMSS) [M\/n\/y\/?]
\nConnection state match support (CONFIG_IP_NF_MATCH_STATE) [M\/n\/?]
\nPacket filtering (CONFIG_IP_NF_FILTER) [M\/n\/y\/?]
\nREJECT target support (CONFIG_IP_NF_TARGET_REJECT) [M\/n\/?]
\nFull NAT (CONFIG_IP_NF_NAT) [M\/n\/?]
\nMASQUERADE target support (CONFIG_IP_NF_TARGET_MASQUERADE) [M\/n\/?]
\nREDIRECT target support (CONFIG_IP_NF_TARGET_REDIRECT) [M\/n\/?]
\nPacket mangling (CONFIG_IP_NF_MANGLE) [M\/n\/y\/?]
\nTOS target support (CONFIG_IP_NF_TARGET_TOS) [M\/n\/?]
\nMARK target support (CONFIG_IP_NF_TARGET_MARK) [M\/n\/?]
\nLOG target support (CONFIG_IP_NF_TARGET_LOG) [M\/n\/y\/?]
\nTCPMSS target support (CONFIG_IP_NF_TARGET_TCPMSS) [M\/n\/y\/?]
\nEsta configura\u00e7\u00e3o permite que voc\u00ea n\u00e3o tenha problemas para iniciar o uso e configura\u00e7\u00e3o do seu
\nfirewall iptables, ela ativa os m\u00f3dulos necess\u00e1rios para utiliza\u00e7\u00e3o de todos os recursos do firewall
\niptables. Quando conhecer a fun\u00e7\u00e3o de cada um dos par\u00e2metros acima (durante o decorrer do
\ntexto), voc\u00ea poder\u00e1 eliminar muitas das op\u00e7\u00f5es desnecess\u00e1rias para seu estilo de firewall ou
\ncontinuar fazendo uso de todas \ud83d\ude09
\nOBS1: A configura\u00e7\u00e3o acima leva em considera\u00e7\u00e3o que voc\u00ea N\u00c3O executar\u00e1 os c\u00f3digos antigos de
\nfirewall ipfwadm e ipchains. Caso deseje utilizar o ipchains ou o ipfwadm, ser\u00e1 preciso
\nresponder com “M” a quest\u00e3o “IP tables support (required for filtering\/masq\/NAT)
\n(CONFIG_IP_NF_IPTABLES)”. Ser\u00e1 necess\u00e1rio carregar manualmente o m\u00f3dulo correspondente
\nao firewall que deseja utilizar (modprobe iptables_filter.o no caso do iptables).
\nN\u00e3o execute mais de um tipo de firewall ao mesmo tempo!!!
\nOBS2: \u00c9 recomend\u00e1vel ativar o daemon kmod para carga autom\u00e1tica de m\u00f3dulos, caso contr\u00e1rio
\nser\u00e1 necess\u00e1rio compilar todas as partes necess\u00e1rias embutidas no kernel, carregar os m\u00f3dulos
\nnecess\u00e1rios manualmente ou pelo iptables (atrav\u00e9s da op\u00e7\u00e3o –modprobe=m\u00f3dulo).
\n10.1.16 Ligando sua rede interna a Internet
\nSe a sua inten\u00e7\u00e3o (como da maioria dos usu\u00e1rios) \u00e9 conectar sua rede interna a Internet de forma
\nr\u00e1pida e simples, leia Fazendo IP masquerading (para os apressados), Se\u00e7\u00e3o 10.4.2 ou Fazendo
\nSNAT, Se\u00e7\u00e3o 10.4.3. Um exemplo pr\u00e1tico de configura\u00e7\u00e3o de Masquerading deste tipo \u00e9 encontrado
\nem Conectando sua rede interna a Internet, Se\u00e7\u00e3o 10.8.3.
\nAp\u00f3s configurar o masquerading, voc\u00ea s\u00f3 precisar\u00e1 especificar o endere\u00e7o IP da m\u00e1quina
\nmasquerading (servidor) como Gateway da rede. No Windows 9x\/NT\/2000 isto \u00e9 feito no
\nPainel de Controle\/Rede\/Propriedades de Tcp\/IP. No Linux pode ser feito com route add
\ndefault gw IP_do_Servidor.
\n10.2 Manipulando chains
\nO iptables trabalha com uma tabela de regras que \u00e9 analisada uma a uma at\u00e9 que a \u00faltima seja
\nprocessada. Por padr\u00e3o, se uma regra tiver qualquer erro, uma mensagem ser\u00e1 mostrada e ela
\ndescartada. O pacote n\u00e3o conferir\u00e1 e a a\u00e7\u00e3o final (se ele vai ser aceito ou rejeitado) depender\u00e1 das
\nregras seguintes.
\nAs op\u00e7\u00f5es passadas ao iptables usadas para manipular os chains s\u00e3o SEMPRE em mai\u00fasculas.
\nAs seguintes opera\u00e7\u00f5es podem ser realizadas:
\n10.2.1 Adicionando regras – A
\nComo exemplo vamos criar uma regra que bloqueia o acesso a nosso pr\u00f3pria m\u00e1quina (127.0.0.1 –
\nloopback). Primeiro daremos um ping para verificar seu funcionamento:
\n#ping 127.0.0.1
\nPING 127.0.0.1 (127.0.0.1): 56 data bytes
\n64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.6 ms
\n64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.5 ms
\n— 127.0.0.1 ping statistics —
\n2 packets transmitted, 2 packets received, 0% packet loss
\nround-trip min\/avg\/max = 0.5\/0.5\/0.6 ms
\nOk, a m\u00e1quina responde, agora vamos incluir uma regra no chain INPUT (-A INPUT) que bloqueie
\n(-j DROP) qualquer acesso indo ao endere\u00e7o 127.0.0.1 (-d 127.0.0.1):
\niptables -t filter -A INPUT -d 127.0.0.1 -j DROP
\nAgora verificamos um novo ping:
\n#ping 127.0.0.1
\nPING 127.0.0.1 (127.0.0.1): 56 data bytes
\n— 127.0.0.1 ping statistics —
\n2 packets transmitted, 0 packets received, 100% packet loss
\nDesta vez a m\u00e1quina 127.0.0.1 n\u00e3o respondeu, pois todos os pacotes com o destino 127.0.0.1 (-d
\n127.0.0.1) s\u00e3o rejeitados (-j DROP). A op\u00e7\u00e3o -A \u00e9 usada para adicionar novas regras no final do
\nchain. Al\u00e9m de -j DROP que serve para rejeitar os pacotes, podemos tamb\u00e9m usar -j ACCEPT para
\naceitar pacotes. A op\u00e7\u00e3o -j \u00e9 chamada de alvo da regra ou somente alvo pois define o destino do
\npacote que atravessa a regra (veja Especificando um alvo, Se\u00e7\u00e3o 10.3.6). Bem vindo a base de um
\nsistema de firewall \ud83d\ude42
\nOBS1: – O acesso a interface loopback n\u00e3o deve ser de forma alguma bloqueado, pois muitos
\naplicativos utilizam soquetes tcp para realizarem conex\u00f5es, mesmo que voc\u00ea n\u00e3o possua uma rede
\ninterna.
\nOBS2: – A tabela filter ser\u00e1 usada como padr\u00e3o caso nenhuma tabela seja especificada atrav\u00e9s da
\nop\u00e7\u00e3o -t.
\n10.2.2 Listando regras – L
\nA seguinte sintaxe \u00e9 usada para listar as regras criadas:
\niptables [-t tabela] -L [chain] [op\u00e7\u00f5es]
\nOnde:
\ntabela
\n\u00c9 uma das tabelas usadas pelo iptables. Se a tabela n\u00e3o for especificada, a tabela filter
\nser\u00e1 usada como padr\u00e3o. Veja O que s\u00e3o tabelas?, Se\u00e7\u00e3o 10.1.14 para detalhes.
\nchain
\nUm dos chains dispon\u00edveis na tabela acima (veja O que s\u00e3o tabelas?, Se\u00e7\u00e3o 10.1.14) ou criado
\npelo usu\u00e1rio (Criando um novo chain – N, Se\u00e7\u00e3o 10.2.6). Caso o chain n\u00e3o seja especificado,
\ntodos os chains da tabela ser\u00e3o mostrados.
\nop\u00e7\u00f5es
\nAs seguintes op\u00e7\u00f5es podem ser usadas para listar o conte\u00fado de chains:
\n\u2022 -v – Exibe mais detalhes sobre as regras criadas nos chains.
\n\u2022 -n – Exibe endere\u00e7os de m\u00e1quinas\/portas como n\u00fameros ao inv\u00e9s de tentar a resolu\u00e7\u00e3o
\nDNS e consulta ao \/etc\/services. A resolu\u00e7\u00e3o de nomes pode tomar muito
\ntempo dependendo da quantidade de regras que suas tabelas possuem e velocidade de
\nsua conex\u00e3o.
\n\u2022 -x – Exibe n\u00fameros exatos ao inv\u00e9s de n\u00fameros redondos. Tamb\u00e9m mostra a faixa de
\nportas de uma regra de firewall.
\n\u2022 –line-numbers – Exibe o n\u00famero da posi\u00e7\u00e3o da regra na primeira coluna da
\nlistagem.
\nPara listar a regra criada anteriormente usamos o comando:
\n#iptables -t filter -L INPUT
\nChain INPUT (policy ACCEPT)
\ntarget prot opt source destination
\nDROP all — anywhere localhost
\nO comando iptables -L INPUT -n tem o mesmo efeito, a diferen\u00e7a \u00e9 que s\u00e3o mostrados
\nn\u00fameros ao inv\u00e9s de nomes:
\n#iptables -L INPUT -n
\nChain INPUT (policy ACCEPT)
\ntarget prot opt source destination
\nDROP all — 0.0.0.0\/0 127.0.0.1
\n#iptables -L INPUT -n –line-numbers
\nChain INPUT (policy ACCEPT)
\nnum target prot opt source destination
\n1 DROP all — 0.0.0.0\/0 127.0.0.1
\n#iptables -L INPUT -n -v
\nChain INPUT (policy ACCEPT 78 packets, 5820 bytes)
\npkts bytes target prot opt in out source
\ndestination
\n2 194 DROP icmp — * * 0.0.0.0\/0
\n127.0.0.1
\nOs campos assim possuem o seguinte significado:
\nChain INPUT
\nNome do chain listado
\n(policy ACCEPT 78 packets, 5820 bytes)
\nPoliciamento padr\u00e3o do chain (veja Especificando o policiamento padr\u00e3o de um chain – P,
\nSe\u00e7\u00e3o 10.2.12).
\npkts
\nQuantidade de pacotes que atravessaram a regra (veja Zerando contador de bytes dos chains –
\nZ, Se\u00e7\u00e3o 10.2.11).
\nbytes
\nQuantidade de bytes que atravessaram a regra. Pode ser referenciado com K (Kilobytes), M
\n(Megabytes), G (Gigabytes).
\ntarget
\nO alvo da regra, o destino do pacote. Pode ser ACCEPT, DROP ou outro chain. Veja
\nEspecificando um alvo, Se\u00e7\u00e3o 10.3.6 para detalhes sobre a especifica\u00e7\u00e3o de um alvo.
\nprot
\nProtocolo especificado pela regra. Pode ser udp, tcp, icmp ou all. Veja Especificando um
\nprotocolo, Se\u00e7\u00e3o 10.3.3 para detalhes.
\nopt
\nOp\u00e7\u00f5es extras passadas a regra. Normalmente “!” (veja Especificando uma exce\u00e7\u00e3o, Se\u00e7\u00e3o
\n10.3.5) ou “f” (veja Especificando fragmentos, Se\u00e7\u00e3o 10.3.4).
\nin
\nInterface de entrada (de onde os dados chegam). Veja Especificando a interface de
\norigem\/destino, Se\u00e7\u00e3o 10.3.2.
\nout
\nInterface de sa\u00edda (para onde os dados v\u00e3o). Veja Especificando a interface de origem\/destino,
\nSe\u00e7\u00e3o 10.3.2.
\nsource
\nEndere\u00e7o de origem. Veja Especificando um endere\u00e7o de origem\/destino, Se\u00e7\u00e3o 10.3.1.
\ndestination
\nEndere\u00e7o de destino. Veja Especificando um endere\u00e7o de origem\/destino, Se\u00e7\u00e3o 10.3.1.
\noutras op\u00e7\u00f5es
\nEstas op\u00e7\u00f5es normalmente aparecem quando s\u00e3o usadas a op\u00e7\u00e3o -x:
\n\u2022 dpt ou dpts – Especifica a porta ou faixa de portas de destino.
\n\u2022 reject-with icmp-port-unreachable – Significa que foi usado o alvo
\nREJECT naquela regra (veja Alvo REJECT, Se\u00e7\u00e3o 10.3.6.1).
\n10.2.3 Apagando uma regra – D
\nPara apagar um chain, existem duas alternativas:
\n\u2022 Quando sabemos qual \u00e9 o n\u00famero da regra no chain (listado com a op\u00e7\u00e3o -L) podemos
\nreferenciar o n\u00famero diretamente. Por exemplo, para apagar a regra criada acima:
\niptables -t filter -D INPUT 1
\nEsta op\u00e7\u00e3o n\u00e3o \u00e9 boa quando temos um firewall complexo com um grande n\u00famero de regras por
\nchains, neste caso a segunda op\u00e7\u00e3o \u00e9 a mais apropriada.
\n\u2022 Usamos a mesma sintaxe para criar a regra no chain, mas trocamos -A por -D:
\niptables -t filter -D INPUT -d 127.0.0.1 -j DROP
\nEnt\u00e3o a regra correspondentes no chain INPUT ser\u00e1 automaticamente apagada (confira listando o
\nchain com a op\u00e7\u00e3o “-L”). Caso o chain possua v\u00e1rias regras semelhantes, somente a primeira ser\u00e1
\napagada.
\nOBS: N\u00e3o \u00e9 poss\u00edvel apagar os chains defaults do iptables (INPUT, OUTPUT…).
\n10.2.4 Inserindo uma regra – I
\nPrecisamos que o tr\u00e1fego vindo de 192.168.1.15 n\u00e3o seja rejeitado pelo nosso firewall. N\u00e3o
\npodemos adicionar uma nova regra (-A) pois esta seria inclu\u00edda no final do chain e o tr\u00e1fego seria
\nrejeitado pela primeira regra (nunca atingindo a segunda). A solu\u00e7\u00e3o \u00e9 inserir a nova regra antes da
\nregra que bloqueia todo o tr\u00e1fego ao endere\u00e7o 127.0.0.1 na posi\u00e7\u00e3o 1:
\niptables -t filter -I INPUT 1 -s 192.168.1.15 -d 127.0.0.1 -j
\nACCEPT
\nAp\u00f3s este comando, temos a regra inserida na primeira posi\u00e7\u00e3o do chain (repare no n\u00famero 1 ap\u00f3s
\nINPUT) e a antiga regra n\u00famero 1 passa a ser a n\u00famero 2. Desta forma a regra acima ser\u00e1
\nconsultada, se a m\u00e1quina de origem for 192.168.1.15 ent\u00e3o o tr\u00e1fego estar\u00e1 garantido, caso
\ncontr\u00e1rio o tr\u00e1fego com o destino 127.0.0.1 ser\u00e1 bloqueado na regra seguinte.
\n10.2.5 Substituindo uma regra – R
\nAp\u00f3s criar nossa regra, percebemos que a nossa inten\u00e7\u00e3o era somente bloquear os pings com o
\ndestino 127.0.0.1 (pacotes ICMP) e n\u00e3o havia necessidade de bloquear todo o tr\u00e1fego da
\nm\u00e1quina. Existem duas alternativas: apagar a regra e inserir uma nova no lugar ou modificar
\ndiretamente a regra j\u00e1 criada sem afetar outras regras existentes e mantendo a sua ordem no chain
\n(isso \u00e9 muito importante). Use o seguinte comando:
\niptables -R INPUT 2 -d 127.0.0.1 -p icmp -j DROP
\nO n\u00famero 2 \u00e9 o n\u00famero da regra que ser\u00e1 substitu\u00edda no chain INPUT, e deve ser especificado. O
\ncomando acima substituir\u00e1 a regra 2 do chain INPUT (-R INPUT 2) bloqueando (-j DROP)
\nqualquer pacote icmp (-p icmp) com o destino 127.0.0.1 (-d 127.0.0.1).
\n10.2.6 Criando um novo chain – N
\nEm firewalls organizados com um grande n\u00famero de regras, \u00e9 interessante criar chains individuais
\npara organizar regras de um mesmo tipo ou que tenha por objetivo analisar um tr\u00e1fego de uma
\nmesma categoria (interface, endere\u00e7o de origem, destino, protocolo, etc) pois podem consumir
\nmuitas linhas e tornar o gerenciamento do firewall confuso (e conseq\u00fcentemente causar s\u00e9rios
\nriscos de seguran\u00e7a). O tamanho m\u00e1ximo de um nome de chain \u00e9 de 31 caracteres e podem conter
\ntanto letras mai\u00fasculas quanto min\u00fasculas.
\niptables [-t tabela] [-N novochain]
\nPara criar o chain internet (que pode ser usado para agrupar as regras de internet) usamos o seguinte
\ncomando:
\niptables -t filter -N internet
\nPara inserir regras no chain internet basta especifica-lo ap\u00f3s a op\u00e7\u00e3o -A:
\niptables -t filter -A internet -s 200.200.200.200 -j DROP
\nE ent\u00e3o criamos um pulo (-j) do chain INPUT para o chain internet:
\niptables -t filter -A INPUT -j internet
\nOBS: O chain criando pelo usu\u00e1rio pode ter seu nome tanto em mai\u00fasculas como min\u00fasculas.
\nSe uma m\u00e1quina do endere\u00e7o 200.200.200.200 tentar acessar sua m\u00e1quina, o iptables consultar\u00e1
\nas seguintes regras:
\n`INPUT’ `internet’
\n—————————- —————————–
\n| Regra1: -s 192.168.1.15 | | Regra1: -s 200.200.200.200|
\n|————————–| |—————————|
\n| Regra2: -s 192.168.1.1 | | Regra2: -d 192.168.1.1 |
\n|————————–| —————————–
\n| Regra3: -j DROP |
\n—————————-
\nO pacote tem o endere\u00e7o de origem
\n200.200.200.200, ele passa pela
\nprimeira e segunda regras do chain
\nINPUT, a terceira regra direciona
\npara o chain internet
\n_______________________________________
\nv \/ v
\n\/————————-|-\\ \/ \/————————————-|
\n-\\
\n| Regra1: -s 192.168.1.15 | | \/ | Regra1: -s 200.200.200.200 -j
\nDROP \\_____\\
\n|————————-|-| \/
\n|—————————————| \/
\n| Regra2: -s 192.168.1.1 | | \/ | Regra2: -d 200.200.200.202 -j DROP
\n|
\n|————————-|-|\/ \\————————————–
\n-\/
\n| Regra3: -j internet \/|
\n|—————————| No chain internet, a primeira regra
\nconfere
\n| Regra4: -j DROP | com o endere\u00e7o de origem
\n200.200.200.200 e
\n\\—————————\/ o pacote \u00e9 bloqueado.
\nSe uma m\u00e1quina com o endere\u00e7o de origem 200.200.200.201 tentar acessar a
\nm\u00e1quina,
\nent\u00e3o as regra consultadas ser\u00e3o as seguintes:
\nO pacote tem o endere\u00e7o de origem
\n200.200.200.201, ele passa pela
\nprimeira e segunda regras do chain
\nINPUT, a terceira regra direciona
\npara o chain internet ______________________________________
\nv \/ v
\n\/————————-|-\\ \/ \/————————————-|
\n-\\
\n| Regra1: -s 192.168.1.15 | | \/ | Regra1: -s 200.200.200.200 -j DROP |
\n|
\n|————————-|-| \/
\n|————————————-|-|
\n| Regra2: -s 192.168.1.1 | | \/ | Regra2: -s 200.200.200.202 -j DROP |
\n|
\n|————————-|-|\/ \\————————————-|
\n-\/
\n| Regra3: -j internet \/| v
\n|—————————| \/
\n| Regra4: -j DROP –+——————————————-
\n\\————————\/-\/ O pacote passa pelas regras 1 e 2 do
\nchain
\n| internet, como ele n\u00e3o confere com
\nnenhuma
\nv das 2 regras ele retorna ao chain INPUT
\ne \u00e9
\nEsta regra \u00e9 a n\u00famero 4 analisado pela regra seguinte.
\nque diz para rejeitar o
\npacote.
\n10.2.7 Renomeando um chain criado pelo usu\u00e1rio – E
\nSe por algum motivo precisar renomear um chain criado por voc\u00ea na tabela filter, nat ou mangle,
\nisto poder\u00e1 ser feito usando a op\u00e7\u00e3o -E do iptables:
\niptables -t filter -E chain-antigo novo-chain
\nNote que n\u00e3o \u00e9 poss\u00edvel renomear os chains defaults do iptables.
\n10.2.8 Listando os nomes de todas as tabelas atuais
\nUse o comando cat \/proc\/net\/ip_tables_names para fazer isto. \u00c9 interessante dar uma
\nolhada nos arquivos dentro do diret\u00f3rio \/proc\/net, pois os arquivos existentes podem lhe
\ninteressar para outras finalidades.
\n10.2.9 Limpando as regras de um chain – F
\nPara limpar todas as regras de um chain, use a seguinte sintaxe:
\niptables [-t tabela] [-F chain]
\nOnde:
\ntabela
\nTabela que cont\u00e9m o chain que desejamos zerar.
\nchain
\nChain que desejamos limpar. Caso um chain n\u00e3o seja especificado, todos os chains da tabela
\nser\u00e3o limpos.
\niptables -t filter -F INPUT
\niptables -t filter -F
\n10.2.10 Apagando um chain criado pelo usu\u00e1rio – X
\nPara apagarmos um chain criado pelo usu\u00e1rio, usamos a seguinte sintaxe:
\niptables [-t tabela] [-X chain]
\nOnde:
\ntabela
\nNome da tabela que cont\u00e9m o chain que desejamos excluir.
\nchain
\nNome do chain que desejamos apagar. Caso n\u00e3o seja especificado, todos os chains definidos
\npelo usu\u00e1rio na tabela especificada ser\u00e3o exclu\u00eddos.
\nOBS: – Chains embutidos nas tabelas n\u00e3o podem ser apagados pelo usu\u00e1rio. Veja os nomes destes
\nchains em O que s\u00e3o tabelas?, Se\u00e7\u00e3o 10.1.14.
\niptables -t filter -X internet
\niptables -X
\n10.2.11 Zerando contador de bytes dos chains – Z
\nEste comando zera o campo pkts e bytes de uma regra do iptables. Estes campos podem ser
\nvisualizados com o comando iptables -L -v. A seguinte sintaxe \u00e9 usada:
\niptables [-t tabela] [-Z chain] [-L]
\nOnde:
\ntabela
\nNome da tabela que cont\u00e9m o chain que queremos zerar os contadores de bytes e pacotes.
\nchain
\nChain que deve ter os contadores zerados. Caso n\u00e3o seja especificado, todos os chains da
\ntabela ter\u00e3o os contadores zerados. Note que as op\u00e7\u00f5es -Z e -L podem ser usadas juntas, assim
\no chain ser\u00e1 listado e imediatamente zerado. Isto evita a passagem de pacotes durante a
\nlistagem de um chain.
\niptables -t filter -Z INPUT
\n10.2.12 Especificando o policiamento padr\u00e3o de um chain – P
\nO policiamento padr\u00e3o determina o que acontecer\u00e1 com um pacote quando ele chegar ao final das
\nregras contidas em um chain. O policiamento padr\u00e3o do iptables \u00e9 “ACCEPT” mas isto pode
\nser alterado com o comando:
\niptables [-t tabela] [-P chain] [ACCEPT\/DROP]
\nOnde:
\ntabela
\nTabela que cont\u00e9m o chain que desejamos modificar o policiamento padr\u00e3o.
\nchain
\nDefine o chain que ter\u00e1 o policiamento modificado. O chain deve ser especificado.
\nACCEPT\/DROP
\nACCEPT aceita os pacotes caso nenhuma regra do chain conferir (usado em regras
\npermissivas). DROP rejeita os pacotes caso nenhuma regra do chain conferir (usado em regras
\nrestritivas).
\nO policiamento padr\u00e3o de um chain \u00e9 mostrado com o comando iptables -L:
\n# iptables -L INPUT
\nChain INPUT (policy ACCEPT)
\ntarget prot opt source destination
\nDROP icmp — anywhere localhost
\nNo exemplo acima, o policiamento padr\u00e3o de INPUT \u00e9 ACCEPT (policy ACCEPT), o que significa
\nque qualquer pacote que n\u00e3o seja rejeitado pela regra do chain, ser\u00e1 aceito. Para alterar o
\npoliciamento padr\u00e3o deste chain usamos o comando:
\niptables -t filter -P INPUT DROP
\nNOTA: Os policiamentos PERMISSIVOS (ACCEPT) normalmente s\u00e3o usados em conjunto com
\nregras restritivas no chain correspondentes (tudo \u00e9 bloqueado e o que sobrar \u00e9 liberado) e
\npoliciamentos RESTRITIVOS (DROP) s\u00e3o usados em conjunto com regras permissivas no chain
\ncorrespondente (tudo \u00e9 liberado e o que sobrar \u00e9 bloqueado pelo policiamento padr\u00e3o).
\n10.3 Outras op\u00e7\u00f5es do iptables
\n10.3.1 Especificando um endere\u00e7o de origem\/destino
\nAs op\u00e7\u00f5es -s (ou –src\/–source)e -d (ou –dst\/–destination) servem para especificar endere\u00e7os de
\norigem e destino respectivamente. \u00c9 permitido usar um endere\u00e7o IP completo (como 192.168.1.1),
\num hostname (debian), um endere\u00e7o fqdn (www.debian.org) ou um par rede\/m\u00e1scara (como
\n200.200.200.0\/255.255.255.0 ou 200.200.200.0\/24).
\nCaso um endere\u00e7o\/m\u00e1scara n\u00e3o sejam especificados, \u00e9 assumido 0\/0 como padr\u00e3o (todos as
\nm\u00e1quinas de todas as redes). A interpreta\u00e7\u00e3o dos endere\u00e7os de origem\/destino dependem do chain
\nque est\u00e1 sendo especificado (como INPUT e OUTPUT por exemplo).
\nOBS: Caso seja especificado um endere\u00e7o fqdn e este resolver mais de um endere\u00e7o IP, ser\u00e3o
\ncriadas v\u00e1rias regras, cada uma se aplicando a este endere\u00e7o IP espec\u00edfico. \u00c9 recomend\u00e1vel sempre
\nque poss\u00edvel a especifica\u00e7\u00e3o de endere\u00e7os IP’s nas regras, pois al\u00e9m de serem muito r\u00e1pidos (pois
\nn\u00e3o precisar de resolu\u00e7\u00e3o DNS) s\u00e3o mais seguros para evitar que nosso firewall seja enganado por
\num ataque de IP spoofing.
\n# Bloqueia o tr\u00e1fego vindo da rede 200.200.200.*:
\niptables -A INPUT -s 200.200.200.0\/24 -j DROP
\n# Bloqueia conex\u00f5es com o destino 10.1.2.3:
\niptables -A OUTPUT -d 10.1.2.3 -j DROP
\n# Bloqueia o tr\u00e1fego da m\u00e1quina www.dominio.teste.org a rede 210.21.1.3
\n# nossa m\u00e1quina possui o endere\u00e7o 210.21.1.3
\niptables -A INPUT -s www.dominio.teste.org -d 210.21.1.3 -j DROP
\n10.3.2 Especificando a interface de origem\/destino
\nAs op\u00e7\u00f5es -i (ou –in-interface) e -o (ou –out-interface) especificam as interfaces de origem\/destino
\nde pacotes. Nem todos as chains aceitam as interfaces de origem\/destino simultaneamente, a
\ninterface de entrada (-i) nunca poder\u00e1 ser especificada em um chain OUTPUT e a interface de sa\u00edda
\n(-o) nunca poder\u00e1 ser especificada em um chain INPUT. Abaixo uma r\u00e1pida refer\u00eancia:
\n+———————+——————————–+
\nTABELA | CHAIN | INTERFACE |
\n| +—————-+—————+
\n| | ENTRADA (-i) | SA\u00cdDA (-o) |
\n+———+———————+—————-+—————+
\n| | INPUT | SIM | N\u00c3O |
\n| filter | OUTPUT | N\u00c3O | SIM |
\n| | FORWARD | SIM | SIM |
\n+———+———————+—————-+—————+
\n| | PREROUTING | SIM | N\u00c3O |
\n| nat | OUTPUT | N\u00c3O | SIM |
\n| | POSTROUTING | N\u00c3O | SIM |
\n+———+———————+—————-+—————+
\n| | PREROUTING | SIM | N\u00c3O |
\n| mangle | | | |
\n| | OUTPUT | N\u00c3O | SIM |
\n+———+———————+—————-+—————+
\nO caminho do pacote na interface ser\u00e1 determinado pelo tipo da interface e pela posi\u00e7\u00e3o dos chains
\nnas etapas de seu roteamento. O chain OUTPUT da tabela filter somente poder\u00e1 conter a interface
\nde sa\u00edda (veja a tabela acima). O chain FORWARD da tabela filter \u00e9 o \u00fanico que aceita a
\nespecifica\u00e7\u00e3o de ambas as interfaces, este \u00e9 um \u00f3timo chain para controlar o tr\u00e1fego que passa entre
\ninterfaces do firewall.
\nPor exemplo para bloquear o acesso do tr\u00e1fego de qualquer m\u00e1quina com o endere\u00e7o
\n200.123.123.10 vinda da interface ppp0 (uma placa de fax-modem):
\niptables -A INPUT -s 200.123.123.10 -i ppp0 -j DROP
\nA mesma regra pode ser especificada como
\niptables -A INPUT -s 200.123.123.10 -i ppp+ -j DROP
\nO sinal de “+” funciona como um coringa, assim a regra ter\u00e1 efeito em qualquer interface de ppp0 a
\nppp9. As interfaces ativas no momento podem ser listadas com o comando ifconfig, mas \u00e9
\npermitido especificar uma regra que faz refer\u00eancia a uma interface que ainda n\u00e3o existe, isto \u00e9
\ninteressante para conex\u00f5es intermitentes como o PPP. Para bloquear qualquer tr\u00e1fego local para a
\nInternet:
\niptables -A OUTPUT -o ppp+ -j DROP
\nPara bloquear a passagem de tr\u00e1fego da interface ppp0 para a interface eth1 (de uma de nossas redes
\ninternas):
\niptables -A FORWARD -i ppp0 -o eth1 -j DROP
\n10.3.3 Especificando um protocolo
\nA op\u00e7\u00e3o -p (ou –protocol) \u00e9 usada para especificar protocolos no iptables. Podem ser
\nespecificados os protocolos tcp, udp e icmp. Por exemplo, para rejeitar todos os pacotes UDP
\nvindos de 200.200.200.200:
\niptables -A INPUT -s 200.200.200.200 -p udp -j DROP
\nOBS1: Tanto faz especificar os nomes de protocolos em mai\u00fasculas ou min\u00fasculas.
\n10.3.3.1 Especificando portas de origem\/destino
\nAs portas de origem\/destino devem ser especificadas ap\u00f3s o protocolo e podem ser precedidas por
\numa das seguintes op\u00e7\u00f5es:
\n\u2022 –source-port ou –sport – Especifica uma porta ou faixa de portas de origem.
\n\u2022 –destination-port ou –dport – Especifica uma porta ou faixa de portas de
\ndestino.
\nUma faixa de portas pode ser especificada atrav\u00e9s de PortaOrigem:PortaDestino:
\n# Bloqueia qualquer pacote indo para 200.200.200.200 na faixa de
\n# portas 0 a 1023
\niptables -A OUTPUT -d 200.200.200.200 -p tcp –dport :1023 -j DROP
\nCaso a PortaOrigem de uma faixa de portas n\u00e3o seja especificada, 0 \u00e9 assumida como padr\u00e3o, caso
\na Porta Destino n\u00e3o seja especificada, 65535 \u00e9 assumida como padr\u00e3o. Caso precise especificar
\ndiversas regras que envolvam o tratamento de portas diferentes, recomendo da uma olhada em
\nEspecificando m\u00faltiplas portas de origem\/destino, Se\u00e7\u00e3o 10.6.6, antes de criar um grande n\u00famero
\nde regras.
\n10.3.3.2 Especificando mensagens do protocolo ICMP
\nO protocolo ICMP n\u00e3o possui portas, mas \u00e9 poss\u00edvel fazer um controle maior sobre o tr\u00e1fego ICMP
\nque entra\/sai da rede atrav\u00e9s da especifica\u00e7\u00e3o dos tipos de mensagens ICMP. Os tipos de mensagens
\ndevem ser especificados com a op\u00e7\u00e3o “–icmp-type C\u00f3digoICMP” logo ap\u00f3s a especifica\u00e7\u00e3o do
\nprotocolo icmp:
\niptables -A INPUT -s 200.123.123.10 -p icmp –icmp-type time-exceeded -i
\nppp+ -j DROP
\nA regra acima rejeitar\u00e1 mensagens ICMP do tipo “time-exceeded” (tempo de requisi\u00e7\u00e3o excedido)
\nque venham do endere\u00e7o 200.123.123.10 atrav\u00e9s da interface ppp+.
\nAlguns tipos de mensagens ICMP s\u00e3o classificados por categoria (como o pr\u00f3prio “timeexceeded”),
\ncaso a categoria “time-exceeded” seja especificada, todas as mensagens daquela
\ncategoria (como “ttl-zero-during-transit”, “ttl-zero-during-reassembly”) conferir\u00e3o na regra
\nespecificada.Os tipos de mensagens ICMP podem ser obtidos com o comando iptables -p
\nicmp -h:
\necho-reply (pong)
\ndestination-unreachable
\nnetwork-unreachable
\nhost-unreachable
\nprotocol-unreachable
\nport-unreachable
\nfragmentation-needed
\nsource-route-failed
\nnetwork-unknown
\nhost-unknown
\nnetwork-prohibited
\nhost-prohibited
\nTOS-network-unreachable
\nTOS-host-unreachable
\ncommunication-prohibited
\nhost-precedence-violation
\nprecedence-cutoff
\nsource-quench
\nredirect
\nnetwork-redirect
\nhost-redirect
\nTOS-network-redirect
\nTOS-host-redirect
\necho-request (ping)
\nrouter-advertisement
\nrouter-solicitation
\ntime-exceeded (ttl-exceeded)
\nttl-zero-during-transit
\nttl-zero-during-reassembly
\nparameter-problem
\nip-header-bad
\nrequired-option-missing
\ntimestamp-request
\ntimestamp-reply
\naddress-mask-request
\naddress-mask-reply
\nOBS1: N\u00e3o bloqueie mensagens do tipo “host-unreachable” e “source-quench”, pois ter\u00e1 s\u00e9rios
\nproblemas no controle de suas conex\u00f5es. A primeira diz que o destino est\u00e1 inalcan\u00e7avel e a segunda
\nque o host est\u00e1 sobrecarregado, assim os pacotes devem ser enviados mais lentamente.
\n10.3.3.3 Especificando pacotes syn
\nPacotes syn s\u00e3o usados para iniciarem uma conex\u00e3o, o uso da op\u00e7\u00e3o –syn serve para especificar
\nestes tipos de pacotes. Desta maneira \u00e9 poss\u00edvel bloquear somente os pacotes que iniciam uma
\nconex\u00e3o, sem afetar os pacotes restantes. Para que uma conex\u00e3o ocorra \u00e9 necess\u00e1rio que a m\u00e1quina
\nobtenha a resposta a pacotes syn enviados, caso ele seja bloqueado a resposta nunca ser\u00e1 retornada e
\na conex\u00e3o n\u00e3o ser\u00e1 estabelecida.
\niptables -A INPUT -p tcp –syn –dport 23 -i ppp+ -j DROP
\nA regra acima bloqueia (-j DROP) qualquer tentativa de conex\u00e3o (–syn) vindas da interface ppp+
\nao telnet (–dport 23) da m\u00e1quina local, conex\u00f5es j\u00e1 efetuadas \u00e3o s\u00e3o afetadas por esta regra. A
\nop\u00e7\u00e3o –syn somente pode ser especificada para o protocolo tcp.
\nATEN\u00c7\u00c3O: – A situa\u00e7\u00e3o de passagem de pacotes durante deve ser levada em conta durante a
\ninicializa\u00e7\u00e3o do firewall, bloqueando a passagem de pacotes durante o processo de configura\u00e7\u00e3o,
\ncriando regras que bloqueiam a passagem de pacotes (exceto para a interface loopback) at\u00e9 que a
\nconfigura\u00e7\u00e3o do firewall esteja completa, pode ser uma solu\u00e7\u00e3o eficiente.
\nOutra alternativa segura \u00e9 configurar as regras de firewall antes das interfaces de rede se tornarem
\nativas (usando a op\u00e7\u00e3o “pre-up comando_firewall” no arquivo de configura\u00e7\u00e3o
\n\/etc\/network\/interfaces em sistemas Debian.
\n10.3.4 Especificando fragmentos
\nA op\u00e7\u00e3o “-f” (ou –fragment) permite especificar regras que confiram com fragmentos. Fragmentos
\ns\u00e3o simplesmente um pacote maior dividido em peda\u00e7os para poder ser transmitido via rede TCP\/IP
\npara remontagem do pacote pela m\u00e1quina de destino.
\nSomente o primeiro fragmento possui detalhes de cabe\u00e7alho para ser processado, os segundos e
\nseguintes somente possuem alguns cabe\u00e7alhos necess\u00e1rios para dar continuidade ao processo de
\nremontagem do pacote no destino.
\nUma regra como
\niptables -A INPUT -s 200.200.200.1 -f -j DROP
\nderrubar\u00e1 os fragmentos de 200.200.200.1 derrubar\u00e1 o segundo pacote e pacotes seguintes enviados
\npor 200.200.200.1 at\u00e9 n\u00f3s.
\nOBS1: Note que se o cabe\u00e7alho do pacote n\u00e3o tiver detalhes suficientes para checagem de regras no
\niptables, a regra simplesmente n\u00e3o ira conferir.
\nOBS2: N\u00e3o \u00e9 preciso especificar a op\u00e7\u00e3o “-f” para conex\u00f5es NAT, pois os pacotes s\u00e3o remontados
\nantes de entrarem no c\u00f3digo de filtragem.
\nOBS3: A op\u00e7\u00e3o “-f” tamb\u00e9m pode ser usada para evitar o flood por fragmentos (bomba de
\nfragmentos) que, dependendo da intensidade, podem at\u00e9 travar a m\u00e1quina.
\n10.3.5 Especificando uma exce\u00e7\u00e3o
\nMuitos par\u00e2metros (como o endere\u00e7o de origem\/destino, protocolo, porta, mensagens ICMP,
\nfragmentos, etc) podem ser precedidos pelo sinal “!” que significa exce\u00e7\u00e3o. Por exemplo:
\niptables -t filter -A INPUT ! -s 200.200.200.10 -j DROP
\nDiz para rejeitar todos os pacotes EXCETO os que vem do endere\u00e7o 200.200.200.10.
\niptables -A INPUT -p tcp ! –syn -s 200.200.200.10 ! -i eth0 -j DROP
\nDiz para bloquear todos os pacotes EXCETO os que iniciam conex\u00f5es (! –syn), EXCETO para
\npacotes vindos pela interface eth0 (! -i eth0).
\niptables -A INPUT -s 200.200.200.10 ! -p tcp -j DROP
\nBloqueia todos os pacotes vindos de 200.200.200.10, EXCETO os do protocolo tcp.
\n10.3.6 Especificando um alvo
\nO alvo (-j) \u00e9 o destino que um pacote ter\u00e1 quando conferir com as condi\u00e7\u00f5es de uma regra, um alvo
\npode dizer para bloquear a passagem do pacote (-j DROP), aceitar a passagem do pacote (-j
\nACCEPT), registrar o pacote no sistema de log (-j LOG), rejeitar o pacote (-j REJECT),
\nredirecionar um pacote -j REDIRECT, retornar ao chain anterior sem completar o processamento no
\nchain atual (-j RETURN), passar para processamento de programas externos (-j QUEUE), fazer
\nsource nat (-j SNAT), destination nat (-j DNAT), etc. Podem existir mais alvos, pois o iptables \u00e9
\nmodulariz\u00e1vel, e m\u00f3dulos que acrescentam mais fun\u00e7\u00f5es podem ser carregados em adi\u00e7\u00e3o aos j\u00e1
\nexistentes no kernel.
\nNos exemplos anteriores vimos o uso de diversos alvos como o DROP e o ACCEPT. Apenas farei
\numa breve refer\u00eancia sobre os alvos mais usados em opera\u00e7\u00f5es comuns dos chains. Os alvos
\nREDIRECT, SNAT e DNAT ser\u00e3o explicados em uma se\u00e7\u00e3o seguinte:
\nACCEPT
\nO pacote \u00e9 ACEITO e o processamento das regras daquele chains \u00e9 conclu\u00eddo. Pode ser usado
\ncomo alvo em todos os chains de todas as tabelas do iptables e tamb\u00e9m pode ser
\nespecificado no policiamento padr\u00e3o das regras do firewall (veja Especificando o
\npoliciamento padr\u00e3o de um chain – P, Se\u00e7\u00e3o 10.2.12).
\nDROP
\nRejeita o pacote e o processamento das regras daquele chain \u00e9 conclu\u00eddo. Pode ser usado
\ncomo alvo em todos os chains de todas as tabelas do iptables e tamb\u00e9m pode ser
\nespecificado no policiamento padr\u00e3o das regras do firewall (veja Especificando o
\npoliciamento padr\u00e3o de um chain – P, Se\u00e7\u00e3o 10.2.12).
\nREJECT
\nEste \u00e9 um m\u00f3dulo opcional que faz a mesma fun\u00e7\u00e3o do alvo DROP com a diferen\u00e7a de que
\numa mensagem ICMP do tipo “icmp-port-unreachable” (TCP\/UDP) ou “host-unreachable”
\n(ICMP) \u00e9 retornada para a m\u00e1quina de origem. Pode ser usado como alvo somente nos chains
\nda tabela (n\u00e3o como policiamento padr\u00e3o).
\nLOG
\nEste m\u00f3dulo envia uma mensagem ao syslog caso a regra confira, o processamento
\ncontinua normalmente para a pr\u00f3xima regra (o pacote n\u00e3o \u00e9 nem considerado ACEITO ou
\nREJEITADO).
\nRETURN
\nRetorna o processamento do chain anterior sem processar o resto do chain atual.
\nQUEUE
\nPassa o processamento para um programa a n\u00edvel de usu\u00e1rio.
\n10.3.6.1 Alvo REJECT
\nPara ser usado, o m\u00f3dulo ipt_REJECT deve ser compilado no kernel ou como m\u00f3dulo. Este alvo
\nrejeita o pacote (como o DROP) e envia uma mensagem ICMP do tipo “icmp-port-unreachable”
\ncomo padr\u00e3o para a m\u00e1quina de origem.
\n\u00c9 um alvo interessante para bloqueio de portas TCP, pois em alguns casos da a impress\u00e3o que a
\nm\u00e1quina n\u00e3o disp\u00f5e de um sistema de firewall (o alvo DROP causa uma parada de muito tempo em
\nalguns portscanners e tentativas de conex\u00e3o de servi\u00e7os, revelando imediatamente o uso de um
\nsistema de firewall pela m\u00e1quina). O alvo REJECT vem dos tempos do ipchains e somente pode ser
\nusado na tabela filter. Quando um pacote confere, ele \u00e9 rejeitado com a mensagem ICMP do tipo
\n“port unreachable”, \u00e9 poss\u00edvel especificar outro tipo de mensagem ICMP com a op\u00e7\u00e3o –reject-with
\ntipo_icmp.
\nOBS: REJECT pode ser usado somente como alvo na tabela filter e n\u00e3o \u00e9 poss\u00edvel especifica-lo
\ncomo policiamento padr\u00e3o do chain filter (como acontecia no ipchains. Uma forma alternativa \u00e9
\ninserir como \u00faltima regra uma que pegue todos os pacotes restantes daquele chain e tenha como
\nalvo REJECT (como iptables -A INPUT -j REJECT), desta forma ele nunca atingir\u00e1 o
\npoliciamento padr\u00e3o do chain.
\n# Rejeita pacotes vindos de 200.200.200.1 pela interface ppp0:
\niptables -A INPUT -s 200.200.200.1 -i ppp+ -j REJECT
\n10.3.6.2 Especificando LOG como alvo
\nEste alvo \u00e9 usado para registrar a passagem de pacotes no syslog do sistema. \u00c9 um alvo muito
\ninteressante para ser usado para regras que bloqueiam determinados tr\u00e1fegos no sistema (para que o
\nadministrador tome conhecimento sobre tais tentativas), para regras de fim de chain (quando voc\u00ea
\ntem um grande conjunto de regras em um firewall restritivo e n\u00e3o sabe onde suas regras est\u00e3o sendo
\nbloqueadas), para satisfazer sua curiosidade, etc.
\n# Para registrar o bloqueio de pacotes vindos de 200.200.200.1 pela
\ninterface ppp0
\niptables -A INPUT -s 200.200.200.1 -i ppp+ -j LOG
\n# Para efetuar o bloqueio
\niptables -A INPUT -s 200.200.200.1 -i ppp+ -j REJECT
\nNote que no exemplo anterior a regra que registra o pacote (-j LOG) deve aparecer antes da regra
\nque REJEITA (-j REJECT), caso contr\u00e1rio a regra de LOG nunca funcionar\u00e1. A regra que REJEITA
\npoderia tamb\u00e9m ser trocada por uma regra que ACEITA, caso queira registrar um pacote que deve
\nser aceito (se o policiamento padr\u00e3o do seu firewall for restritivo (-P DROP). A \u00fanica coisa que
\nmuda nas regras de log \u00e9 o alvo da regra, isto facilita a implementa\u00e7\u00e3o de grandes conjuntos de
\nregras de firewall.
\nA regra acima mostrar\u00e1 a seguinte sa\u00edda no syslog do sistema:
\nAug 25 10:08:01 debian kernel: IN=ppp0 OUT=
\nMAC=10:20:30:40:50:60:70:80:90:00:00:00:08:00 SRC=200.200.200.1
\nDST=200.210.10.10 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1031
\nDPT=53 LEN=41
\nOs campos possuem o seguinte significado:
\nAug 25 10:08:01
\nM\u00eas, dia e hora do registro do pacote.
\ndebian
\nNome do computador que registrou o pacote.
\nkernel:
\nDaemon que registrou a mensagem, no caso o iptables faz parte do pr\u00f3prio kernel.
\nIN=ppp0
\nEspecifica a interface de entrada (de onde o pacote veio).
\nOUT=
\nEspecifica a interface de sa\u00edda (para onde o pacote foi).
\nMAC=10:20:30:40:50:60:70:80:90:00:00:00:08:00
\nEndere\u00e7o mac da interface de rede (pode ser obtido com arp interface).
\nSRC=200.200.200.1
\nEndere\u00e7o de origem do pacote.
\nDST=200.210.10.10
\nEndere\u00e7o de destino do pacote.
\nSEQ=234234343
\nN\u00famero de seq\u00fc\u00eancia da recep\u00e7\u00e3o. \u00c9 ativado com a op\u00e7\u00e3o –log-tcp-sequence.
\nLEN=61
\nTamanho em bytes do pacote IP.
\nTOS=0x00
\nPrioridade do cabe\u00e7alho TOS (Tipo). Veja a se\u00e7\u00e3o Especificando o tipo de servi\u00e7o, Se\u00e7\u00e3o
\n10.5.1 para mais detalhes.
\nPREC=0x00
\nPrioridade do cabe\u00e7alho TOS (Preced\u00eancia). Veja a se\u00e7\u00e3o Especificando o tipo de servi\u00e7o,
\nSe\u00e7\u00e3o 10.5.1 para mais detalhes.
\nTTL=64
\nTempo de vida do pacote. No exemplo, 64 roteadores (hops).
\nID=0
\nIdentifica\u00e7\u00e3o \u00fanica destes datagrama. Esta identifica\u00e7\u00e3o tamb\u00e9m \u00e9 usada pelos fragmentos
\nseguintes deste pacote.
\nDF
\nOp\u00e7\u00e3o “Don’t fragment” (n\u00e3o fragmentar) do pacote. Usada quando o pacote \u00e9 pequeno o
\nbastante para n\u00e3o precisar ser fragmentado.
\nMF
\nOp\u00e7\u00e3o “More Fragments” (mais fragmentos) est\u00e3o para ser recebidos.
\nFRAG=100
\nTamanho do fragmento especificado em pacotes de 8 bits. No exemplo acima, o pacote tem o
\ntamanho de 800 bytes (100*8).
\nPROTO=UDP
\nNome do protocolo. Pode ser TCP, UDP ou ICMP
\nSPT=1031
\nPorta de origem da requisi\u00e7\u00e3o.
\nDPT=53
\nPorta de destino da requisi\u00e7\u00e3o.
\nLEN=41
\nTamanho do pacote.
\nO log acima mostra uma consulta DNS (porta destino 53) para nossa m\u00e1quina (INPUT) de
\n200.200.200.1 para 200.210.10.10.
\nO problema \u00e9 que em um grande n\u00famero de regras ser\u00e1 dif\u00edcil saber qual regra conferiu (pois
\nter\u00edamos que analisar o endere\u00e7o\/porta origem\/destino) e o destino do pacote (se ele foi ACEITO ou
\nBLOQUEADO) pois voc\u00ea pode ter regras para ambas as situa\u00e7\u00f5es. Por este motivo existem
\nalgumas op\u00e7\u00f5es \u00fateis que podemos usar com o alvo LOG:
\n–log-prefix “descri\u00e7\u00e3o”
\nPermite especificar uma descri\u00e7\u00e3o para a regra do firewall de at\u00e9 29 caracteres. Caso tiver
\nespa\u00e7os, devem ser usadas “aspas”.
\n–log-level n\u00edvel
\nEspecifica o n\u00edvel da mensagem no syslog.
\n–log-tcp-options
\nRegistra campos do cabe\u00e7alho TCP nos logs do sistema.
\n–log-ip-options
\nRegistra campos do cabe\u00e7alho IP nos logs do sistema
\n–log-tcp-sequence
\nRegistra os n\u00fameros de seq\u00fcencia TCP. Evite ao m\u00e1ximo o uso desta op\u00e7\u00e3o, pois a seq\u00fcencia
\nde n\u00fameros TCP pode ser a chave para um seq\u00fcestro de se\u00e7\u00e3o ou IP spoofing em seu sistema
\ncaso algum usu\u00e1rio tenha acesso a estes logs. Caso utilize tcp\/ip em servidores p\u00fablicos, o uso
\ndesta op\u00e7\u00e3o ajudar\u00e1 a entender bem os ataques DoS causados por syn-flood e porque ativar os
\nSynCookies (veja Prote\u00e7\u00e3o contra syn flood, Se\u00e7\u00e3o 10.6.4).
\nOBS1:Lembre-se que estas op\u00e7\u00f5es s\u00e3o referentes ao alvo LOG e devem ser usadas ap\u00f3s este, caso
\ncontr\u00e1rio voc\u00ea ter\u00e1 um pouco de trabalho para analisar e consertar erros em suas regras do firewall.
\nOBS2:Caso esteja usando o firewall em um servidor p\u00fablico, recomendo associar um limite a regra
\nde log, pois um ataque poderia causar um DoS enchendo sua parti\u00e7\u00e3o. Leia mais sobre isso em
\nLimitando o n\u00famero de vezes que a regra confere, Se\u00e7\u00e3o 10.6.2.
\n# Complementando o exemplo anterior:
\n# Para registrar o bloqueio de pacotes vindos de 200.200.200.1 pela
\ninterface ppp0
\niptables -A INPUT -s 200.200.200.1 -i ppp+ -j LOG –log-prefix “FIREWALL:
\nDerrubado ”
\n# Para efetuar o bloqueio
\niptables -A INPUT -s 200.200.200.1 -i ppp+ -j REJECT
\nRetornar\u00e1 a seguinte mensagem no syslog:
\nAug 25 10:08:01 debian kernel: FIREWALL: Derrubado IN=ppp0 OUT=
\nMAC=10:20:30:40:50:60:70:80:90:00:00:00:08:00 SRC=200.200.200.1
\nDST=200.210.10.10 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1031
\nDPT=53 LEN=41
\nAgora voc\u00ea sabe o que aconteceu com o pacote (Rejeitado). A padroniza\u00e7\u00e3o de mensagens de
\nfirewall \u00e9 tamb\u00e9m importante para a cria\u00e7\u00e3o de scripts de an\u00e1lise que poder\u00e3o fazer a an\u00e1lise dos
\nlogs do seu firewall (para cria\u00e7\u00e3o de estat\u00edsticas que podem servir como base para a cria\u00e7\u00e3o de
\nnovas regras de firewall ou elimina\u00e7\u00e3o de outras).
\nOBS: Se voc\u00ea sente falta da fun\u00e7\u00e3o “-l” do ipchains que combina o alvo e log na mesma regra
\nvoc\u00ea pode criar um alvo como o seguinte:
\niptables -N log-drop
\niptables -A log-drop -j LOG
\niptables -A log-drop -j DROP
\nE usar “log-drop” como alvo em suas regras. Mesmo assim esta solu\u00e7\u00e3o \u00e9 “limitada” em rela\u00e7\u00e3o a “-
\nl” do ipchains porque o iptables n\u00e3o inclui detalhes de qual chain bloqueou o pacote\/qual
\npacote foi bloqueado, assim \u00e9 necess\u00e1rio a especifica\u00e7\u00e3o da op\u00e7\u00e3o –log-prefix para as mensagens se
\ntornarem mais compreens\u00edveis. Esta limita\u00e7\u00e3o pode ser contornada utilizando um firewall feito em
\nlinguagem shell script, desta forma voc\u00ea ter\u00e1 um controle maior sobre o seu programa usando
\nfun\u00e7\u00f5es e integra\u00e7\u00e3o com outros utilit\u00e1rios.
\n10.3.6.3 Especificando RETURN como alvo
\nO alvo RETURN diz ao iptables interromper o processamento no chain atual e retornar o
\nprocessamento ao chain anterior. Ele \u00e9 \u00fatil quando criamos um chain que faz um determinado
\ntratamento de pacotes, por exemplo bloquear conex\u00f5es vindas da internet para portas baixas, exceto
\npara um endere\u00e7o IP espec\u00edfico. Como segue:
\n1-) iptables -t filter -A INPUT -i ppp0 -j internet
\n2-) iptables -t filter -j ACCEPT
\n3-) iptables -t filter -N internet
\n4-) iptables -t filter -A internet -s www.debian.org -p tcp –dport 80 -j
\nRETURN
\n5-) iptables -t filter -A internet -p tcp –dport 21 -j DROP
\n6-) iptables -t filter -A internet -p tcp –dport 23 -j DROP
\n7-) iptables -t filter -A internet -p tcp –dport 25 -j DROP
\n\ud83d\ude0e iptables -t filter -A internet -p tcp –dport 80 -j DROP
\nQuando um pacote com o endere\u00e7o www.debian.org tentando acessar a porta www (80) de
\nnossa m\u00e1quina atrav\u00e9s da internet (via interface ppp0), o chain n\u00famero 1 confere, ent\u00e3o o
\nprocessamento continua no chain n\u00famero 4, o chain n\u00famero 4 confere ent\u00e3o o processamento volta
\npara a regra n\u00famero 2, que diz para aceitar o pacote.
\nAgora se um pacote vem com o endere\u00e7o www.dominio.com.br tentando acessar a porta www
\n*80) de nossa m\u00e1quina atrav\u00e9s da internet (via interface ppp0), o chain n\u00famero 1 confere, ent\u00e3o o
\nprocessamento continua no chain n\u00famero 4, que n\u00e3o confere. O mesmo acontece com os chains 5, 6
\ne 7. O chain n\u00famero 8 confere, ent\u00e3o o acesso \u00e9 bloqueado.
\nComo pode notou, o alvo RETURN facilita bastante a constru\u00e7\u00e3o das regras do seu firewall, caso
\nexistam m\u00e1quinas\/redes que sejam exce\u00e7\u00f5es as suas regras. Se ela n\u00e3o existisse, seria necess\u00e1rio
\nespecificar diversas op\u00e7\u00f5es -s, -d, etc para poder garantir o acesso livre a determinadas m\u00e1quinas.
\n10.3.7 Salvando e Restaurando regras
\nAs regras que voc\u00ea est\u00e1 trabalhosamente criando e testando manualmente enquanto manipula o
\niptables podem ser salvas de 2 formas; uma delas \u00e9 escrevendo um shell script que tenha todos
\nos comandos, um por linha. Isto \u00e9 recomendado quando tem um firewall grande e que exige uma
\nboa padroniza\u00e7\u00e3o de regras, bem como sua leitura, coment\u00e1rios. O script shell tamb\u00e9m permite o
\nuso de fun\u00e7\u00f5es presente no interpretador de comando, portanto se voc\u00ea \u00e9 uma pessoa que gosta de
\ninteragir com as fun\u00e7\u00f5es do shell e deixar as coisas mais flex\u00edveis, prefira esta op\u00e7\u00e3o.
\nA outra forma \u00e9 usando as ferramentas iptables-save e iptables-restore baseada na
\nid\u00e9ia do ipchains-save e ipchains-restore. O iptables-save deve ser usado
\nsempre que modificar regras no firewall iptables da seguinte forma:
\niptables-save >\/dir\/iptables-regras
\nUma das vantagens do uso do iptables-save \u00e9 ele tamb\u00e9m salvar os contadores de chains, ou
\nseja, a quantidade de pacotes que conferiram com a regra. Isto tamb\u00e9m pode ser feito com algumas
\nregras adicionais em seu shell script, caso tenha interesse nesses contadores para estat\u00edsticas ou
\noutros tipos de relat\u00f3rios.
\nPara restaurar as regras salvas, utilize o comando:
\niptables-restore <\/dir\/iptables-regras
\n10.4 A tabela nat (Network Address Translation) – fazendo nat
\nA tabela nat serve para controlar a tradu\u00e7\u00e3o dos endere\u00e7os que atravessam o c\u00f3digo de roteamento
\nda m\u00e1quina Linux. Existem 3 chains na tabela nat: PREROUTING, OUTPUT e POSTROUTING
\n(veja O que s\u00e3o tabelas?, Se\u00e7\u00e3o 10.1.14 para maiores detalhes).
\nA tradu\u00e7\u00e3o de endere\u00e7os tem in\u00fameras utilidades, uma delas \u00e9 o Masquerading, onde m\u00e1quinas de
\numa rede interna podem acessar a Internet atrav\u00e9s de uma m\u00e1quina Linux, redirecionamento de
\nporta, proxy transparente, etc. Esta se\u00e7\u00e3o abordar\u00e1 os tipos de NAT, exemplos de como criar
\nrapidamente uma conex\u00e3o IP masquerading e entender como a tradu\u00e7\u00e3o de endere\u00e7os funciona no
\niptables.
\nSe sua inten\u00e7\u00e3o \u00e9 ligar sua rede a Internet existem duas op\u00e7\u00f5es:
\n\u2022 Voc\u00ea possui uma conex\u00e3o que lhe oferece um endere\u00e7o IP din\u00e2mico (a cada conex\u00e3o \u00e9 dado
\num endere\u00e7o IP – como uma conex\u00e3o PPP) ent\u00e3o o IP masquerading \u00e9 o que precisa (veja
\nFazendo IP masquerading (para os apressados), Se\u00e7\u00e3o 10.4.2 ou Fazendo IP Masquerading,
\nSe\u00e7\u00e3o 10.4.3.1).
\n\u2022 Voc\u00ea tem uma conex\u00e3o que lhe oferece um endere\u00e7o IP permanente (ADSL, por exemplo)
\nent\u00e3o o SNAT \u00e9 o que precisa (veja Fazendo SNAT, Se\u00e7\u00e3o 10.4.3).
\n10.4.1 Criando um novo chain na tabela NAT
\nO procedimento para cria\u00e7\u00e3o de um novo chain nesta tabela \u00e9 o mesmo descrito em Criando um
\nnovo chain – N, Se\u00e7\u00e3o 10.2.6 ser\u00e1 necess\u00e1rio somente especificar a tabela nat (-t nat) para que o
\nnovo chain n\u00e3o seja criado na tabela padr\u00e3o (-t filter).
\niptables -t nat -N intra-inter
\nQue criar\u00e1 o chain chamado intra-inter na tabela nat. Para inserir regras neste chain ser\u00e1 necess\u00e1rio
\nespecificar a op\u00e7\u00e3o “-t nat”.
\n10.4.2 Fazendo IP masquerading (para os apressados)
\nVoc\u00ea precisar\u00e1 de um kernel com suporte ao iptables (veja Habilitando o suporte ao iptables no
\nkernel, Se\u00e7\u00e3o 10.1.15 e ip_forward e ent\u00e3o digitar os dois comandos abaixo para habilitar o
\nmasquerading para todas as m\u00e1quinas da rede 192.168.1.*:
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -j MASQUERADE
\necho “1” >\/proc\/sys\/net\/ipv4\/ip_forward
\nA configura\u00e7\u00e3o do servidor Linux est\u00e1 completa, agora os clientes da rede precisar\u00e3o ser
\nconfigurados para usar o endere\u00e7o IP do servidor Linux como gateway. \u00c9 recomend\u00e1vel instalar
\num servidor proxy e DNS na m\u00e1quina Linux para acelerar o desempenho das
\nrequisi\u00e7\u00f5es\/resolu\u00e7\u00e3o de nomes das m\u00e1quinas em rede. A utiliza\u00e7\u00e3o de bits TOS tamb\u00e9m pode
\ntrazer um grande aumento de velocidade para os diferentes servi\u00e7os da rede (veja Especificando o
\ntipo de servi\u00e7o, Se\u00e7\u00e3o 10.5.1).
\n10.4.3 Fazendo SNAT
\nSNAT (source nat – nat no endere\u00e7o de origem) consiste em modificar o endere\u00e7o de origem das
\nm\u00e1quinas clientes antes dos pacotes serem enviados. A m\u00e1quina roteadora \u00e9 inteligente o bastante
\npara lembrar dos pacotes modificados e reescrever os endere\u00e7os assim que obter a resposta da
\nm\u00e1quina de destino, direcionando os pacotes ao destino correto. Toda opera\u00e7\u00e3o de SNAT \u00e9 feita no
\nchain POSTROUTING.
\n\u00c9 permitido especificar endere\u00e7os de origem\/destino, protocolos, portas de origem\/destino, interface
\nde entrada\/sa\u00edda (dependendo do chain), alvos, etc. \u00c9 desnecess\u00e1rio especificar fragmentos na
\ntabela nat, pois eles ser\u00e3o remontados antes de entrar no c\u00f3digo de roteamento.
\nO SNAT \u00e9 a solu\u00e7\u00e3o quando voc\u00ea tem acesso a internet atrav\u00e9s de um \u00fanico IP e deseja fazer que
\nsua rede tenha acesso a Internet atrav\u00e9s da m\u00e1quina Linux. Nenhuma m\u00e1quina da Internet poder\u00e1
\nter acesso direto as m\u00e1quinas de sua rede interna via SNAT.
\nOBS: A observa\u00e7\u00e3o acima n\u00e3o leva em conta o controle de acesso externo configurado na m\u00e1quina
\nque estiver configurando o iptables, uma configura\u00e7\u00e3o mau realizada pode expor sua m\u00e1quina a
\nacessos externos indesejados e comprometer sua rede interna caso algu\u00e9m consiga acesso direto ao
\nservidor.
\n\u00c9 necess\u00e1rio especificar SNAT como alvo (-j SNAT) quando desejar que as m\u00e1quinas de sua rede
\ninterna tenha acesso a Internet atrav\u00e9s do IP fixo da m\u00e1quina Linux (para conex\u00f5es intermitentes
\ncomo PPP, veja Fazendo IP Masquerading, Se\u00e7\u00e3o 10.4.3.1). O par\u00e2metro –to IP:portas deve
\nser usado ap\u00f3s o alvo SNAT. Ele serve para especificar um endere\u00e7o IP, faixa de endere\u00e7os e
\nopcionalmente uma porta ou faixa de portas que ser\u00e1 substitu\u00edda. Toda a opera\u00e7\u00e3o de SNAT \u00e9
\nrealizada atrav\u00e9s do chain POSTROUTING:
\n# Modifica o endere\u00e7o IP dos pacotes vindos da m\u00e1quina 192.168.1.2 da rede
\ninterna
\n# que tem como destino a interface eth1 para 200.200.217.40 (que \u00e9 o nosso
\nendere\u00e7o
\n# IP da interface ligada a Internet).
\niptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth1 -j SNAT –to
\n200.200.217.40
\nOs pacotes indo para a Internet (nossa conex\u00e3o \u00e9 feita via eth1, nossa interface externa) vindo do
\nendere\u00e7o 192.168.1.2, s\u00e3o substitu\u00eddos por 200.241.200.40 e enviados para fora. Quando a resposta
\na requisi\u00e7\u00e3o \u00e9 retornada, a m\u00e1quina com iptables recebe os pacotes e faz a opera\u00e7\u00e3o inversa,
\nmodificando o endere\u00e7o 200.241.200.40 novamente para 192.168.1.2 e enviando a resposta a
\nm\u00e1quina de nossa rede interna. Ap\u00f3s definir suas regras de NAT, execute o comando echo “1”
\n>\/proc\/sys\/net\/ipv4\/ip_forward para habilitar o suporte a redirecionamento de pacotes
\nno kernel.
\nTamb\u00e9m \u00e9 poss\u00edvel especificar faixas de endere\u00e7os e portas que ser\u00e3o substitu\u00eddas:
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o eth0 -j SNAT –to
\n200.200.217.40-200.200.217.50
\nModifica o endere\u00e7o IP de origem de todas as m\u00e1quinas da rede 192.168.1.0\/24 que tem o destino a
\ninterface eth0 para 200.241.200.40 a 200.241.200.50. O endere\u00e7o IP selecionado \u00e9 escolhido de
\nacordo com o \u00faltimo IP alocado.
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o eth0 -j SNAT –to
\n200.200.217.40-200.200.217.50:1-1023
\nId\u00eantico ao anterior, mas faz somente substitui\u00e7\u00f5es na faixa de portas de origem de 1 a 1023.
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o eth0 -j SNAT –to
\n200.200.217.40-200.200.217.50 –to 200.200.217.70-200.200.217.73
\nFaz o mapeamento para a faixa de portas 200.200.217.40 a 200.200.217.50 e de 200.200.217.70 a
\n200.200.217.73.
\nOBS1: Se por algum motivo n\u00e3o for poss\u00edvel mapear uma conex\u00e3o NAT, ela ser\u00e1 derrubada.
\nOBS2: Tenha certeza que as respostas podem chegar at\u00e9 a m\u00e1quina que fez o NAT. Se estiver
\nfazendo SNAT em um endere\u00e7o livre em sua rede (como 200.200.217.73).
\nOBS3: Como notou acima, o SNAT \u00e9 usado quando temos uma conex\u00e3o externa com um ou mais
\nIP’s fixos. O Masquerading \u00e9 uma forma especial de SNAT usada para funcionar em conex\u00f5es que
\nrecebem endere\u00e7os IP aleat\u00f3rios (PPP).
\nOBS4: N\u00e3o se esque\u00e7a de habilitar o redirecionamento de pacotes ap\u00f3s fazer suas regra de NAT
\ncom o comando: echo “1” >\/proc\/sys\/net\/ipv4\/ip_forward, caso contr\u00e1rio o
\nredirecionamento de pacotes n\u00e3o funcionar\u00e1.
\n10.4.3.1 Fazendo IP Masquerading
\nO IP Masquerading \u00e9 um tipo especial de SNAT usado para conectar a sua rede interna a internet
\nquando voc\u00ea recebe um IP din\u00e2mico de seu provedor (como em conex\u00f5es ppp). Todas as opera\u00e7\u00f5es
\nde IP Masquerading s\u00e3o realizadas no chain POSTROUTING. Se voc\u00ea tem um IP fixo, deve ler
\nFazendo SNAT, Se\u00e7\u00e3o 10.4.3.
\nPara fazer IP Masquerading de uma m\u00e1quina com o IP 192.168.1.2 para ter acesso a Internet, use o
\ncomando:
\niptables -t nat -A POSTROUTING -s 192.168.1.2\/32 -o ppp0 -j MASQUERADE
\nA diferen\u00e7a \u00e9 que o alvo \u00e9 -j MASQUERADE. O comando acima faz IP Masquerading de todo o
\ntr\u00e1fego de 192.168.1.2 indo para a interface ppp0: O endere\u00e7o IP dos pacotes vindos de 192.168.1.2
\ns\u00e3o substitu\u00eddos pelo IP oferecido pelo seu provedor de acesso no momento da conex\u00e3o, quando a
\nresposta \u00e9 retornada a opera\u00e7\u00e3o inversa \u00e9 realizada para garantir que a resposta chegue ao destino.
\nNenhuma m\u00e1quina da internet poder\u00e1 ter acesso direto a sua m\u00e1quina conectava via Masquerading.
\nPara fazer o IP Masquerading de todas as m\u00e1quinas da rede 192.168.1.*:
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp0 -j MASQUERADE
\nAp\u00f3s definir a regra para fazer Masquerading (SNAT), execute o comando echo “1”
\n>\/proc\/sys\/net\/ipv4\/ip_forward para habilitar o suporte a redirecionamento de pacotes
\nno kernel.
\n10.4.4 Fazendo DNAT
\nDNAT (Destination nat – nat no endere\u00e7o de destino) consiste em modificar o endere\u00e7o de destino
\ndas m\u00e1quinas clientes. O destination nat \u00e9 muito usado para fazer redirecionamento de pacotes,
\nproxyes transparentes e balanceamento de carga.
\nToda opera\u00e7\u00e3o de DNAT \u00e9 feita no chain PREROUTING. As demais op\u00e7\u00f5es e observa\u00e7\u00f5es do
\nSNAT s\u00e3o tamb\u00e9m v\u00e1lidas para DNAT (com exce\u00e7\u00e3o que somente \u00e9 permitido especificar a
\ninterface de origem no chain PREROUTING).
\n# Modifica o endere\u00e7o IP destino dos pacotes de 200.200.217.40 vindo da
\ninterface eth0
\n# para 192.168.1.2.
\niptables -t nat -A PREROUTING -s 200.200.217.40 -i eth0 -j DNAT –to
\n192.168.1.2
\nTamb\u00e9m \u00e9 poss\u00edvel especificar faixas de endere\u00e7os e portas que ser\u00e3o substitu\u00eddas no DNAT:
\niptables -t nat -A PREROUTING -i eth0 -s 192.168.1.0\/24 -j DNAT –to
\n200.200.217.40-200.200.217.50
\nModifica o endere\u00e7o IP de destino do tr\u00e1fego vindos da interface 192.168.1.0\/24 para um IP de
\n200.241.200.40 a 200.241.200.50. Este \u00e9 um excelente m\u00e9todo para fazer o balanceamento de carga
\nentre servidores. O endere\u00e7o IP selecionado \u00e9 escolhido de acordo com o \u00faltimo IP alocado.
\niptables -t nat -A PREROUTING -i eth0 -s 192.168.1.0\/24 -j DNAT –to
\n200.200.217.40-200.200.217.50:1024:5000
\nId\u00eantico ao anterior, mas faz somente substitui\u00e7\u00f5es na faixa de portas de destino de 1024 a 5000. A
\nopera\u00e7\u00e3o acima \u00e9 a mesma realizada pelo ipmasqadm dos kernels da s\u00e9rie 2.2.
\nOBS1: Se por algum motivo n\u00e3o for poss\u00edvel mapear uma conex\u00e3o NAT, ela ser\u00e1 derrubada.
\nOBS2: N\u00e3o se esque\u00e7a de conferir se o ip_forward est\u00e1 ajustado para 1: echo “1”
\n>\/proc\/sys\/net\/ipv4\/ip_forward.
\n10.4.4.1 Redirecionamento de portas
\nO redirecionamento de portas permite a voc\u00ea repassar conex\u00f5es com destino a uma porta para outra
\nporta na mesma m\u00e1quina. O alvo REDIRECT \u00e9 usado para fazer esta opera\u00e7\u00e3o, junto com o
\nargumento –to-port especificando a porta que ser\u00e1 redirecionada. Este \u00e9 o m\u00e9todo DNAT espec\u00edfico
\npara se para fazer proxy transparente (para redirecionamento de endere\u00e7os\/portas, veja Fazendo
\nDNAT, Se\u00e7\u00e3o 10.4.4). Todas as opera\u00e7\u00f5es de redirecionamento de portas \u00e9 realizada no chain
\nPREROUTING e OUTPUT da tabela nat.
\niptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –toport
\n81
\nRedireciona as conex\u00f5es indo para a porta 80 para a porta 81 (rodando squid) no firewall.
\nATEN\u00c7\u00c3O: O squid possui suporte a proxy transparente, e poder\u00e1 atender as requisi\u00e7\u00f5es acima
\nda regra acima.
\n10.4.5 Monitorando conex\u00f5es feitas na tabela nat
\nUse o comando cat \/proc\/net\/ip_conntrack para listar todas as conex\u00f5es atuais tratadas
\npelo m\u00f3dulo nat.
\n10.5 A tabela mangle
\nA tabela mangle serve para especificar a\u00e7\u00f5es especiais para o tratamento do tr\u00e1fego que atravessa os
\nchains. Nesta tabela existem cincos chains: PREROUTING, POSTROUTING, INPUT, OUTPUT e
\nFORWARD (veja O que s\u00e3o tabelas?, Se\u00e7\u00e3o 10.1.14 para maiores detalhes).
\nEm geral, cada um deste chain \u00e9 processado antes do chain correspondente na tabela filter e nat para
\ndefinir op\u00e7\u00f5es especiais para o tr\u00e1fego (por exemplo, o chain PREROUTING da tabela mangle \u00e9
\nprocessado antes do PREROUTING da tabela nat). O chain OUTPUT da tablea mangle corresponde
\nao OUTPUT da tabela nat. Op\u00e7\u00f5es como o Tipo de Servi\u00e7o (TOS) \u00e9 especificado nesta tabela para
\nclassificar e aumentar consideravelmente a velocidade de tr\u00e1fego considerados em tempo real.
\nMesmo ap\u00f3s o tr\u00e1fego ser estabelecido, os chains da tabela mangle continuam ativos para garantir
\nque as op\u00e7\u00f5es especiais relacionadas com a conex\u00e3o continuem fazendo efeito (veja os exemplos de
\nCaminho percorrido pelos pacotes nas tabelas e chains, Se\u00e7\u00e3o 10.7).
\n10.5.1 Especificando o tipo de servi\u00e7o
\nO tipo de servi\u00e7o \u00e9 um campo existente no cabe\u00e7alho de pacotes do protocolo ipv4 que tem a
\nfun\u00e7\u00e3o especificar qual \u00e9 a prioridade daquele pacote. A prioridade \u00e9 definida usando o algoritmo
\nFIFO do pr\u00f3prio kernel, sendo uma das alternativas de controle\/prioriza\u00e7\u00e3o de tr\u00e1fego das mais
\nsimples e r\u00e1pidas.
\nUma das vantagens da utiliza\u00e7\u00e3o do tipo de servi\u00e7o \u00e9 dar prioridade ao tr\u00e1fego de pacotes
\ninterativos (como os do ICQ, IRC, servidores de chat), etc. Com o TOS especificado, mesmo que
\nesteja fazendo um download consumindo toda a banda de sua interface de rede, o tr\u00e1fego com
\nprioridade interativa ser\u00e1 enviado antes, aumentando a efici\u00eancia do uso de servi\u00e7os em sua
\nm\u00e1quina.
\nEm testes realizados em minha conex\u00e3o de 56K, o uso de regras TOS aumentou bastante o
\ndesempenho em tr\u00e1fego interativo (em torno de 300%), durante o uso total da banda da interface
\nppp em grande consumo de banda.
\nUsamos o alvo TOS (-j TOS) para especificar a modifica\u00e7\u00e3o do tipo de servi\u00e7o nos pacotes que
\natravessam as regras do firewall, acompanhada do argumento –set-tos TOS que define a nova
\nprioridade dos pacotes. Os valores aceitos s\u00e3o os seguintes:
\nEspera M\u00ednima
\n\u00c9 especificado atrav\u00e9s de Minimize-Delay, 16 ou 0x10
\nM\u00e1ximo Processamento
\n\u00c9 especificado atrav\u00e9s de Maximize-Throughput, 8, ou 0x08.
\nM\u00e1xima Confian\u00e7a
\n\u00c9 especificado atrav\u00e9s de Maximize-Reliability, 4 ou 0x04.
\nCusto m\u00ednimo
\nEspecificado atrav\u00e9s de Minimize-Cost, 2 ou 0x02.
\nPrioridade Normal
\nEspecificado atrav\u00e9s de Normal-Service, 0 ou 0x00.
\nOs pacotes vem por padr\u00e3o com o valor TOS ajustado como prioridade normal (bits tos ajustados
\npara 0x00). O tipo M\u00ednima Espera \u00e9 o de maior prioridade, recomendado para tr\u00e1fego interativo.
\n10.5.1.1 Especificando o TOS para tr\u00e1fego de sa\u00edda
\nEste \u00e9 o mais usado, pois prioriza o tr\u00e1fego que sai da m\u00e1quina (com destino a Internet, por
\nexemplo). Sua opera\u00e7\u00e3o \u00e9 realizada atrav\u00e9s do chain OUTPUT ou POSTROUTING.
\nPara priorizar todo o tr\u00e1fego de IRC de nossa rede interna indo para a interface ppp0:
\niptables -t mangle -A OUTPUT -o ppp0 -p tcp –dport 6666-6668 -j TOS –settos
\n16
\nO bit TOS \u00e9 ajustado para Espera m\u00ednima e ser\u00e1 enviado antes dos pacotes com prioridade normal
\npara fora. Para priorizar a transmiss\u00e3o de dados ftp saindo da rede:
\niptables -t mangle -A OUTPUT -o ppp0 -p tcp –dport 20 -j TOS –set-tos 8
\nPara priorizar o tr\u00e1fego de ICQ da rede:
\niptables -t mangle -A OUTPUT -o ppp0 -p tcp –dport 5190 -j TOS –set-tos
\n16
\nExistem muitas outras otimiza\u00e7\u00f5es que podem ser feitas, s\u00f3 depende dos requerimentos e an\u00e1lise de
\ncada servi\u00e7o da rede pelo administrador.
\nOBS: – Os pacotes que atravessam o alvo TOS somente tem os bits tipo do servi\u00e7o modificados,
\neles n\u00e3o ser\u00e3o de qualquer forma rejeitados.
\n10.5.1.2 Especificando o TOS para o tr\u00e1fego de entrada
\nEste prioriza o tr\u00e1fego que entra da m\u00e1quina. Sua opera\u00e7\u00e3o \u00e9 realizada no chain INPUT ou
\nPREROUTING. N\u00e3o faz muito sentido o uso deste chain dentro de uma rede pequena\/m\u00e9dia, pois o
\ntr\u00e1fego que recebermos ser\u00e1 priorizado pelo chain de sa\u00edda de outras m\u00e1quinas da internet\/outras
\nredes antes de chegar a nossa (desde que elas tamb\u00e9m estejam usando TOS).
\nPara priorizar o processamento do tr\u00e1fego interativo vindo de servidores IRC para nossa rede:
\niptables -t mangle -A PREROUTING -i eth0 -p tcp –sport 6666-6668 -j TOS
\n–set-tos 0x10
\nModifica o tipo de servi\u00e7o para m\u00ednima espera de todo o tr\u00e1fego enviado por servidores de IRC
\nvindo da interface eth0.
\nOBS: – Os pacotes que atravessam o alvo TOS somente tem os bits tipo do servi\u00e7o modificados,
\neles n\u00e3o ser\u00e3o de qualquer forma rejeitados. \\
\n10.6 Outros m\u00f3dulos do iptables
\nOs m\u00f3dulos do iptables s\u00e3o especificados com a op\u00e7\u00e3o -m m\u00f3dulo ou –match m\u00f3dulo e permitem
\nexpandir a funcionalidade do firewall atrav\u00e9s de novas confer\u00eancias e recursos de filtragem
\nadicionais, como limitar a confer\u00eancia de regras do firewall (um m\u00e9todo \u00fatil de limitar ping floods,
\nsyn floods, etc).
\n10.6.1 Conferindo de acordo com o estado da conex\u00e3o
\nEste m\u00f3dulo permite especificar regras de acordo com o estado da conex\u00e3o do pacote, isto \u00e9 feito
\natrav\u00e9s da interpreta\u00e7\u00e3o da sa\u00edda do m\u00f3dulo ip_conntrack. O par\u00e2metro –state OP\u00c7\u00d5ES deve
\nacompanhar este m\u00f3dulo. As op\u00e7\u00f5es permitidas s\u00e3o as seguintes:
\n\u2022 NEW – Confere com pacotes que criam novas conex\u00f5es
\n\u2022 ESTABLISHED – Confere com conex\u00f5es j\u00e1 estabelecidas
\n\u2022 RELATED – Confere com pacotes relacionados indiretamente a uma conex\u00e3o, como
\nmensagens de erro icmp, etc.
\n\u2022 INVALID – Confere com pacotes que n\u00e3o puderam ser identificados por algum motivo.
\nComo respostas de conex\u00f5es desconhecidas.
\nCaso seja necess\u00e1rio especificar mais de uma op\u00e7\u00f5es estas devem ser separadas por v\u00edrgulas.
\niptables -A INPUT -m state –state NEW -i ppp0 -j DROP
\nBloqueia qualquer tentativa de nova conex\u00e3o vindo da interface ppp0.
\niptables -A INPUT -m state –state NEW,INVALID -i ppp0 -j LOG
\nPermite registrar novas conex\u00f5es e pacotes inv\u00e1lidos vindos da interface ppp0.
\n10.6.2 Limitando o n\u00famero de vezes que a regra confere
\nA op\u00e7\u00e3o -m limit permite especificar o n\u00famero de vezes que uma regra conferir\u00e1 quando todas as
\noutras condi\u00e7\u00f5es forem satisfeitas. O n\u00famero padr\u00e3o de confer\u00eancia \u00e9 de 3 por hora, a n\u00e3o ser que
\nseja modificado atrav\u00e9s dos argumentos aceitos pelo limit:
\n\u2022 –limit num\/tempo – Permite especificar a taxa de confer\u00eancias do limit. O par\u00e2metro
\nnum especifica um n\u00famero e tempo pode ser
\n\u2022 s – Segundo
\n\u2022 m – Minuto
\n\u2022 h – Hora
\n\u2022 d – Dia
\nAssim uma regra como iptables -A INPUT -m limit –limit 5\/m -j
\nACCEPT permitir\u00e1 que a regra acima confira apenas 5 vezes por minuto (–limit 2\/s). Este
\nlimite pode ser facilmente adaptado para uma regra de log que confere constantemente n\u00e3o
\ncausar uma avalanche em seus logs. O valor padr\u00e3o \u00e9 3\/h.
\n\u2022 –limit-burst num – Especifica o n\u00famero inicial m\u00e1ximo de pacotes que ir\u00e3o conferir,
\neste n\u00famero \u00e9 aumentado por 1 a cada vez que o par\u00e2metro –limit acima n\u00e3o for atingido. O
\nvalor padr\u00e3o \u00e9 5.
\n10.6.3 Prote\u00e7\u00e3o contra ping da morte
\nA regra abaixo pode tomada como base para prote\u00e7\u00e3o contra ping flood:
\niptables -t filter -A ping-chain -p icmp –icmp-type echo-request -m limit
\n–limit 1\/s -j ACCEPT
\niptables -t filter -A ping-chain -j DROP
\nA regra acima limita em 1 vez por segundo (–limit 1\/s) a passagem de pings (echo requests) para a
\nm\u00e1quina Linux.
\niptables -t filter -A ping-chain -i ppp0 -p icmp –icmp-type echo-reply -m
\nlimit –limit 1\/s -j RETURN
\niptables -t filter -A ping-chain -j DROP
\nLimita respostas a pings (echo reply) vindos da interface ppp0 (-i ppp0) a 1 por segundo.
\nATEN\u00c7\u00c3O: O exemplo acima \u00e9 somente para a cria\u00e7\u00e3o de suas pr\u00f3prias regras com limita\u00e7\u00f5es,
\ncaso um pacote n\u00e3o confira ele ser\u00e1 bloqueado pela pr\u00f3xima regra. Se uma regra como esta for
\ncolocada no chain INPUT sem modifica\u00e7\u00f5es, ela n\u00e3o ter\u00e1 o efeito desejado, podendo colocar em
\nrisco a sua instala\u00e7\u00e3o pela falsa impress\u00e3o de seguran\u00e7a. Portanto, \u00e9 recomend\u00e1vel sempre testar as
\nmodifica\u00e7\u00f5es para ter certeza que elas tem efeito.
\n10.6.4 Prote\u00e7\u00e3o contra syn flood
\nA regra abaixo \u00e9 uma boa prote\u00e7\u00e3o para os ataques syn floods:
\niptables -t filter -A syn-chain -p tcp –syn -m limit –limit 2\/s -j ACCEPT
\niptables -t filter -A syn-chain -j DROP
\nEsta regra limita o atendimento de requisi\u00e7\u00f5es de conex\u00f5es a 2 por segundo. Outra forma de
\naumentar a seguran\u00e7a contra syn-floods \u00e9 atrav\u00e9s do pr\u00f3prio kernel ativando a op\u00e7\u00e3o “TCP
\nSynflood” na compila\u00e7\u00e3o e depois executando: echo “1”
\n>\/proc\/sys\/net\/ipv4\/tcp_synflood. No entanto, utilize estas op\u00e7\u00f5es com cautela em
\nservidores que possuem um grande n\u00famero de acessos para n\u00e3o ter problemas que afetem seu
\nclientes.
\nATEN\u00c7\u00c3O: Os exemplos acima devem s\u00e3o somente exemplos para cria\u00e7\u00e3o de suas pr\u00f3prias regras
\ncom limita\u00e7\u00f5es, caso um pacote n\u00e3o confira com a regra ele ser\u00e1 bloqueado pela pr\u00f3xima regra. Se
\numa regra como esta for colocada no chain INPUT sem modifica\u00e7\u00f5es, ela n\u00e3o ter\u00e1 o efeito
\ndesejado, podendo colocar em risco a sua instala\u00e7\u00e3o pela falsa impress\u00e3o de seguran\u00e7a. Portanto, \u00e9
\nrecomend\u00e1vel sempre testar as modifica\u00e7\u00f5es para ter certeza que elas tem efeito.
\n10.6.5 Prote\u00e7\u00e3o contra IP spoofing
\nA especifica\u00e7\u00e3o de endere\u00e7os de origem\/destino junto com a interface de rede pode ser usado como
\num detector de ataques spoofing. A l\u00f3gica \u00e9 que todos os endere\u00e7os que NUNCA devem vir da
\ninterface X devem ser negados imediatamente. As regras abaixo s\u00e3o colocadas no inicio do chain
\nINPUT para detectar tais ataques:
\niptables -A INPUT -s 192.168.1.0\/24 -i ! eth0 -j DROP
\niptables -A INPUT ! -s 192.168.1.0\/24 -i eth0 -j DROP
\nA primeira regra diz para bloquear todos os endere\u00e7os da faixa de rede 192.168.1.* que N\u00c3O vem
\nda interface eth0, a segunda regra diz para bloquear todos os endere\u00e7os que n\u00e3o sejam 192.168.1.*
\nvindos da interface eth0. O s\u00edmbolo “!” serve para especificar exce\u00e7\u00f5es (veja Especificando uma
\nexce\u00e7\u00e3o, Se\u00e7\u00e3o 10.3.5. O kernel do Linux automaticamente bloqueia a passagem de pacotes que
\ndizem ser de 127.0.0.1 e n\u00e3o est\u00e1 vindo da interface loopback.
\nO m\u00e9todo preferido para controlar o ip spoofing \u00e9 atrav\u00e9s do c\u00f3digo de roteamento do kernel (a n\u00e3o
\nser que esteja usando algum tipo de roteamento de origem assim\u00e9trico necess\u00e1rio por alguns
\nprogramas especiais):
\nfor i in \/proc\/sys\/net\/ipv4\/conf\/*\/rp_filter; do
\necho 1 >$i
\ndone
\nDesta forma qualquer endere\u00e7o dizendo ser 192.168.1.5 vindo de ppp0 ser\u00e1 imediatamente
\nrejeitado. Uma checagem adicional contra IP spoofing pode ser feita no arquivo
\n\/etc\/host.conf (veja \/etc\/host.conf, Se\u00e7\u00e3o 4.6.2.2).
\n10.6.6 Especificando m\u00faltiplas portas de origem\/destino
\nO m\u00f3dulo multiport permite que seja especificado m\u00faltiplas portas para um alvo. Podem ser
\nespecificadas at\u00e9 15 portas em um \u00fanico par\u00e2metro e basta que uma porta confira para que a regra
\nentre em a\u00e7\u00e3o, pois a compara\u00e7\u00e3o \u00e9 feita usando condi\u00e7\u00f5es “or”. O par\u00e2metro multiport deve
\nser acompanhado de um dos argumentos abaixo:
\n\u2022 –source-port [porta1, porta2…] – Faz a regra conferir se a porta de origem
\nestiver presente entre as portas especificadas.
\n\u2022 –destination-port [porta1, porta2…] – Faz a regra conferir se a porta de
\ndestino estiver presente entre as portas especificadas.
\n\u2022 –port [porta1, porta2…] – Faz a regra conferir caso a porta de origem ou
\ndestino esteja presente no par\u00e2metro.
\nEste m\u00f3dulo pode eliminar muitas regras de firewall que fazem o mesmo tratamento de pacotes
\npara diversas portas diferentes.
\niptables -A INPUT -p tcp -i ppp0 -m multiport –destination-port
\n21,23,25,80,110,113,6667 -j DROP
\nBloqueia todos os pacotes vindo de ppp0 para as portas 21 (ftp), 23 (telnet), 25 (smtp), 80 (www),
\n110 (pop3), 113 (ident), 6667 (irc).
\n10.6.7 Especificando o endere\u00e7o MAC da interface
\nO m\u00f3dulo mac serve para conferir com o endere\u00e7o Ethernet dos pacotes de origem. Somente faz
\nsentido se usado nos chains de PREROUTING (da tabela nat) ou INPUT (da tabela filter). Aceita
\ncomo argumento a op\u00e7\u00e3o –mac-source endere\u00e7o. O s\u00edmbolo “!” pode ser usado para especificar
\numa exce\u00e7\u00e3o.
\niptables -t filter -A INPUT -m mac –mac-source 00:80:AD:B2:60:0B -j DROP
\nConfere com a m\u00e1quina com endere\u00e7o ethernet igual a 00:80:AD:B2:60:0B.
\n10.6.8 Conferindo com quem criou o pacote
\nEste m\u00f3dulo confere com o usu\u00e1rio que iniciou a conex\u00e3o. \u00c9 somente v\u00e1lido no chain OUTPUT da
\ntabela filter. Os seguintes argumentos s\u00e3o v\u00e1lidas para este m\u00f3dulo:
\n\u2022 –uid-owner UID – Confere se o pacote foi criado por um processo com o UID
\nespecificado. At\u00e9 o momento somente UID num\u00e9ricos s\u00e3o aceitos.
\n\u2022 –gid-owner GID – Confere se o pacote foi criado por um usu\u00e1rio pertencente ao grupo
\nGID. At\u00e9 o momento somente GID num\u00e9ricos s\u00e3o aceitos.
\n\u2022 –pid-owner PID – Confere se o pacote foi criado por um processo com o PID
\nespecificado.
\n\u2022 –sid-owner ID – Confere se o pacote foi criado por um processo no grupo de se\u00e7\u00e3o
\nespecificado.
\nOBS: – Lembre-se que pacotes que n\u00e3o possuem detalhes suficientes de cabe\u00e7alho nunca
\nconferir\u00e3o!
\niptables -A OUTPUT -m owner –gid-owner 100 -p udp -j DROP
\nRejeita um conex\u00f5es indo para portas UDP de pacotes criados pelo usu\u00e1rios pertencentes ao grupo
\n100.
\n10.6.9 Conferindo com o conte\u00fado do pacote
\nO m\u00f3dulo string do iptables permite a inspe\u00e7\u00e3o de conte\u00fado de um pacote e tomar uma a\u00e7\u00e3o
\nse determinado tipo de tr\u00e1fego for encontrado em um pacote. Esta t\u00e9cnica pode ser usada tanto para
\nseguran\u00e7a como para economia de banda dentro da rede. Esta op\u00e7\u00e3o *N\u00c3O* torna o iptables como
\num firewall proxy, pois o proxy tem a habilidade de inspecionar o conte\u00fado, protocolo, comandos
\ndo pacote e decidir se o seu conte\u00fado \u00e9 nocivo ou n\u00e3o. O firewall em n\u00edvel de pacotes fazendo
\ninspe\u00e7\u00e3o de conte\u00fado, chega a ser 3 a 10 vezes mais r\u00e1pido do que um proxy, assim seu uso deve
\nser analisado dependendo do tr\u00e1fego que circula pelo link e da seguran\u00e7a dos dados que trafegam
\natrav\u00e9s dele.
\nUma boa pr\u00e1tica \u00e9 aliar esta op\u00e7\u00e3o a um IDS externo usando o alvo QUEUE e deixando o trabalho
\nde espe\u00e7\u00e3o de conte\u00fado para ele. Um exemplo de restri\u00e7\u00e3o direta \u00e9 o bloqueio do envio de qualquer
\ninforma\u00e7\u00e3o confidencial sigilosa para fora da rede interna (n\u00famero de contas, tudo que conferir com
\nCPF, CGC, endere\u00e7os de e-mail, memorandos, etc). De qualquer forma, analise o tr\u00e1fego de sua
\nrede antes de querer implementar qualquer solu\u00e7\u00e3o baseada neste m\u00e9todo sob o risco de afetar
\ntr\u00e1fego leg\u00edtimo.
\nOutra utilidade eficiente \u00e9 a diminui\u00e7\u00e3o de tr\u00e1fego, pois podemos barrar programas que
\nsobrecarregam o link em uma rede com muitos usu\u00e1rios como, por exemplo, usando o Kazaa ou
\nqualquer outro programa para c\u00f3pia de arquivos via Internet. Veja alguns exemplos:
\n# Bloqueia qualquer tentativa de acesso ao programa Kazaa
\niptables -A INPUT -m string –string “X-Kazaa” -j DROP
\n# N\u00e3o permite que dados confidenciais sejam enviados para fora da empresa
\n# e registra o ocorrido.
\niptables -A OUTPUT -m string –string “conta” -j LOG –log-prefix “ALERTA:
\ndados confidencial ”
\niptables -A OUTPUT -m string –string “conta” -j DROP
\n# Somente permite a passagem de pacotes que n\u00e3o cont\u00e9m “.exe” em seu
\nconte\u00fado
\niptables -A INPUT -m string –string ! “.exe” -j ACCEPT
\n10.6.10 Conferindo com o tempo de vida do pacote
\nO m\u00f3dulo ttl pode ser usado junto com as seguintes op\u00e7\u00f5es para conferir com o tempo de vida
\n(TTL) de um pacote:
\n\u2022 –ttl-eq [num]
\n\u2022 –ttl-lt [num]
\n\u2022 –ttl-gq [num]
\nVeja alguns exemplos:
\n# Confere com todos os pacotes que tem o TTL maior que 100
\niptables -A INPUT -m ttl –ttl-gt 100 -j LOG –log-prefix “TTL alto”
\n# Confere com todos os pacotes que tem o TTL igual a 1
\niptables -A INPUT -m ttl –ttl-eq 1 -j DROP
\nOBS: Tenha um especial cuidado durante a programa\u00e7\u00e3o de regras que usem TTL, como elas est\u00e3o
\nespecialmente associadas com o estado da comunica\u00e7\u00e3o estabelecida entre as duas pontas e o tipo
\nde protocolo, cuidados especiais devem ser tomados para que seu firewall n\u00e3o manipule de forma
\nincorreta tr\u00e1fego v\u00e1lido.
\n10.6.11 Conferindo com n\u00fameros RPC
\nO m\u00f3dulo rpc permite um controle especial sobre o tr\u00e1fego RPC que chega at\u00e9 a sua m\u00e1quina. Um
\nuso \u00fatil \u00e9 restringir a chamada a determinados n\u00fameros RPC e permitir outros (por exemplo,
\npermitindo somente o servi\u00e7o keyserv e bloqueando outros como o ypserv ou portmapper). As
\nseguintes op\u00e7\u00f5es podem ser usadas com o m\u00f3dulo nfs:
\n\u2022 –rpcs [procedimentos] – Confere com a lista de chamadas RPC especificadas.
\nMais de um procedimento RPC pode ser especificado como nome ou n\u00famero separandoos
\ncom v\u00edrgulas. Um arquivo \u00fatil que cont\u00e9m esta lista \u00e9 o \/etc\/rpc.
\n\u2022 –strict – Ignora servi\u00e7os RPC que n\u00e3o contenham a chamada get do portmapper. Em
\nsitua\u00e7\u00f5es normais, o inicio de qualquer solicita\u00e7\u00e3o RPC.
\nVeja alguns exemplos:
\n# Para conferir com todas as chamadas RPC referentes a conex\u00f5es iniciadas
\n# para o portmapper
\niptables -A INPUT -m rpc –rpcs portmapper –strict -j DROP
\n# Para permitir que somente as chamadas para status e statmon sejam
\n# aceitas
\niptables -A INPUT -m rpc –rpcs 100023,100024 -j ACCEPT
\n10.6.12 Conferindo com tipo de pacote
\nO m\u00f3dulo pkttype permite identificar um pacote do tipo unicast (direcionado a voc\u00ea), broadcast
\n(direcionado a uma determinada rede, definida pela netmask) ou multicast (destinado a grupos de
\nredes) e desta forma realizar a\u00e7\u00f5es em cima destes. O tipo de pacote \u00e9 identificado logo ap\u00f3s a
\nop\u00e7\u00e3o –pkt-type. Veja alguns exemplos:
\n# Bloqueia a passagem de pacotes multicast de uma rede para outra
\niptables -A FORWARD -i eth0 -o eth0 -m pkttype –pkt-type multicast -j DROP
\n# Como deve ter notado, \u00e9 poss\u00edvel fazer a associa\u00e7\u00e3o com diversas
\nespecifica\u00e7\u00f5es
\n# de m\u00f3dulos, bastando apenas especificar uma op\u00e7\u00e3o “-m” para cada m\u00f3dulo
\n# adicional:
\n# Permite a passagem de pacotes broadcast de uma rede para outra com
\n# limita\u00e7\u00e3o de 5\/s.
\niptables -A FORWARD -i eth0 -o eth0 -m pkttype –pkt-type broadcast -m
\nlimit –limit 5\/s -j ACCEPT
\n10.6.13 Conferindo com o tamanho do pacote
\nO tamanho do pacote pode ser usado como condi\u00e7\u00e3o de filtragem atrav\u00e9s do m\u00f3dulo length. O
\ntamanho do pacote \u00e9 especificado atrav\u00e9s da op\u00e7\u00e3o –length e o argumento segue a mesma sintaxe
\nda especifica\u00e7\u00e3o de portas no iptables sendo separados por :. Veja alguns exemplos:
\n# Bloqueia qualquer pacote ICMP maior que 30Kb
\niptables -A INPUT -i eth0 -m length –length 30000: -j DROP
\n# Bloqueia qualquer pacote com o tamanho entre 20 e 2000 bytes
\niptables -A INPUT -i eth0 -m length –length 20:2000 -j DROP
\n10.7 Caminho percorrido pelos pacotes nas tabelas e chains
\n\u00c9 MUITO importante entender a fun\u00e7\u00e3o de cada filtro e a ordem de acesso dos chains de acordo
\ncom o tipo de conex\u00e3o e interface de origem\/destino. Esta se\u00e7\u00e3o explica a ordem que as regra s\u00e3o
\natravessadas, isso lhe permitir\u00e1 planejar a distribui\u00e7\u00e3o das regras nos chains, e evitar erros de
\nlocaliza\u00e7\u00e3o de regras que poderia deixar seu firewall com s\u00e9rios problemas de seguran\u00e7a, ou um
\nsistema de firewall totalmente confuso e sem l\u00f3gica.
\nNos exemplos abaixo assumirei a seguinte configura\u00e7\u00e3o:
\n\u2022 A m\u00e1quina do firewall com iptables possui o endere\u00e7o IP 192.168.1.1 e conecta a
\nrede interna ligada via interface eth0 a internet via a interface ppp0.
\n\u2022 Rede interna com a faixa de endere\u00e7os 192.168.1.0 conectada ao firewall via interface
\neth0
\n\u2022 Interface ppp0 fazendo conex\u00e3o com a Internet com o endere\u00e7o IP 200.217.29.67.
\n\u2022 A conex\u00e3o das m\u00e1quinas da rede interna (eth0) com a rede externa (ppp0) \u00e9 feita via
\nMasquerading.
\nTamb\u00e9m utilizarei a sintaxe CHAIN-tabela para fazer refer\u00eancia aos chains e tabelas dos blocos
\nASCII: INPUT-filter – chain INPUT da tabela filter.
\nATEN\u00c7\u00c3O: A ordem de processamento das regras do iptables, \u00e9 diferente do ipchains
\ndevido a inclus\u00e3o do novo sistema de nat e da tabela mangle.
\n10.7.1 Ping de 192.168.1.1 para 192.168.1.1
\n\u2022 Endere\u00e7o de Origem: 192.168.1.1
\n\u2022 Endere\u00e7o de Destino: 192.168.1.1
\n\u2022 Interface de Entrada: lo
\n\u2022 Interface de Sa\u00edda: lo
\n\u2022 Protocolo: ICMP
\n\u2022 Descri\u00e7\u00e3o: Ping para o pr\u00f3prio firewall
\nSA\u00cdDA DE PACOTES (envio do ping para 192.168.1.1):
\n+————-+ +———-+ +————-+ +——————+
\n+—————-+
\n|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| =>|POSTROUTING-mangle|
\n=>|POSTROUTING-nat |
\n+————-+ +———-+ +————-+ +——————+
\n+—————-+
\nENTRADA DOS PACOTES (Retorno da resposta ping acima):
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| =>|INPUT-mangle|=>|INPUT-filter|
\n+—————–+ +————+ +————+
\nQuando damos o ping (echo request) os pacotes seguem o caminho em SA\u00cdDA DE PACOTES
\npercorrendo os chains na ordem especificada e retornam via ENTRADA DOS PACOTES (echo
\nreply). No envio da resposta da requisi\u00e7\u00e3o de ping, o caminho de sa\u00edda do pacote ignora os chains
\nOUTPUT-nat e POSTROUTING-nat (j\u00e1 que n\u00e3o \u00e9 necess\u00e1rio nat) mas sempre processa os chains
\ncorrespondentes da tabela mangle na ordem indicada acima.
\nOBS1: Para conex\u00f5es com destinos na pr\u00f3pria m\u00e1quina usando um endere\u00e7o IP das interfaces
\nlocais, a interface ser\u00e1 ajustada sempre para lo (loopback).
\nOBS2: Em qualquer opera\u00e7\u00e3o de entrada\/sa\u00edda de pacotes, os dois chains da tabela mangle s\u00e3o
\nsempre os primeiros a serem acessados. Isto \u00e9 necess\u00e1rio para definir a prioridade e controlar outros
\naspectos especiais dos pacotes que atravessam os filtros.
\nOBS3: O chain OUTPUT da tabela filter \u00e9 consultado sempre quando existem conex\u00f5es se
\noriginando em endere\u00e7os de interfaces locais.
\n10.7.2 Conex\u00e3o FTP de 192.168.1.1 para 192.168.1.1
\n\u2022 Endere\u00e7o de Origem: 192.168.1.1
\n\u2022 Endere\u00e7o de Destino: 192.168.1.1
\n\u2022 Interface de Origem: lo
\n\u2022 Interface de Destino: lo
\n\u2022 Porta Origem: 1404
\n\u2022 Porta Destino: 21
\n\u2022 Protocolo: TCP
\n\u2022 Descri\u00e7\u00e3o: Conex\u00e3o ftp (at\u00e9 o prompt de login, sem transfer\u00eancia
\nde arquivos).
\nSA\u00cdDA DOS PACOTES (envio da requisi\u00e7\u00e3o para 192.168.1.1):
\n+————-+ +———-+ +————-+ +——————+
\n+—————+
\n|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => +POSTROUTING-mangle|
\n=> |POSTROUTING-nat|
\n+————-+ +———-+ +————-+ +——————+
\n+—————+
\nENTRADA DE PACOTES (respostas da requisi\u00e7\u00e3o vindas de 192.168.1.1):
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————+ +————+
\nA requisi\u00e7\u00e3o ftp passa atrav\u00e9s dos chains especificados em SA\u00cdDA DOS PACOTES e retorna por
\nENTRADA DE PACOTES. Ap\u00f3s a conex\u00e3o ser estabelecida, o caminho de SA\u00cdDA DE PACOTES
\nser\u00e1:
\n+————-+ +————-+ +——————+
\n|OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|
\n+————-+ +————-+ +——————+
\npois os dados de entrada que vem da interface externa, s\u00e3o passados diretamente a m\u00e1quina do
\nfirewall, n\u00e3o necessitando de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat s\u00e3o
\nprocessado somente uma vez a procura de regras que conferem, principalmente para fazer SNAT).
\nNote novamente que mesmo n\u00e3o sendo necess\u00e1rio NAT, o chain POSTROUTING-mangle \u00e9
\nchecado.
\nOBS1: Para conex\u00f5es com destinos na pr\u00f3pria m\u00e1quina usando um endere\u00e7o IP das interfaces
\nlocais, a interface ser\u00e1 ajustada sempre para lo (loopback).
\nOBS2: Em qualquer opera\u00e7\u00e3o de entrada\/sa\u00edda de pacotes, os dois chains da tabela mangle s\u00e3o
\nsempre os primeiros a serem acessados. Isto \u00e9 necess\u00e1rio para definir a prioridade e controlar outros
\naspectos especiais dos pacotes que atravessam os filtros.
\n10.7.3 Conex\u00e3o FTP de 192.168.1.1 para 192.168.1.4
\n\u2022 Endere\u00e7o de Origem: 192.168.1.1
\n\u2022 Endere\u00e7o de Destino: 192.168.1.4
\n\u2022 Interface de Origem: eth0
\n\u2022 Interface de Destino: eth0
\n\u2022 Porta Origem: 1405
\n\u2022 Porta Destino: 21
\n\u2022 Protocolo: TCP
\n\u2022 Descri\u00e7\u00e3o: Conex\u00e3o ftp (at\u00e9 o prompt de login, sem transfer\u00eancia
\nde arquivos).
\nSA\u00cdDA DOS PACOTES (envio da requisi\u00e7\u00e3o para 192.168.1.4):
\n+————-+ +———-+ +————-+ +——————+
\n+—————+
\n|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => +POSTROUTING-mangle|
\n=> |POSTROUTING-nat|
\n+————-+ +———-+ +————-+ +——————+
\n+—————+
\nENTRADA DE PACOTES (respostas da requisi\u00e7\u00e3o de 192.168.1.4):
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————+ +————+
\nA requisi\u00e7\u00e3o ftp passa atrav\u00e9s dos chains especificados em SA\u00cdDA DOS PACOTES com o destino
\n192.168.1.4 porta 21 e retorna por ENTRADA DE PACOTES para 192.168.1.1 porta
\n1405. Ap\u00f3s a conex\u00e3o ser estabelecida, o caminho de SA\u00cdDA DE PACOTES ser\u00e1:
\n+————-+ +————-+ +——————+
\n|OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|
\n+————-+ +————-+ +——————+
\npois os dados n\u00e3o precisam de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat
\ns\u00e3o processado somente uma vez a procura de regras que conferem, principalmente para fazer
\nSNAT).
\nOBS: Em qualquer opera\u00e7\u00e3o de entrada\/sa\u00edda de pacotes, os dois chains da tabela mangle s\u00e3o
\nsempre os primeiros a serem acessados. Isto \u00e9 necess\u00e1rio para definir a prioridade e controlar outros
\naspectos especiais dos pacotes que atravessam os filtros.
\n10.7.4 Conex\u00e3o FTP de 200.217.29.67 para a m\u00e1quina ftp.debian.org.br
\n\u2022 Endere\u00e7o de Origem: 200.217.29.67
\n\u2022 Endere\u00e7o de Destino: 200.198.129.162
\n\u2022 Interface de Origem: ppp0
\n\u2022 Interface de Destino: ppp0
\n\u2022 Porta Origem: 1407
\n\u2022 Porta Destino: 21
\n\u2022 Protocolo: TCP
\n\u2022 Descri\u00e7\u00e3o: Conex\u00e3o ftp (at\u00e9 o prompt de login, sem transfer\u00eancia
\nde arquivos).
\nSA\u00cdDA DOS PACOTES (envio da requisi\u00e7\u00e3o para 200.198.129.162):
\n+————-+ +———-+ +————-+ +——————+
\n+—————+
\n|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => +POSTROUTING-mangle|
\n=> |POSTROUTING-nat|
\n+————-+ +———-+ +————-+ +——————+
\n+—————+
\nENTRADA DE PACOTES (respostas da requisi\u00e7\u00e3o vindas de 200.198.129.162):
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————+ +————+
\nA requisi\u00e7\u00e3o ftp passa atrav\u00e9s dos chains especificados em SA\u00cdDA DOS PACOTES com o destino
\n200.198.129.162 porta 21 (ap\u00f3s a resolu\u00e7\u00e3o DNS de www.debian.org.br) e retorna por
\nENTRADA DE PACOTES para 200.217.29.67 porta 1407. Ap\u00f3s a conex\u00e3o ser estabelecida, o
\ncaminho de sa\u00edda de pacotes \u00e9:
\n+————-+ +————-+ +——————+
\n|OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|
\n+————-+ +————-+ +——————+
\npois os dados n\u00e3o precisam de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat
\ns\u00e3o processado somente uma vez a procura de regras que conferem, principalmente para fazer
\nSNAT).
\nE ap\u00f3s a conex\u00e3o estabelecida, o caminho de entrada de pacotes passa a ser:
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————+ +————+
\npois os dados n\u00e3o precisam de tratamento DNAT (o chain PREROUTING-nat \u00e9 processado somente
\numa vez a procura de regras que conferem, principalmente para fazer DNAT).
\nOBS: Para qualquer opera\u00e7\u00e3o de entrada\/sa\u00edda de pacotes, os dois chains da tabela mangle s\u00e3o
\nsempre os primeiros a serem acessados. Isto \u00e9 necess\u00e1rio para definir a prioridade e controlar outros
\naspectos especiais dos pacotes que atravessam os filtros.
\n10.7.5 Ping de 192.168.1.4 para 192.168.1.1
\n\u2022 Endere\u00e7o de Origem: 192.168.1.4
\n\u2022 Endere\u00e7o de Destino: 192.168.1.1
\n\u2022 Interface de Entrada: eth0
\n\u2022 Interface de Sa\u00edda: eth0
\n\u2022 Protocolo: ICMP
\n\u2022 Descri\u00e7\u00e3o: Ping de 192.168.1.4 para a m\u00e1quina do firewall.
\nENTRADA DE PACOTES (recebimento da requisi\u00e7\u00e3o, vinda de 192.168.1.4):
\n+—————–+ +————–+ +————+ +————+
\n|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————–+ +————+ +————+
\nSA\u00cdDA DE PACOTES (envio da resposta a 192.168.1.4)
\n+————-+ +————-+ +——————+
\n|OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|
\n+————-+ +————-+ +——————+
\nQuando damos o ping (echo request) os pacotes seguem o caminho em ENTRADA DE PACOTES
\npercorrendo os chains na ordem especificada e retornam via SA\u00cdDA DOS PACOTES (echo reply).
\nOBS1: Para qualquer opera\u00e7\u00e3o de entrada\/sa\u00edda de pacotes, os dois chains da tabela mangle s\u00e3o
\nsempre os primeiros a serem acessados. Isto \u00e9 necess\u00e1rio para definir a prioridade e controlar outros
\naspectos especiais dos pacotes que atravessam os filtros.
\n10.7.6 Conex\u00e3o FTP de 192.168.1.4 para 192.168.1.1
\n\u2022 Endere\u00e7o de Origem: 192.168.1.4
\n\u2022 Endere\u00e7o de Destino: 192.168.1.1
\n\u2022 Interface de Origem: eth0
\n\u2022 Interface de Destino: eth0
\n\u2022 Porta Origem: 1030
\n\u2022 Porta Destino: 21
\n\u2022 Protocolo: TCP
\n\u2022 Descri\u00e7\u00e3o: Conex\u00e3o ftp (at\u00e9 o prompt de login, sem transfer\u00eancia
\nde dados).
\nENTRADA DOS PACOTES (envio da requisi\u00e7\u00e3o vindas de 192.168.1.4):
\n+—————–+ +————–+ +————+ +————+
\n|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————–+ +————+ +————+
\nSA\u00cdDA DE PACOTES (respostas da requisi\u00e7\u00e3o acima para 192.168.1.4):
\n+————-+ +————-+ +——————+
\n|OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|
\n+————-+ +————-+ +——————+
\nA requisi\u00e7\u00e3o ftp passa atrav\u00e9s dos chains especificados em ENTRADA DOS PACOTES com o
\ndestino 192.168.1.1 porta 21 e retorna por SA\u00cdDA DE PACOTES para 192.168.1.4 porta
\n1030. Ap\u00f3s a conex\u00e3o ser estabelecida, o caminho de entrada de pacotes \u00e9:
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————+ +————+
\npois os dados n\u00e3o precisam de tratamento DNAT (o chain PREROUTING-nat \u00e9 processado somente
\numa vez a procura de regras que conferem, principalmente para fazer DNAT).
\nOBS: O roteamento \u00e9 sempre realizado ap\u00f3s o processamento do chain PREROUTING da tabela
\nnat.
\n10.7.7 Conex\u00e3o FTP de 192.168.1.4 para ftp.debian.org.br
\n\u2022 Endere\u00e7o de Origem: 192.168.1.4
\n\u2022 Endere\u00e7o de Destino: 200.198.129.162
\n\u2022 Interface de Origem: eth0
\n\u2022 Interface de Destino: ppp0
\n\u2022 Porta Origem: 1032
\n\u2022 Porta Destino: 21
\n\u2022 Protocolo: TCP
\n\u2022 Descri\u00e7\u00e3o: Conex\u00e3o ftp (at\u00e9 o prompt de login, sem transfer\u00eancia
\nde dados).
\nSA\u00cdDA DOS PACOTES (requisi\u00e7\u00e3o vindas de 192.168.1.4):
\n+—————–+ +————–+ +————–+
\n|PREROUTING-mangle| => |PREROUTING-nat| => |FORWARD-mangle| => (continua
\nabaixo)
\n+—————–+ +————–+ +————–+
\n+————–+ +——————+ +—————+
\n|FORWARD-filter| => |POSTROUTING-mangle| => |POSTROUTING-nat|
\n+————–+ +——————+ +—————+
\nENTRADA DE PACOTES (respostas da requisi\u00e7\u00e3o acima, enviadas para
\n192.168.1.4):
\n+—————–+ +————–+ +————–+
\n+——————+
\n|PREROUTING-mangle| => |FORWARD-mangle| => |FORWARD-filter| => |
\nPOSTROUTING-mangle|
\n+—————–+ +————–+ +————–+
\n+——————+
\nA requisi\u00e7\u00e3o ftp passa atrav\u00e9s dos chains especificados em SA\u00cdDA DOS PACOTES com o destino
\n200.198.129.162 porta 21 (ap\u00f3s a resolu\u00e7\u00e3o DNS de ftp.debian.org.br) e retorna por
\nENTRADA DE PACOTES para 192.168.1.4 porta 1032.
\nNote que o Masquerading regrava os pacotes; para a m\u00e1quina 200.198.129.162 a conex\u00e3o est\u00e1
\nsendo feita para 200.217.29.67. As respostas de conex\u00f5es vindas de 200.198.129.162 e
\nindo para 200.217.29.67 s\u00e3o regravadas no firewall com o destino 192.168.1.4 e enviadas
\npara a m\u00e1quina correspondente. Ap\u00f3s a conex\u00e3o ser estabelecida, o caminho de sa\u00edda de pacotes
\npara 200.198.129.163 \u00e9:
\n+—————–+ +————–+ +————–+
\n+——————+
\n|PREROUTING-mangle| => |FORWARD-mangle| => |FORWARD-filter| => |
\nPOSTROUTING-mangle|
\n+—————–+ +————–+ +————–+
\n+——————+
\nAp\u00f3s a conex\u00e3o estabelecida, o caminho da entrada de pacotes vindos de 200.198.129.163 \u00e9:
\n+—————–+ +————–+ +————–+
\n+——————+
\n|PREROUTING-mangle| => |FORWARD-mangle| => |FORWARD-filter| => |
\nPOSTROUTING-mangle|
\n+—————–+ +————–+ +————–+
\n+——————+
\nIsto acontece porque ap\u00f3s feita a conex\u00e3o Masquerading (via PREROUTING-nat), o firewall j\u00e1
\nsabe como reescrever os pacotes para realizar a opera\u00e7\u00e3o de Masquerading, reescrevendo todos os
\npacotes que chegam de www.debian.org.br para 192.168.1.4.
\nOBS: As conex\u00f5es Masquerading feitas atrav\u00e9s da rede interna, s\u00e3o enviadas para
\n200.198.129.162 tem o endere\u00e7o de origem ajustado para 200.217.29.67 que \u00e9 o IP de
\nnossa interface ppp0. Quando as respostas atravessam o firewall, os pacotes s\u00e3o checados pra saber
\nse s\u00e3o uma resposta a uma conex\u00e3o masquerading e far\u00e1 a regrava\u00e7\u00e3o dos pacotes substituindo o
\nendere\u00e7o de destino para 192.168.1.4. Caso uma opera\u00e7\u00e3o de Masquerading falhe, os pacotes
\nser\u00e3o Bloqueados.
\n10.7.8 Conex\u00e3o FTP de 200.198.129.162 para 200.217.29.167
\n\u2022 Endere\u00e7o de Origem: 200.198.129.162
\n\u2022 Endere\u00e7o de Destino: 200.217.29.67
\n\u2022 Interface de Origem: ppp0
\n\u2022 Interface de Destino: ppp0
\n\u2022 Porta Origem: 3716
\n\u2022 Porta Destino: 21
\n\u2022 Protocolo: TCP
\n\u2022 Descri\u00e7\u00e3o: Conex\u00e3o ao servi\u00e7o ftp do firewall
\nENTRADA DOS PACOTES (requisi\u00e7\u00e3o vinda de 200.198.129.162):
\n+—————–+ +————–+ +————-+ +————
\n+
\n|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-mangle | => |INPUTfilter|
\n+—————–+ +————–+ +————-+ +————
\n+
\nSA\u00cdDA DE PACOTES (respostas da requisi\u00e7\u00e3o de 200.198.129.162):
\n+————-+ +————-+ +——————+
\n|OUTPUT-mangle| => |OUTPUT-filter| => |POSTROUTING-mangle|
\n+————-+ +————-+ +——————+
\nA requisi\u00e7\u00e3o ftp passa atrav\u00e9s dos chains especificados em ENTRADA DOS PACOTES com o
\ndestino 200.217.29.67 (nossa interface ppp0 local) porta 21 e retorna por SA\u00cdDA DE
\nPACOTES para 200.198.129.162 porta 3716 (tamb\u00e9m via ppp0). Ap\u00f3s a conex\u00e3o ser
\nestabelecida, o caminho de entrada de pacotes \u00e9:
\n+—————–+ +————+ +————+
\n|PREROUTING-mangle| => |INPUT-mangle| => |INPUT-filter|
\n+—————–+ +————+ +————+
\nIsto acontece porque ap\u00f3s feita a an\u00e1lise do chain PREROUTING (para necessidade de DNAT), a
\nm\u00e1quina j\u00e1 saber\u00e1 tomar a decis\u00e3o apropriada para gerenciar aquela conex\u00e3o.
\n10.7.9 Gr\u00e1fico geral da passagem dos pacotes
\nEste gr\u00e1fico foi retirado do documento netfilter-hacking-HOWTO.txt e mostra a estrutura
\ngeral de passagem dos pacotes nas tabelas\/chains. Os exemplos de passagem de pacotes acima
\npoder\u00e3o ser facilmente comparados com as etapas abaixo para compreender a estrutura do
\niptables.
\nE —> PREROUTING ——> (ROTEAM.) —> FORWARD ———-> POSTROUTING
\n–> S
\nMangle e | Mangle ^ Mangle
\nNAT (DNAT)) | Filter | NAT (SRC)
\n| (ROTEAM.)
\nv |
\nIN Mangle, OUT – Mangle,
\n| Filter ^ NAT (DNAT)
\n| | Filter
\nv |
\n+—————————————-+
\n| Processo Local |
\n+—————————————-+
\n10.8 Exemplos de configura\u00e7\u00f5es do iptables
\nExemplo de como bloquear todas as conex\u00f5es para a m\u00e1quina do firewall permitindo somente
\nconex\u00f5es da m\u00e1quina Linux para fora.
\n10.8.1 Bloqueando conex\u00f5es de fora para sua m\u00e1quina
\nAs regras a seguir servem para bloquear tentativas de conex\u00f5es da interface de Internet (ppp0) a sua
\nrede sem bloquear o tr\u00e1fego de conex\u00f5es j\u00e1 iniciadas. O tr\u00e1fego de outras interfaces n\u00e3o \u00e9 afetado
\ncom as regras a seguir:
\niptables -A INPUT -i ppp0 -m state –state ! ESTABLISHED,RELATED -j DROP
\nTodas as conex\u00f5es vindas de ppp0 de estado diferente de ESTABLISHED e RELATED (NEW e
\nINVALID) ser\u00e3o derrubadas. Veja Conferindo de acordo com o estado da conex\u00e3o, Se\u00e7\u00e3o 10.6.1
\npara detalhes.
\niptables -A INPUT -i ppp0 –syn -j DROP
\nEste acima \u00e9 mais simples e possui o mesmo efeito: Pacotes SYN s\u00e3o usados para iniciar conex\u00f5es,
\nderrubando pacotes deste tipo significa bloquear novas conex\u00f5es. Pacotes de conex\u00f5es j\u00e1
\nestabelecidas ainda s\u00e3o permitidos.
\nEstas regras acima servem para quem n\u00e3o deseja NENHUM acesso indevido a sua m\u00e1quina.
\nExistem outras formas de bloquear conex\u00f5es de modo mais seletivo usando chains espec\u00edficos,
\nendere\u00e7os de origem\/destino, portas, etc., este tipo de configura\u00e7\u00e3o \u00e9 muito usada caso precise
\nfornecer algum tipo de servi\u00e7o que seja acess\u00edvel externamente e protegendo outros.
\n10.8.2 Monitorando tentativa de conex\u00e3o de trojans em sua m\u00e1quina
\nAs regras abaixo alertam sobre a tentativa de conex\u00e3o dos trojans “For Win” mais conhecidos.
\nColoquei isto aqui por curiosidade de algumas pessoas, pois m\u00e1quinas Linux s\u00e3o imunes a este
\ntipo de coisa:
\n#!\/bin\/sh
\nTROJAN_PORTS=”12345 31336 31337 31338 3024 4092 5714 5742 2583 8787 5556
\n5557″
\niptables -t filter -N trojans-in
\nfor PORTA in ${TROJAN_PORTS};do
\niptables -A trojans-in -p tcp –sport=1024: –dport=${PORTA} -j LOG \\
\n–log-prefix “FIREWALL: Trojan ${PORTA} ”
\niptables -A trojans-in -p tcp –sport=1024: –dport=${PORTA} -j DROP
\ndone
\niptables -t filter -A INPUT -i ppp0 -j trojans-in
\nA primeira linha do iptables cria o chain trojans-in dentro da tabela filter que usaremos para
\narmazenar nossas regras de firewall. A segunda (dentro do la\u00e7o for) faz uma regra de LOG para
\nregistrar as tentativas de acesso de trojans em nosso sistema, a terceira rejeita o acesso. A quarta
\nregra do iptables cria de todo o tr\u00e1fego vindo da interface ppp0 pra o chain trojans-in (queremos
\nque s\u00f3 o tr\u00e1fego vindo da internet seja analisado pelo chain trojans-in).
\nMuitas das portas especificadas na vari\u00e1vel TROJAN_PORTS s\u00e3o antigas conhecidas de quem j\u00e1
\nbrincou ou sofreram com o Back Orifice, Win Crack, NetBus (quem nunca passou pela
\nfase de ter uma lista com mais de 100 netmasks e conseguir encontrar centenas de m\u00e1quinas por dia
\ninfectadas pelo BO? :-).
\nNo c\u00f3digo acima a \u00fanica coisa que precisa fazer para adicionar mais portas \u00e9 inseri-las na vari\u00e1vel
\nTROJAN_PORTS e executar o programa. O la\u00e7o do for executar\u00e1 as 2 regras para cada porta
\nprocessada (economizando linhas e linhas de regras, me livrando de uma LER e poupando muitos
\nbytes neste guia ;-).
\nDependendo do n\u00famero de portas alvo, este c\u00f3digo pode ser muito simplificado usando o recurso
\nmultiport do iptables (veja Especificando m\u00faltiplas portas de origem\/destino, Se\u00e7\u00e3o 10.6.6 para
\ndetalhes).
\n10.8.3 Conectando sua rede interna a Internet
\nO seguinte exemplo permite ligar sua rede interna com a faixa de IP’s 192.168.1.* a internet
\n(usando uma conex\u00e3o discada do tipo ppp):
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp+ -j MASQUERADE
\necho “1” >\/proc\/sys\/net\/ipv4\/ip_forward
\n10.8.4 Um exemplo de firewall simples
\nEsta se\u00e7\u00e3o possui um exemplo mais elaborado de firewall que servir\u00e1 para m\u00e1quinas conectadas via
\nppp com uma rede interna conectada via Masquerading. Este exemplo n\u00e3o \u00e9 t\u00e3o complexo e cobre
\nas expectativas mais comuns de pessoas que gostam de explorar os potenciais de rede no Linux ou
\nsatisfazer sua curiosidade. Ele poder\u00e1 ser facilmente adaptado para atender outro tipo de
\nnecessidade. A configura\u00e7\u00e3o assumida \u00e9 a seguinte:
\n\u2022 M\u00e1quina do firewall com 2 interfaces de rede, uma \u00e9 eth0 com o IP 192.168.1.1 que
\nserve de liga\u00e7\u00e3o a sua rede Interna, a outra \u00e9 ppp0 que \u00e9 a interface Internet.
\n\u2022 Qualquer acesso externo a m\u00e1quinas da rede interna \u00e9 bloqueado.
\n\u2022 Os usu\u00e1rios da rede local tem acesso livre ao servidor Linux.
\n\u2022 Qualquer acesso externo a m\u00e1quina do firewall \u00e9 bloqueado, exceto conex\u00f5es para o servi\u00e7o
\nApache (httpd). Outras tentativas de conex\u00f5es devem ser explicitamente registradas nos
\nlogs do sistema para conhecimento do administrador.
\n\u2022 Todos os usu\u00e1rios possuem acesso livre a Internet via Masquerading, exceto que o acesso
\npara o servi\u00e7o www deve ser obrigatoriamente feito via squid, e o servidor smtp a ser
\nusado dever\u00e1 ser o do firewall Linux.
\n\u2022 Prioridades ser\u00e3o estabelecidas para os servi\u00e7os de telnet, IRC,talk e DNS.
\n#!\/bin\/sh
\n# Modelo de configura\u00e7\u00e3o de firewall
\n# Autor: Gleydson M. Silva
\n# Data: 05\/09\/2001
\n# Descri\u00e7\u00e3o: Produzido para ser distribu\u00eddo livremente, acompanha o guia
\n# Foca GNU\/Linux. http:\/\/www.guiafoca.org
\n#
\n# \u00c9 assumido um sistema usando kmod para carga autom\u00e1tica dos m\u00f3dulos
\nusados por
\n# esta configura\u00e7\u00e3o do firewall:
\n# ipt_filter
\n# ipt_nat
\n# ipt_conntrack
\n# ipt_mangle
\n# ipt_TOS
\n# ipt_MASQUERADE
\n# ipt_LOG
\n# Se voc\u00ea tem um kernel modularizado que n\u00e3o utiliza o kmod, ser\u00e1
\nnecess\u00e1rio
\n# carregar estes m\u00f3dulos via modprobe, insmod ou iptables –modprobe=modulo
\n##### Defini\u00e7\u00e3o de Policiamento #####
\n# Tabela filter
\niptables -t filter -P INPUT DROP
\niptables -t filter -P OUTPUT ACCEPT
\niptables -t filter -P FORWARD DROP
\n# Tabela nat
\niptables -t nat -P PREROUTING ACCEPT
\niptables -t nat -P OUTPUT ACCEPT
\niptables -t nat -P POSTROUTING DROP
\n# Tabela mangle
\niptables -t mangle -P PREROUTING ACCEPT
\niptables -t mangle -P OUTPUT ACCEPT
\n##### Prote\u00e7\u00e3o contra IP Spoofing #####
\nfor i in \/proc\/sys\/net\/ipv4\/conf\/*\/rp_filter; do
\necho 1 >$i
\ndone
\n##### Ativamos o redirecionamento de pacotes (requerido para NAT) #####
\necho “1” >\/proc\/sys\/net\/ipv4\/ip_forward
\n# O iptables define automaticamente o n\u00famero m\u00e1ximo de conex\u00f5es simult\u00e2neas
\n# com base na mem\u00f3ria do sistema. Para 32MB = 2048, 64MB = 4096, 128MB =
\n8192,
\n# sendo que s\u00e3o usados 350 bytes de mem\u00f3ria residente para controlar
\n# cada conex\u00e3o.
\n# Quando este limite \u00e9 excedido a seguinte mensagem \u00e9 mostrada:
\n# “ip_conntrack: maximum limit of XXX entries exceed”
\n#
\n# Como temos uma rede simples, vamos abaixar este limite. Por outro lado
\nisto
\n# criar\u00e1 uma certa limita\u00e7\u00e3o de tr\u00e1fego para evitar a sobrecarga do
\nservidor.
\necho “2048” > \/proc\/sys\/net\/ipv4\/ip_conntrack_max
\n###############################################################
\n# Tabela filter #
\n###############################################################
\n##### Chain INPUT #####
\n# Criamos um chain que ser\u00e1 usado para tratar o tr\u00e1fego vindo da Internet e
\niptables -N ppp-input
\n# Aceita todo o tr\u00e1fego vindo do loopback e indo pro loopback
\niptables -A INPUT -i lo -j ACCEPT
\n# Todo tr\u00e1fego vindo da rede interna tamb\u00e9m \u00e9 aceito
\niptables -A INPUT -s 192.168.1.0\/24 -i eth0 -j ACCEPT
\n# Conex\u00f5es vindas da interface ppp0 s\u00e3o tratadas pelo chain ppp-input
\niptables -A INPUT -i ppp+ -j ppp-input
\n# Qualquer outra conex\u00e3o desconhecida \u00e9 imediatamente registrada e
\nderrubada
\niptables -A INPUT -j LOG –log-prefix “FIREWALL: INPUT ”
\niptables -A INPUT -j DROP
\n##### Chain FORWARD ####
\n# Permite redirecionamento de conex\u00f5es entre as interfaces locais
\n# especificadas abaixo. Qualquer tr\u00e1fego vindo\/indo para outras
\n# interfaces ser\u00e1 bloqueado neste passo
\niptables -A FORWARD -d 192.168.1.0\/24 -i ppp+ -o eth0 -j ACCEPT
\niptables -A FORWARD -s 192.168.1.0\/24 -i eth0 -o ppp+ -j ACCEPT
\niptables -A FORWARD -j LOG –log-prefix “FIREWALL: FORWARD ”
\niptables -A FORWARD -j DROP
\n##### Chain ppp-input ####
\n# Aceitamos todas as mensagens icmp vindas de ppp0 com certa limita\u00e7\u00e3o
\n# O tr\u00e1fego de pacotes icmp que superar este limite ser\u00e1 bloqueado
\n# pela regra “…! ESTABLISHED,RELATED -j DROP” no final do
\n# chain ppp-input
\n#
\niptables -A ppp-input -p icmp -m limit –limit 2\/s -j ACCEPT
\n# Primeiro aceitamos o tr\u00e1fego vindo da Internet para o servi\u00e7o www (porta
\n80)
\niptables -A ppp-input -p tcp –dport 80 -j ACCEPT
\n# A tentativa de acesso externo a estes servi\u00e7os ser\u00e3o registrados no
\nsyslog
\n# do sistema e ser\u00e3o bloqueados pela \u00faltima regra abaixo.
\niptables -A ppp-input -p tcp –dport 21 -j LOG –log-prefix “FIREWALL: ftp
\n”
\niptables -A ppp-input -p tcp –dport 25 -j LOG –log-prefix “FIREWALL: smtp
\n”
\niptables -A ppp-input -p udp –dport 53 -j LOG –log-prefix “FIREWALL: dns
\n”
\niptables -A ppp-input -p tcp –dport 110 -j LOG –log-prefix “FIREWALL:
\npop3 ”
\niptables -A ppp-input -p tcp –dport 113 -j LOG –log-prefix “FIREWALL:
\nidentd ”
\niptables -A ppp-input -p udp –dport 111 -j LOG –log-prefix “FIREWALL:
\nrpc”
\niptables -A ppp-input -p tcp –dport 111 -j LOG –log-prefix “FIREWALL:
\nrpc”
\niptables -A ppp-input -p tcp –dport 137:139 -j LOG –log-prefix “FIREWALL:
\nsamba ”
\niptables -A ppp-input -p udp –dport 137:139 -j LOG –log-prefix “FIREWALL:
\nsamba ”
\n# Bloqueia qualquer tentativa de nova conex\u00e3o de fora para esta m\u00e1quina
\niptables -A ppp-input -m state –state ! ESTABLISHED,RELATED -j LOG –logprefix
\n“FIREWALL: ppp-in ”
\niptables -A ppp-input -m state –state ! ESTABLISHED,RELATED -j DROP
\n# Qualquer outro tipo de tr\u00e1fego \u00e9 aceito
\niptables -A ppp-input -j ACCEPT
\n#######################################################
\n# Tabela nat #
\n#######################################################
\n##### Chain POSTROUTING #####
\n# Permite qualquer conex\u00e3o vinda com destino a lo e rede local para eth0
\niptables -t nat -A POSTROUTING -o lo -j ACCEPT
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o eth0 -j ACCEPT
\n# N\u00e3o queremos que usu\u00e1rios tenham acesso direto a www e smtp da rede
\nexterna, o
\n# squid e smtpd do firewall devem ser obrigatoriamente usados. Tamb\u00e9m
\nregistramos
\n# as tentativas para monitorarmos qual m\u00e1quina est\u00e1 tentando conectar-se
\ndiretamente.
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp+ -p tcp –dport 80
\n-j LOG –log-prefix “FIREWALL: SNAT-www ”
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp+ -p tcp –dport 25
\n-j LOG –log-prefix “FIREWALL: SNAT-smtp ”
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp+ -p tcp –dport 25
\n-j DROP
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp+ -p tcp –dport 80
\n-j DROP
\n# \u00c9 feito masquerading dos outros servi\u00e7os da rede interna indo para a
\ninterface
\n# ppp0
\niptables -t nat -A POSTROUTING -s 192.168.1.0\/24 -o ppp+ -j MASQUERADE
\n# Qualquer outra origem de tr\u00e1fego desconhecida indo para eth0 (conex\u00f5es
\nvindas
\n# de ppp+) s\u00e3o bloqueadas aqui
\niptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.0\/24 -j LOG –logprefix
\n“FIREWALL: SNAT unknown”
\niptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.0\/24 -j DROP
\n# Quando iniciamos uma conex\u00e3o ppp, obtermos um endere\u00e7o classe A
\n(10.x.x.x) e ap\u00f3s
\n# estabelecida a conex\u00e3o real, este endere\u00e7o \u00e9 modificado. O tr\u00e1fego indo
\npara
\n# a interface ppp n\u00e3o dever\u00e1 ser bloqueado. Os bloqueios ser\u00e3o feitos no
\n# chain INPUT da tabela filter
\niptables -t nat -A POSTROUTING -o ppp+ -j ACCEPT
\n# Registra e bloqueia qualquer outro tipo de tr\u00e1fego desconhecido
\niptables -t nat -A POSTROUTING -j LOG –log-prefix “FIREWALL: SNAT ”
\niptables -t nat -A POSTROUTING -j DROP
\n###############################################
\n# Tabela mangle #
\n###############################################
\n##### Chain OUTPUT #####
\n# Define m\u00ednimo de espera para os servi\u00e7os ftp, telnet, irc e DNS, isto
\n# dar\u00e1 uma melhor sensa\u00e7\u00e3o de conex\u00e3o em tempo real e diminuir\u00e1 o tempo
\n# de espera para conex\u00f5es que requerem resolu\u00e7\u00e3o de nomes.
\niptables -t mangle -A OUTPUT -o ppp+ -p tcp –dport 21 -j TOS –set-tos
\n0x10
\niptables -t mangle -A OUTPUT -o ppp+ -p tcp –dport 23 -j TOS –set-tos
\n0x10
\niptables -t mangle -A OUTPUT -o ppp+ -p tcp –dport 6665:6668 -j TOS –settos
\n0x10
\niptables -t mangle -A OUTPUT -o ppp+ -p udp –dport 53 -j TOS –set-tos
\n0x10<\/p>\n","protected":false},"excerpt":{"rendered":"
Introdu\u00e7\u00e3o O Firewall \u00e9 um programa que como objetivo proteger a m\u00e1quina contra acessos indesejados, tr\u00e1fego indesejado, proteger servi\u00e7os que estejam rodando na m\u00e1quina e bloquear a passagem de coisas que voc\u00ea n\u00e3o deseja receber (como conex\u00f5es vindas da Internet para sua segura rede local, evitando acesso aos dados corporativos de uma empresa ou a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[79,51],"tags":[117,19],"class_list":["post-294","post","type-post","status-publish","format-standard","hentry","category-firewall","category-linux-linuxrs","tag-iptables","tag-tcpip"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=294"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/294\/revisions"}],"predecessor-version":[{"id":295,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/294\/revisions\/295"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}