ATENÇÃO A PARTIR DO KERNEL 2.4....... NÃO SE USA MAIS O IPCHAIM. FOI SUSBSTITUIDO PELO IPTABLES VEJA NESTE DIRETÓRIO iptables.txt copiei de: http://www.ufrnet.br/~rk/linux/howtos/IPCHAINS-HOWTO.txt Linux IPCHAINS-HOWTO Paul Russell, ipchains@rustcorp.com v1.0.7, 12 March 1999 Tradução por Gleydson Mazioli da Silva, gleydson@linuxbr.com.br Este documento descreve como obter, instalar e configurar o avançado programa IP chains firewall para Linux, e muitas idéias de como você pode usa-lo. ______________________________________________________________________ Tabela de conteúdo 1. Introdução 1.1 O que? 1.2 Porque? 1.3 Como? 1.4 Onde? 2. Básico sobre Filtragem de pacotes 2.1 O que? 2.2 Porque? 2.3 Como? 2.3.1 Um Kernel com filtragem de pacotes 2.3.2 ipchains 2.3.3 Fazendo Regras Permanentes 3. Estou confuso! Roteamento, masquerading, portforwarding, ipautofw... 3.1 Guia de três linhas para Masquerading 3.2 Promoção Gratuita: Regras Assista o Guarda 3.3 Configuração de Firewalls simples 3.3.1 Rede Privada: Proxies Tradicionais 3.3.2 Rede Privada: Proxies Transparentes 3.3.3 Rede Privada: Masquerading 3.3.4 Rede Publica 3.3.5 Serviços Internos Limitados 3.4 Mais informações sobre Masquerading: David Ranch escreveu um novo HOWT O excelente sobre Masquerading, que foi um largo sobreposto deste howto. Voc p ode atualmente encontrar este HOWTO em 4. IP Firewalling Chains 4.1 Como pacotes atravessam os filtros 4.1.1 Usando ipchains 4.1.2 Operações em uma Regra Simples 4.1.3 Especificação de Filtragem 4.1.3.1 Especificando Enderecos de Origem e Destino 4.1.3.2 Especificando Inversão 4.1.3.3 Especificando o Protocolo 4.1.3.3.1 Especificando Portas UDP e TCP 4.1.3.3.2 Especificando tipo de ICMP e Codigo 4.1.3.4 Especificando a Interface 4.1.3.5 Especificando somente pacotes TCP SYN 4.1.3.6 Direcionando Fragmentos 4.1.4 Efeitos do Lado de Filtragem 4.1.4.1 Especificando um Alvo 4.1.4.2 Registrando Pacotes 4.1.4.3 Manipulando o tipo de serviço 4.1.4.4 Marcando um Pacotes 4.1.4.5 Operações em todo o chain 4.1.4.6 Criando uma novo chain 4.1.4.7 Deletando um chain 4.1.4.8 Liberando um chain 4.1.4.9 Listando um chain 4.1.4.10 Resetando contadores (Zeroing) 4.1.4.11 Configurando o Policiamento 4.1.5 Operações em Masquerading 4.1.6 Checando um Pacote Packet 4.1.7 Multiplas Regras em uma and Watching What Happens 4.2 Exemplos Úteis 4.2.1 Usando ipchains-save 4.2.2 Usando ipchains-restore 5. Outros. 5.1 Como organizar suas regras de Firewall 5.2 O que não descartar no Filtro 5.2.1 Pacotes ICMP 5.2.2 Conexões TCP para DNS (nameservers) 5.2.3 Pesadelos FTP 5.3 Descartando o Ping of Death 5.4 Descartando Teardrop and Bonk 5.5 Descartando Bombas de Fragmento (Fragment Bombs) 5.6 Modificando Regras do Firewall 5.7 Como configurar a proteção de IP Spoof? 5.8 Projetos Avançados 5.8.1 SPF: Stateful Packet Filtering 5.8.2 Michael Hasenstein's ftp-data hack 5.9 Avanços futuros 6. Problemas Comuns 6.1 ipchains -L Congela! 6.2 Masquerading/Forwarding não funciona! 6.3 -j REDIR não funciona! 6.4 O uso de Coringas em Interfaces não funciona! 6.5 TOS não funciona! 6.6 ipautofw e ipportfw não funcionam! 6.7 xosview esta com problema! 6.8 Segmentation Fault com `-j REDIRECT'! 6.9 Eu não posso configurar Timeouts em Masquerading! 6.10 Eu desejo fazer Firewall em IPX! 7. Um Exemplo Sério. 7.1 O Arranjo 7.2 Metas 7.3 Antes da Filtragem de Pacotes 7.4 Filtragem de Pacotes para Through Packets 7.4.1 Set Up Jumps From forward Chain 7.4.2 Define a icmp-acc Chain 7.4.3 Bom (Interno) para DMZ (Servidores) 7.4.4 Ruins (externos) para DMZ (servidores). 7.4.5 Bom (internos) para Ruins (externos). 7.4.6 DMZ para Good (internos). 7.4.7 DMZ para Ruins (externos). 7.4.8 Ruins (externos) para Bom (internos). 7.4.9 Filtragem de Pacotes para sua própria Máquina Linux 7.4.9.1 Má Interfaces (externas). 7.4.9.2 Interface DMZ. 7.4.9.3 Boa interface (interna). 7.5 Finalmente 8. Apêndice: Diferenças entre ipchains e ipfwadm. 8.1 Tabela de Referência Rápida. 8.2 Exemplos de comandos ipfwadm traduzidos 9. Apêndice: Usando o script ipfwadm-wrapper. 10. Apêndice: Agradecimentos. ______________________________________________________________________ 1. Introdução Este é o Linux IPCHAINS-HOWTO; Veja "Onde?" para o ver site principal, que contém a última cópia. Você também deve ler o Linux NET-3-HOWTO. O IP-Masquerading HOWTO, o PPP-HOWTO, o Ethernet-HOWTO e o Firewall HOWTO que podem ser uma leitura interessante. (Então denovo a FAQ alt.fan.bigfoot). Se a filtragem de pacotes é passado para você, leia a seção "Porque?", Seção "Como?" e verifique os títulos na seção "IP Firewalling Chains". Se você esta convertendo através do ipfwadm, leia a secao "Introdução", Seção "Como?", e os Apêndices da seção "Diferenças entre ipchains e ipfwadm" e a seção "Usando o script ipfwadm-wrapper". 1.1. O que? O ipchains do Linux é uma regravação do codigo de firewall IPv4 do linux (que foi originalmente roubado do BSD) e uma regravação do ipfwadm, que foi uma regravação do ipfw dos BSD's, eu acho. É requerido para administrar os filtros de pacotes IP nos kernels do linux 2.1.102 e superiores. 1.2. Por que? O antigo codigo do firewall do Linux não negociava com fragmentos, tinha contadores de 32 bits (no Intel no mínimo), não permitia especificação de outros protocolos senão TCP, UDP ou ICMS, não faziam grandes alterações dinâmicamente, não especificava regras contrárias, possuia alguns truques, e é dificil de gerenciar ( podendo causar erros do usuário). 1.3. Como? Atualmente o código está no kernel em desenvolvimento do 2.1.192. Para as séries do kernel 2.0, você precisará fazer o download de um patch da página Internet. Se seu kernel 2.0 é mais recente que o patch fornecido, o patch antigo ser OK; esta parte dos kernels 2.0 é razoavelmente estável (eg. o patch do kernel 2.0.34 funciona perfeitamente com o kernel 2.0.35). Desde então o patch 2.0 é incompatível com patches do ipportfw e ipautofw, eu não recomendo aplica-los a não ser que você ralmente necessita da funcionalidade que o ipchains oferece. 1.4. Onde? A página oficial é The Linux IP Firewall Chains Page Lá existe uma lista de discussão para relatar bugs, discussões, desenvolvimento e uso. Entre na lista de discussão enviando uma mensagem contendo a palavra "subscribe" para ipchains-request em rustcorp.com. Para enviar E-Mails para a lista use "ipchains" ao invés de "ipchains-request". 2. Básico sobre a filtragem de pacotes 2.1. O que? Todo o tráfego da rede é enviado em forma de pacotes. Por exemplo, copiando este pacote (digamos de 50k) pode fazer você receber 36 ou assim pacotes de 1460 bytes em cada um, (puxando números ao acaso). O inicio de cada pacote diz onde ele esta indo, de onde vem, o tipo do pacote, e outros detalhes administrativos. Isto inicia o pacote e é chamado de cabeçalho (head). O resto do pacote que contém o dado atual sendo transmitido, é usualmente chamado de corpo (body). Alguns protocolos, como TCP, que é usado para o trafego na web, mail, e logins remotos, usam o conceito de "conexão" -- antes de qualquer pacote com os dados atuais serem enviados, vários pacotes de configuração (com cabeçalhos especiais) são trocados dizendo "Eu desejo conectar", "OK" e "Obrigado". Então os pacotes normais são trocados. Uma filtragem de pacotes é uma peça de software que olha no cabeçalho do pacote quando eles passam, e decide o destino de todo o pacote. Ele pode decidir negar o pacote (DENY - ie. descartar o pacote como se ele nunca tivesse o recebido), aceita o pacote (ACCEPT - ie. deixar o pacote segu ir adiante), ou rejeitar o pacote (REJECT - como negar, mas avisa a origem do pa cote sobre o acontecido). No Linux, a filtragem de pacotes é embutida no kernel, e aqui estão algumas coisas que nós podemos fazer com os pacotes, mas o principio geral é de olhar o cabeçalho dos pacotes e decidindo seu destino. 2.2. Por que? Controle. Segurança. Vigilância. Controle: quando você está usando um computador linux para conectar sua rede interna a outra rede (digo, a Internet) você tem a oportunidade de permitir certos tipos de tráfego, e desativar outros. Por exemplo, o cabeçalho do pacote contém o endereço de destino do pacote, assim você pode prevenir pacote de irem para certas partes de fora da rede. Como outro exemplo, eu uso o Netscape para acessar os arquivos Dilbert. Lá estão anúncios da página doubleclick.net, e o Netscape desperdiça partes do meu tempo copiando-a. Dizendo para o filtro de pacotes não permitir qualquer pacotes para ou de o endereço conhecido por doubleclick.net resolve este problema (lá estão meios melhores de se fazer isto). Segurança: quando um computador linux é a única coisa entre o caos da Internet e sua bonita e organizada rede, é maravilhoso conhecer como você pode restringir o que vem batendo em sua porta. Por exemplo, você pode permitir ir para fora de sua rede, mas você pode estar preocupado com os conhecidos "Ping of Death" (ping da morte) que vem de computadores maliciosos de fora. Como outro exemplo, você pode não desejar que pessoas de fora TELNETiando seu computador linux, embora mesmo que todas suas contas tenham senhas; talvez você deseja (como muitas pessoas) ser um observador na Internet, e não um servidor (legando ou caso contrário) -- simplesmente não deixe ninguém conectar em seu computador, tendo filtros de pacotes rejeitando pacotes de entrada usado para iniciar conexões. Vigilância: muitas vezes uma máquina mal configurada na rede local pode decidir enviar pacotes para fora da rede. É bom dizer ao filtro de pacotes para avisa-lo se alguma coisa de anormal ocorre; talvez você pode fazer alguma coisa sobre isto, ou talvez você está simplesmente curioso por natureza. 2.3. Como? 2.3.1. Um kernel com filtragem de pacotes Você precisará de um kernel que tem o novo IP firewall chains nele. Você pode ver ser o kernel que está executando tem isto instalado verificando pelo arquivo "/proc/net/ip_FWchains". Se ele existe, seu kernel tem o suporte. Caso contrário, você precisará compilar um kernel com o IP firewall chains. Primeiro copie o código fonte do kernel que deseja. Se possui um kernel númerado 2.1.102 ou maior, você não precisará aplicar o patch (está na versão principal do kernel agora). Caso contrário, aplique o patch da página web listada acima, e ajuste a configuração como detalhado abaixo. Se você não sabe como fazer isto, sem pânico -- leia o Kernel-HOWTO. As opções de configuração que precisa configurar para os kernels da série 2.0 são: ______________________________________________________________________ CONFIG_EXPERIMENTAL=y CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_CHAINS=y ______________________________________________________________________ Para os kernels da série 2.1 ou 2.2: ______________________________________________________________________ CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y ______________________________________________________________________ A ferramenta ipchains fala com o kernel e diz a ele quais pacotes filtrar. A não ser que você seja um programador, ou curioso demais, assim você controlará a filtragem de pacotes. 2.3.2. ipchains A ferramenta ipchains insere ou deleta regras da seção de filtragem de pacotes do kernel. Isto quer dizer que qualquer coisa que você configurar, será perdida na reinicialização; veja "Fazendo Regras Permanentes" para como fazer as regras serem restauradas quando o Linux é iniciado. ipchains substitui ipfwadm, que foi usado pelo antigo código de firewall de IP. Há um conjunto de scripts úteis disponíveis no site ftp do ipchains: ftp://ftp.rustcorp.com/ipchains/ipchains-scripts-1.1.2.tar.gz Este contém um script shell chamado ipfwadm-wrapper que permite fazer a filtragem de pacotes como fez antes. Você provavelmente não deve usar este script a não ser se deseje fazer um método rápido de upgrade em um sistema que usa o ipfwadm (ele é lento, não checa argumentos, etc). Neste caso, você não precisa muito deste HOWTO. Veja Apêndice "Diferenças entre ipchains e ipfwadm" e Apêndice "Usando o script ipfwadm-wrapper" para um assunto mais detalhado sobre ipfwadm. 2.3.3. Fazendo regras permanentes Sua configuração atual do firewall é armazenada no kernel, e assim será perdida na reinicialziação. Eu recomendo usar os scripts "ipchains-save" e "ipchains-restore" para fazer estas regras permanentes. Para fazer isto, configure suas regras, então execute (como root): # ipchains-save > /etc/ipchains.rules # Crie um script parecido com o seguinte: #! /bin/sh # Script para controlar a filtragem de pacotes. # Se não existir regras, não faz nada. [ -f /etc/ipchains.rules ] || exit 0 case "$1" in start) echo -n "Ativando a filtragem de pacotes:" /sbin/ipchains-restore < /etc/ipchains.rules || exit 1 echo 1 > /proc/sys/net/ipv4/ip_forward echo "." ;; stop) echo -n "Desativando a filtragem de pacotes:" echo 0 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -X /sbin/ipchains -F /sbin/ipchains -P input ACCEPT /sbin/ipchains -P output ACCEPT /sbin/ipchains -P forward ACCEPT echo "." ;; *) echo "Use: /etc/init.d/packetfilter {start|stop}" exit 1 ;; esac exit 0 Tenha certeza que isto está antes no processo de inicialização. No meu caso (Debian 2.1), eu fiz um link simbólico chamado 'S39packetfilter' em meu diret¢rio "/etc/rcS.d" (isto ser executado antes de S40network). 3. Estou confuso! Roteamento, masquerading, portforwarding, ipautofw... Este HOWTO é sobre filtragem de pacotes. Isto quer dizer decidindo que pacote terá permissão de passar ou não. No entanto, o Linux está sendo um parque de diversões para hackers, você provavelmente desejará mais do que isso. Um problema é que a mesma ferramenta ("ipchains") é usada para controlar tanto o masquerading e transparend proxy, embora estejam nacionalmente separados da filtragem de pacotes (a implementação atual do Linux obscurece estes junto não naturalmente, deixando a impressão que eles foram descontinuados). Masquerading e proxying são discutidos em HOWTOs separados, e as características auto forwarding e port forwarding são controladas por ferramentas separadas, mas mesmo assim muitas pessoas me perguntam sobre elas, eu também vou incluir diversos cenários comuns e indicar quando cada um deve ser aplicado. Os méritos de segurança de cada configuração não serão discutidos aqui. 3.1. Guia rápido de três linhas para Masquerading Isto assume que sua interface externa é chamada "ppp0". Use ifconfig para acha-la, e ajuste ao guia. # ipchains -P forward DENY # ipchains -A forward -i ppp0 -j MASQ # echo 1 > /proc/sys/net/ipv4/ip_forward 3.2. Promoção Gratuita: Regras WatchGuard Você pode comprar firewall separados. Um excelente é o WatchGuard FireBox. Ele é excelente porque eu gosto dele, é seguro, é baseado no Linux, e porque eles estão fundindo a manutanção do ipchains também como um novo código de firewall (almeijado para 2.3). Resumindo, WatchGuard está me pagando enquanto eu trabalho para você. Assim por favor considere este material. http://www.watchguard.com 3.3. Configurações de firewall simples Você trabalha na littlecorp.com. Você tem uma rede interna, e uma conexão dialup (PPP) simples com a Internet (firewall.littlecorp.com que é 1.2.3.4). Você usa Ethernet em sua rede local, e sua máquina pessoal é chamada "myhost". Esta seção ilustrará os diferentes arranjos no qual são comuns. Leia com atenção porque cada um é sutilmente diferente. 3.3.1. Rede Privada: Proxies Tradicionais Neste cenário, pacotes vindo da rede privada nunca atravessam para a Internet, e vice versa. O endereço IP da rede privada usam os endereços de acordo com o RFC1597 Private Network Allocations (ie. 10.*.*.*, 172.16.*.* or 192.168.*.*). O Único meio de se conectar com a Internet é conectando com o firewall, que é a única máquina na rede que conectam ambas. Você executa um programa (no firewall) chamado proxy para fazer isto (há proxies para FTP, acesso Web, telnet, RealAudio, Usenet News e outros serviços). Veja o Firewall HOWTO. Qualquer serviço que você deseja acessar na Internet deve estar no firewall (mas veja "Serviços Internos Limitados" abaixo). Exemplo: Permitindo acesso web da rede privada para a Internet. 1. A rede privada usa endereços 192.168.1.*, com myhost sendo 192.168.1.100, e a interface do firewall firewall sendo designada 192.168.1.1. 2. Um proxy web (eg. "squid") está instalado e configurado no firewall, digo executando na porta 8080. 3. Netscape na rede privada está configurado para usar a porta 8080 do firewall como um proxy. 4. DNS não precisa ser configurado na rede privada. 5. DNS não precisa estar configurado no firewall. 6. Sem rota padrão (gateway) necessitando ser configurado na rede privada. Netscape em myhost lê http://slashdot.org. 1. Netscape conecta-se com o firewall na porta 8080, usando a porta 1050 em myhost. Ele pergunta pela página internet "http://slashdot.org". 2. O proxy procura o nome "slashdot.org", e obtém 207.218.152.131. Ele abre uma conexão com aquele endereço IP (usando a porta 1025 na interface externa do firewall), e pergunta ao servidor web (porta 80) pela página web. 3. Como ele recebe a página web de sua própria conexão com o servidor web, ele copia os dados para a conexão do Netscape. 4. Netscape desenha a página. ie. Do ponto de vista de slashdot.org, a conexão é feita de 1.2.3.4 (interface PPP do firewall) porta 1025 para 207.218.152.131 (slashdot.org) porta 80. Do ponto de vista de myhost, a conexão é feita de 192.168.1.100 (myhost) porta 1050, para 192.168.1.1 (interface Ethernet do firewall) porta 8080. 3.3.2. Rede Privada: Proxies Transparentes Neste cenário, pacotes da rede privada nunca atravessam a Internet e vice versa. O endereço IP da rede privada deve ser escolhido de acordo com o RFC1597 Private Network Allocations (ie. 10.*.*.*, 172.16.*.* or 192.168.*.*). O Único meio de conectar com a internet é conectando com o firewall, que é a única máquina entre as duas redes e que conectam ambas. Você executa um programa (no firewall) chamando um proxy transparente para fazer isto; o kernel envia pacotes de saída para o transparent proxy ao invés de envia-los adiante (ie. ele abastarda o roteamento). Proxyes transparentes querem dizer que o cliente não precisa saber que há um proxy envolvido. Qualquer serviço que desejar acessar na Internet deve estar no firewall. (Mas veja "Serviços Internos Limitados" abaixo). Exemplo: Permitindo acesso web da rede privada para a Internet. 1. A rede privada usa endereços 192.168.1.*, com myhost sendo 192.168.1.100, e a interface Ethernet do firewall sendo 192.168.1.1. 2. Um proxy web transparente (eu acredito que existem patches para squid para permitir ele operar desta maneira, ou tente "transproxy") instalado e configurado no firewall, digo executando na porta 8080. 3. O kernel esta configurado para redirecionar conexão para a porta 80 do proxy, usando ipchains. 4. Netscape na rede privada está configurado para conectar diretamente. 5. DNS precisa estar configurado na rede privada (ie. você precisa executar um servidor DNS como um proxy no firewall). 6. A rota default (gateway) precisa estar configurado na rede privada, para enviar pacotes para o firewall. Netscape em myhost lê http://slashdot.org. 1. Netscape localiza o nome "slashdot.org", e obtem 207.218.152.131. Ele abre uma conexão para aquele endereço IP, usando a porta local 1050, e pergunta ao servidor web (porta 80) pela página web. 2. Como os pacotes de myhost (porta 1050) para slashdot.org (porta 80) passam pelo firewall, eles são direcionados para proxy transparente aguardando na porta 8080. O proxy transparente abre uma conexão usando (usando a porta local 1025) com 207.218.152.131 porta 80 (que é aqui onde os pacotes originais estão indo). 3. Como o proxy recebe a página web de sua conexão com o servidor web, ele copia os dados para a conexão com o Netscape. 4. Netscape desenha a página. ie. Do ponto de vista de slashdot.org, a conexão é feita de 1.2.3.4 (interface PPP do firewall) porta 1025 para 207.218.152.131 (slashdot.org) porta 80. Do ponto de vista de myhost, a conexão é feita de 192.168.1.100 (myhost) porta 1050, para 207.218.152.131 (slashdot.org) porta 80, mas ele está atualmente falando com o proxy transparente. 3.3.3. Rede Privada: Masquerading Neste cenário, pacotes da rede privada nunca atravessam a Internet sem um tratamento especial, e vice versa. O endereço Ip da rede privada devem ser escolhidos de acordo com o RFC1597 Private Network Allocations (ie. 10.*.*.*, 172.16.*.* or 192.168.*.*). Ao invés de usar um proxy, nós usamos facilidades especiais do kernel chamadas "masquerading". Masquerading regravam pacotes quando passam através do firewall, assim eles sempre parecem vir do próprio firewall. Ele então re-escreve as respostas assim eles pareceram estar indo para o recipiente original. Masquerading possui módulos separados para manipular protocolos "enganados", como FTP, RealAudio, Quake, etc. Para procolos realmente difíceis de manipular, a facilidade "auto forwarding" pode manipular muitos destes configurando automáticamente o forward de portas para configurações de portas relacionadas: procure por "ipportfw" (kernels 2.0) ou "ipmasqadm" (kernels 2.1). Quaisquer serviços que você deseja acessar na Internet deve estar no firewall. (Mas veja "Serviços Internos Limitados" abaixo). Exemplo: Permitindo acesso web da rede privada com a Internet. 1. A rede privada possui endereços 192.168.1.*, com myhost sendo 192.168.1.100, e a interface Ethernet do firewall sendo 192.168.1.1. 2. O firewall é configurado para masquerade (mascarar) qualquer pacotes vindo da rede privada e indo para a porta 80 de um host da internet. 3. Netscape está configurado para conectar diretamente. 4. DNS deve ser configurado corretamente na rede privada. 5. O firewall deve ser a rota default (gateway) para a rede privada. Netscape em myhost lê http://slashdot.org. 1. Netscape procura o nome "slashdot.org", e obtém 207.218.152.131. Ele então abre uma conexão para aquele endereço IP, usando a porta local 1050, e pergunta ao servidor web (porta 80) pela página web. 2. Como os pacotes de myhost (porta 1050) para slashdot.org (porta 80) passam através do firewall, eles são regravados para virem da interface PPP do firewall, porta 65000. O firewall possui um endereço Internet válido (1.2.3.4) assim responde pacote de www.linuxhq.com. 3. Como pacotes de slashdot.org (porta 80) para firewall.littlecorp.com (port 65000) vem, eles são regravados para irem para myhost, porta 1050. Esta é a mágica real do masquerading: ele relembra quando ele regravou pacotes enviados para regrar as respostas quando retornarem. 4. Netscape desenha a página. ie. Do ponto de vista de slashdot.org, a conexão é feita de 1.2.3.4 (interface PPP do firewall) porta 65000 para 207.218.152.131 (slashdot.org) porta 80. Do ponto de vista de myhost, a conexão é feita de 192.168.1.100 (myhost) porta 1050, para 207.218.152.131 (slashdot.org) porta 80. 3.3.4. Rede Pública Neste cenário, sua rede pessoal é uma parte da Internet: pacotes pode seguir sem alterações através de ambas as redes. O endereço IP da rede interna deve ser escolhido aplicando por um bloco de endereços IP, assim o resto da rede conhecerá como obter pacotes para você. Isto implica em uma conexão permanente. Neste cenário, a filtragem de pacotes é usada para que pacotes podem ser direcionados entre sua rede e o resto da internet, eg. para restringir o resto da internet para somente acessar seus servidores web internos. Exemplo: Permitindo acesso web de sua rede privada para a Internet. 1. Sua rede interna é configurada de acordo com os blocos de endereços IP que possui registrados, (digamos 1.2.3.*). 2. O firewall está configurado para permitir qualquer tráfego. 3. Netscape está configurado para conectar diretamente. 4. DNS deve estar configurado corretamente em sua rede. 5. O firewall deve ser a rota padrão (gateway) para sua rede privada. Netscape em myhost lê http://slashdot.org. 1. Netscape procura o nome "slashdot.org", e obtém 207.218.152.131. Ele então abre uma conexão para aquele endereço IP, usando a porta local 1050, e pergunta do servidor web (porta 80) pela página web. 2. Pacotes passam através do firewall, simplesmente como passam através de diversos firewalls entre você e slashdot.org. 3. Netscape desenha a página. ie. Aqui existe somente uma conexão: de 1.2.3.100 (myhost) porta 1050, para 207.218.152.131 (slashdot.org) porta 80. 3.3.5. Serviços Internos Limitados Existem alguns truques que você pode usar para permitir a Internet acessar seus serviços internos, em lugar de executar serviços no firewall. Estes funcionarão com aproximação baseada em proxy ou masquerading para conexões externas. Uma simples aproximação é executar um "redirector", que é um poor-man's proxy que aguarda por uma conexão em uma determinada porta, e então abre uma conexão em um porta e host fixo, e copia os dados entre as duas conexões. Um exemplo disto é o programa "redir". Do ponto de vista da Internet, a conexão é feita para seu firewall. Do ponto de vista de seu servidor interno, a coneão é feita da interface interna do firewall para o servidor. Outra aproximação (que requer um kernel 2.0 com patch para ipportfw, ou um kernel 2.1 ou superior) é usar um port forwarding no kernel. Isto faz o mesmo trabalho que o redir em um método diferente: o kernel regrava os pacotes enquanto passam, alterando seus endereços de destino e portas para apontarem para hosts e portas internas. Do ponto de vista da da internet, a conexão é feita para seu firewall. Do ponto de vista de seu servidor interno, uma conexão é feita do host Internet para o servidor. 3.4. David Ranch escreveu um excelente novo HOWTO em Masquerading, que tem uma larga quantidade de materiais com este HOWTO. Você pode atualmente encontrar ete HOWTO em http://www.ecst.csuchico.edu/~dranch/LINUX/index-LINUX.html#ipmasq Mais detalhes sobre Masquerading Logo eu iria esperar que isto fosse encontrado em algum lugar do Projeto de documentação do Linux, em http://www.metalab.unc.edu/LDP A página oficial do Masquerading está disponível em http://ipmasq.cjb.net 4. IP Firewalling Chains Esta seção descreve tudo o que você realmente precisa saber para construir um filtro de pacotes que se encaixe em suas necessidades. 4.1. Como os pacotes atravessam os filtros O kernel inicia com três listas de regras; estas listas são chamadas firewall chains ou simplesmente chains. Os três chains são chamados input output e forward. Quando um pacote entra (digo, através da placa Ethernet) o kernel usa o chain de entrada e decide seu destino. Se ele sobrevive a este passo, então o pr¢ximo passo do kernel é decidir onde enviar o pacote (isto é chamado roteamento). Se o seu destino for outra máquina, ele consultará o chain forward. Finalmente, antes de simplesmente o pacote ir para fora da rede, o kernel consulta o chain output. Um chain é uma lista de checagem de regras. Cada regra diz "se o cabeçalho do pacote parece com isto, então aqui esta o que fazer com o pacote". Se a regra não confere com o pacote, então a próxima regra no chain é consultada. Finalmente, se não existem mais regras a consultar, então o kernel procura no policiamento do chains para decidir o que fazer. Em um sistema consciente em segurança, este policiamento normalmente diz ao kernel para rejeitar ou negar o pacote. Para fans da arte em ASCII, isto mostra o caminho completo do pacote entrando em uma máquina. ---------------------------------------------------------------- | ACEITAR/ interface lo | v REDIRECIONAR _______ | --> C --> S --> ______ --> D --> ~~~~~~~~ -->|forward|----> _______ --> h a |input | e {Routing } |Chain | |output |ACEITAR e n |Chain | m {Decision} |_______| --->|Chain | c i |______| a ~~~~~~~~ | | ->|_______| k t | s | | | | | s y | q | v | | | u | v e v NEGAR/ | | v m | NEGAR/ r Processo Local REJEITAR | | NEGAR/ | v REJEITAR a | | | REJEITAR | NEGAR d --------------------- | v e ----------------------------- NEGAR Aqui está uma descrição passo a passo de cada estágio: Checksum: Este é um teste para verificar se o pacote não está corrompido de alguma forma. Se estiver, ele é negado. Sanity: Esta é atualmente um destas checagens de sanidade antes de cada chain firewall, mas o chain input é o mais importante. Muitos pacotes malformados podem deixar o código de checagem de regras confuso, e estes são negados aqui (uma mensagem é mostrada no syslog se isto acontecer). input chain: Este é o primeiro chain firewall que será testado contra o pacote. Se a decisão do chain não for NEGAR ou REJEITAR, o pacote passa. Demasquerade: Se o pacote é uma resposta de um pacote anterior do masquerade, (mascaramento) ele é desmascarado, e pula para o chain output. Se você não usa o IP masquerading, você pode ignorar esta parte no diagrama. Routing decision (decisão do roteamento): O campo de destino é examinado pelo código de roteamento, para decidir se o pacote deve ir para um processo local (veja processos locais abaixo) ou direcionado (forward) para uma máquina remota (veja forward chains abaixo). Local process (processo local): Um processo sendo executado em uma máquina pode receber pacotes após o passo de decisão do roteamento, e pode enviar pacotes (que vão pelo passo de decisão do reteamento, quando atravessam o chain output). interface lo: Se pacotes de um processo locai são desinados a um processo local, eles vão através do chain output com a interface configurada para "lo", então retorna pelo chain input também com a interface "lo". A interface lo é normalmente chamada de interface loopback. local: Se o pacote não foi criado por um processo local, então o chain forward é checado, caso contrário o pacote vai através do chain output. forward chain: Este chain é usado para qualquer pacote que está tentando passar entre esta máquina para outra. output chain: Este chain é usado para todos os pacotes antes de serem enviados para fora. 4.1.1. Usando ipchains Primeiro, verifique se você tem a versão do ipchains que este documento se refere: $ ipchains --version ipchains 1.3.9, 17-Mar-1999 Note que eu recomendo 1.3.4 (que não possui opões longas, como "--sport"), ou 1.3.8 ou superior; estes são muito estáveis. ipchains tem uma página de manual razoavelmente detalhada (man ipchains), e se você precisa de mais detalhes em particularidades, você deve checar a interface de programação (man 4 ipfw), ou o arquivo net/ipv4/ip_fw.c no código fonte do kernel 2.1.x, que é (obviamente) autoritativo. Também existem um excelente guia de referência rápida por Scott Bronson no pacote fonte, em ambas A4 e US Letter PosScript(TM). Existem diferentes outras coisas que você pode fazer com ipchains. Primeiro operações para gerenciar chains completos. Você inicia com três chains input, output e forward que voce não pode apagar. 1. Criar um novo chain (-N). 2. Deletar um chain vazio (-X). 3. Alterar o policiamento de um chain embutido. (-P). 4. Listar as regras em um chain (-L). 5. Transportar (Flush) as regras fora do chain (-F). 6. Zerar os contadores de pacote e byte em todas as regras no chain (-Z). Existem diversos meios de manipular regras dentro do chain: 1. Adiciona uma nova regra no chain (-A). 2. Insere uma nova na mesma posição no chain (-I). 3. Substitui uma regra na mesma posição no chain (-R). 4. Deleta uma regra na mesma posição no chain (-D). 5. Deleta a primeira regra que confere no chain (-D). Existem poucas operações para masquerading, que estão no ipchains que é um bom lugar para coloca-las: 1. Lista de conexões atuais do masquerade (-M -L). 2. Configura os valores de tempo máximo (timeout) do masquerade (-M -S). (Mas veja "Eu não posso configurar tempo máximo no masquerade") O função final (e talvez a mais útil) permite a você checar o que aconteceu com o dado pacote se ele atravessou o chain. 4.1.2. Operações em uma regra Simples Este é o pão-e-manteiga do ipchains; manipulando regras. Mas especificamente você ira provavelmene usar os comandos append (-A) e delete (-D). os outros (-I para inserir e -R para substituir) são simples extensões nestes conceitos. Cada regra especifica uma cofiguração de condições em que o pacote se encontra, e o que fazer quando a encontra (um "alvo"). Por exemplo, você pode desejar negar todos os pacotes ICMS vindo do endereço IP 127.0.0.1. Assim neste caso nossas condições são que o protocolo deve ser ICMS e que o endereço de origem deve ser 127.0.0.1. Nosso alvo é "NEGAR". 127.0.0.1 a interface "loopback", que você tem mesmo se não possuir uma conexão real da rede. Você pode usar o programa "ping" para gerar tais pacotes (ele simplesmente envia um ICMP tipo 8 (echo request) com todos os hosts cooperativos que devem serviçalmente responder com o pacote ICMS tipo 0 (echo reply). Isto é útil para testes. # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # ipchains -A input -s 127.0.0.1 -p icmp -j DENY # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes --- 127.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss # Você pode ver aqui que o primeiro ping se sucede( o "-c 1"que dizer para o ping enviar somente um pacote simples) Então nós adicionamos (-A) um chain "input", uma regra especificando que para pacotes vindo de 127.0.0.1 ("-s 127.0.0.1") com o protocolo ICMS ("-p ICMS") devem ser negados ("-j DENY"). Quando nós testamos nossa regra, usando o segundo ping, Existe uma pausa antes do programa aguardar a resposta que nunca vem. Nós podemos apagar uma regra em um dos dois meios. Primeiro nós conhecemos que esta é a £nica regra no chain input, nós podemos usar um número para apagar, como em: # ipchains -D input 1 # Para apagar a regra número 1 no chain input. O segundo meio é espelhar o comando -A, mas trocando o -A com -D. Isto é útil quando voce tem um complexo conjunto de regras e você não deseja conta-las para retirar a regra 37. Neste caso, nós podemos usar: # ipchains -D input -s 127.0.0.1 -p icmp -j DENY # A sintaxe de -D deve ter exatamente as mesmas opções que os comandos -A (ou -I ou -R). Se existem múltiplas regras idênticas no mesmo chain, somente a primeira ser apagada. 4.1.3. Especificações de Filtragem Você deve sempre usar "-p" para especificar um protocolo, e "-s" para especificar um endereço de origem, mas existem outras opções que nós podemos usar para especificar características do pacote. O que segue é um compêndio exaustivo. 4.1.3.1. Especificando o endereço IP de origem e Destino Endereços IPs de origem (-s) e destino (-d) podem ser especificados em quatro meios. O meio mais comum usar o nome completo, como "localhost" ou "www.linuxhq.com". O segundo método é especificar o endereço IP como "127.0.0.1". O terceiro e quarto meio permite especificar um grupo de endereços IPs, como "199.95.207.0/24" ou "199.95.207.0/255.255.255.0". Estes dois especificam qualquer endereços IP de 192.95.207.0 para 192.95.207.255 inclusive; os digitos depois da "/" dizem dizem que a parte do endereço IP é significante. "/32" ou "/255.255.255.255" é o padrão (abrange todos os endereços IPs). Para especificar qualquer endereço IP, deve ser usado "/0", como no exemplo: # ipchains -A input -s 0/0 -j DENY # Isto é raramente usado, como o efeito acima é o mesmo como não especificar a opção "-s". 4.1.3.2. Especificando Inversão Muitas opções, incluindo a "-s" e "-d" podem ter seus argumentos seguidos de "!" (que significa não) para atingirem endereços NÃO iguais ao especificado. Por exemplo, "-s ! localhost" atinge qualquer pacote menos de localhost. 4.1.3.3. Especificando o Protocolo O protocolo pode ser especificado com a opção "-p". O protocolo pode ser um número (se conhecer os valores numéricos dos protocolos para IP) ou um nome para casos especiais de "TCP", "UDP" ou "ICMP". Caso especificar "tcp" também funcinará como "TCP". O nome do protcolo pode usar o prefixo "!", para inverter a regra, como "-p ! TCP". 4.1.3.3.1. Especificando portas UDP e TCP Para casos especiais onde um protocolo TCP ou UDP é especificado, existem argumentos extras indicando a porta TCP ou UDP, ou um (exclusivo) faixa de portas (mas veja "Dirigindo Fragmentos" abaixo). Uma faixa é representada pelo caracter ":", como "6000:6010", que abrange 11 números de portas, de 6000 para 6010. Se o menor número é omitido, o padrão será 0. Se o maior número for omitido, o padrão será 65535. Assim para especificar conexões TCP vindo de portas abaixo de 1024, a sintaxe deve ser como "-p TCP -s 0.0.0.0/0 :1023". Números de portas podem ser especificadas por nomes, eg. "www". Note que a especificação de portas devem ser precedidas por uma "!", que inverte a regra. Assim para especificar qualquer pacote TCP menos uma pacote WWW, você deve especificar -p TCP -d 0.0.0.0/0 ! www É importante realizar aquela especificação -p TCP -d ! 192.168.1.1 www é muito diferente de -p TCP -d 192.168.1.1 ! www A primeira especifica qualquer pacote TCP para a porta WWW em qualquer máquina menos 192.168.1.1. O segundo especifica qualquer conexão TCP para qualquer porta em 192.168.1.1 menos a porta WWW. Finalmente, este caso significa não para a porta WWW e não para 192.168.1.1: -p TCP -d ! 192.168.1.1 ! www 4.1.3.3.2. Especificando tipo do ICMP Type e Code ICMP também permite um argumento opcional, mas como ICMP não possui portas, (ICMP possui tipo e código) eles possuem diferentes significados. Você pode especifica-los como nomes ICMP (use ipchains -h icmp para listar os nomes) após a opão "-s", ou como um tipo e código ICMP numérico, onde os tipos seguem a opcão "-s" e o código segue a opção "-d". Os nomes ICMP são razoavelmente logos: você somente precisa usar bastante letras para fazer um nome se distinguir de outros. Aqui está um pequena tabela de alguns dos pacotes ICMP mais comuns: Número Nome Requerido por 0 echo-reply ping 3 destination-unreachable Qualquer tráfego TCP/UDP. 5 redirect roteamente se não estiver executando um daemon de roteamento 8 echo-request ping 11 time-exceeded traceroute Note que os nomes ICMS não podem ser precedidos de "!" no momento. NÃO, NÃO, NÃO, bloqueie as mensagems ICMP do tipo 3! (Veja "Pacotes ICMP" abaixo) 4.1.3.4. Especificando a Interface A opção "-i" especifica o nome de uma interface para atingir. Uma interface é o dispositivo físico onde o pacote vem, ou onde vai. Você pode usar o comando ifconfig para listas as interfaces que estão em "up" (ie. trabalhando no momento). A interface para pacotes de entrada (ie. pacotes atravessando as regras de entrada) é considerada sendo uma interface onde eles vem. Lógicamente, a interface para pacotes enviados (pacotes atravessando as regras de saída) é a interface onde eles vão. A interface para pacotes atravessando os chains forward é também a interface onde eles serão enviados para fora; me parece uma decisão bastante arbitrária. É perfeitamente legal especificar uma interface que atualmente não existe; a regra não atingirá nada até que a interface seja iniciada. Isto é extremamente útil para conexões PPP dialup (normalmente a interface ppp0). Como um caso especial, um nome de interface finalizando com um "+" atinge todas as interfaces (até mesmo se existem atualmente ou não) que começam com aquele string. Por exemplo, para especificar uma regra que atinge todas as interfaces PPP, a opção "-i ppp+" pode ser usada. O nome da interface pode ser precedida por uma "!" para não atingir pacotes que NÃO conferem com a interface especificada. 4.1.3.5. Especificando somente pacotes TCP SYN É muitas vezes útil permitir conexões TCP em uma direção, mas não em outra. Por exemplo, você pode desejar permitir conexões para uma servidor WWW externo, mas não conexões daquele servidor. Uma aproximação ingênua pode ser bloquear pacotes TCP vindo do servidor. Infelizmente, conexões TCP requerem pacotes indo em ambas direções para funcionarem corretamente. A solução é bloquear somente os pacotes usados para requisitar uma conexão. Estes pacotes são chamados SYN (ok, técnicamente eles são pacotes com a flag SYN configurada, e as flags FIN e ACK limpas, mas nós os chamamos de pacotes SYN). Desativando somente estes pacotes, nós podemos parar tentativas de conexões em seus rastros. A flag "-y" é usada para isto: é somente válida para regras que especificam TCP como seu protocolo. Por exemplo, para especificar tentativas de conexão TCP de 192.168.1.1: -p TCP -s 192.168.1.1 -y Mais uma vez, esta opção pode ser invertida se for precedida de um "!", que diz que cada pacote sem ser a inicialização da conexão. 4.1.3.6. Dirigindo Fragmentos As vezes um pacote é muito largo para passar de uma só vez. Quando isto aconteçe, o pacote é dividido em framentos, e enviado como múltiplos pacotes. O outro lado remonta os fragmentos para reconstruir o pacote inteiro. O problema com fragmentos é que muitas das especificaçõess listadas acima (em particular, porta de origem, porta de destino, tipo ICMP, código ICMP, ou opção TCP SYN) requerem que o kernel verifique no inicio do pacote, que é o único que contém o primeiro fragmento. Se sua máquina é a única conectada a uma rede externa, então você pode dizer para o kernel do linux para remontar todos os fragmentos dos pacotes que passam através dele, compilando o kernel com IP: always defragment (sempre desfragmentar) configurado para "Y". Isto nítidamente evita isto. Caso contrário, é importante entender como os fragmentos são tratados pelas regras de filtragem. O primeiro fragmento é tratado como qualquer outro pacote. O segundo e os fragmentos seguintes não são. Assim uma regra -p TCP -s 192.168.1.1 www (especificando uma porta de origem de "www") nunca atingirá um fragmento (do segundo em diante). Nem será o oposto a regra -p TCP -s 192.168.1.1 ! www. No entanto, você pode especificar uma regra especificamente para o segundo e outros fragmentos, usando a opção "-f". Obviamente, é ilegal especificar uma porta TCP ou UDP, tipo ICMP, código ICMP ou a opção TCP SYN em tal regra de fragmento. É também permitido especificar que uma regra que não se aplica ao segundo e fragmentos seguintes, procedendo "-f" com "!". Normalmente é considerado como seguro deixar o segundo e outros fragmentos atravessarem, desde que a filtragem afetará o primeiro fragmento, e assim previne a remontagem no computador de destino, porém, tem sido conhecido bugs para permitir o travamento de máquinas simplesmente enviando fragmentos. Nota para cabeças de rede: pacotes mal formados (TCP, UDP e pacotes ICMP muitos curtos para o c¢digo de firewall ler as portas ou código e tipo ICMP) são tratados como fragmentos também. Sometne fragmentos TCP iniciando na posição 8 são explicitamente derrubados pelo código do firewall (uma mensagem aparecerá no syslog se isto ocorrer). Como um exemplo, a seguinte regra derrubará quaisquer fragmentos indo para 192.168.1.1: # ipchains -A output -f -d 192.168.1.1 -j DENY # 4.1.4. Efeitos do Lado da Filtragem OK, agora nÓs conhecemos todos os métodos que podemos atingir um pacote usando uma regra. Se um pacote confere com a regra, as seguintes coisas podem acontecer: 1. O contador de byte para aquela regra é aumentado pelo tamando do pacote (cabeçalho e tudo). 2. O contador de pacotes para aquela regra é incrementado. 3. Se a regra o requisitar, o pacote é registrado. 4. Se a regra o requisitar, o campo do pacote Type Of Service é alterado. 5. Se a regra o requisitar, o pacote é marcado (não em kernels da série 2.0). 6. O alvo da regra é examinado para decidir o que fazer com o próximo pacote. Para variedade, todos estas regras estão em ordem de importância. 4.1.4.1. Especificando um alvo Um alvo diz ao kenrel o que fazer com um pacote que confere cum uma regra. ipchains usa "-j" (pense como "jump-to" - pular para) para a especificação do alvo. O nome do alvo deve ser menor que 8 letras, e case sensitive: "RETURN" e "return" são completamente diferentes. O caso mais simples é quando não há um alvo especificado. Este tipo de regra (muitas vezes chamado de uma regra de "contagem") é útil para uma contagem simples de certos tipos de pacotes. Se esta regra confere ou não, o kernel simplesmente examina a próxima regra no chain. Por exemplo, para contar o número de pacotes de 192.168.1.1, nós podemos fazer isto: # ipchains -A input -s 192.168.1.1 # (Usando "ipchains -L -v" nós podemos ver os contadores e bytes associados com cada regra). Existem seis alvos especiais. Os primeiros três, ACCEPT, REJECT e DENY são muito simples. ACCEPT aceita o pacote, DENY bloqueia o pacote, é como se nunca o tivesse recebido. REJECT rejeita o pacote, mas (se ele não é um pacote ICMP) gera uma resposta ICMP para a origem para dizer que o destino está inalcançavel. A próxima, MASQ diz ao kernel mascarar (masquerade) o pacote. Para isto funcionar, seu kernel precisa estar compilado com IP Masquerading ativado. Para detalhes sobre isto, veja Masquerading_HOWTO e o apêndice "Diferenças ente ipchains e ipfwadm". Este alvo é somente válido para pacotes atravessando o chain forward. O alvo mais especial é REDIRECT que diz ao kernel para enviar um pacote para uma porta local em vez de onde tivesse vindo. Isto pode ser somente especificado por regras especificando TCP ou UDP como seus protocolos. Opcionalmente, uma porta (nome ou número) podem ser especificadas seguidas de "-j REDIRECT" que causar o redirecionamento do pacote para uma porta particular, até mesmo se for endereçado para outra porta. Este alvo é somente válido para pacotes atravessando a regra de entrada. O alvo final especial é RETURN que é idêntico a cair fora do final da regra imediatamente. (Veja "Configurando o Policiamento" abaixo). Qualquer outro alvo indica uma regra definida pelo usuário (como descrita em "Operações em todo o Chain" abaixo). O pacote começará atravessando as regras naquele chain. Se aquele chain não decide o destino do pacote, então uma vez passam por aquele chain como finalizado, passar se resume na próxima regra no chain atual. Hora de mais arte ASCII. Considere dois (tolos) chains: input (o chain embutido) e Test (um chain definido pelo usuário). `input' `Test' ---------------------------- ---------------------------- | Rule1: -p ICMP -j REJECT | | Rule1: -s 192.168.1.1 | |--------------------------| |--------------------------| | Rule2: -p TCP -j Test | | Rule2: -d 192.168.1.1 | |--------------------------| ---------------------------- | Rule3: -p UDP -j DENY | ---------------------------- Considerando um pacote TCP vindo de 192.168.1.1, indo para 1.2.3.4. Ele entra no chain input, e é testado na regra 1 - sem bater com a regra. A regra 2 bate, e seu alvo é Test, assim a próxima regra examinada é o inicio do teste. Regra 1 em test confere, mas não especifica um alvo, assim a próxima regra é examinada, Regra 2. Isto não confere, assim nós atingimos o final do chain. Nós retornamos ao chain de entrada, onde nós simplesmente examinamos a Regra 2, assim nós agora examinamos Regra3, que não confere. Assim o caminho do pacote é: v __________________________ `input' | / `Test' v ------------------------|--/ -----------------------|---- | Rule1 | /| | Rule1 | | |-----------------------|/-| |----------------------|---| | Rule2 / | | Rule2 | | |--------------------------| -----------------------v---- | Rule3 /--+___________________________/ ------------------------|--- v Veja a seção "Como organizar suas regras de Firewall" para meios para usar regras definidas pelo usu rios efetivamente. 4.1.4.2. Registrando pacotes Este é o lado do efeito que confere com uma regra que possui; você pode ter o pacote que bateu com a regra registrado com a opção "-l". Você normalmente não precisará disto para pacotes rotineiros, mas ela é uma característica útil se você deseja verificar por eventos excepcionais. O kernel registra esta informação parecida como: Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025 L=34 S=0x00 I=18 F=0x0000 T=254 Esta mensagem de registro é designada para ser concisa, e contém informações técnicas úteis somente para gurus de rede, mas ela pode ser útil para o resto de nós. Cada uma que dizer o seguinte: 1. "input" este é o chain que contém a regra que confere com o pacote, causando a mensagem de registro. 2. "DENY" é o que a regra disse fazer com o pacote. Se isto é "-" então a regra não afetou o pacote (uma regra de registro). 3. "eth0" é o nome da interface. Porque isto foi o chain de entrada, ela significa que o pacote veio de "eth0". 4. "PROTO=17" significa que o pacote foi protocolo 17. Uma lista de números de protocolos esta disponível em "etc/prococols". Os mais comuns são 1 (ICMP), 6(TCP) e 17(UDP). 5. "192.168.2.1" significa que o endereço IP de origem do pacote foi "192.168.2.1". 6. ":53" significa que a porta de origem foi 53. Olhando em "/etc/services" é verificado que esta é uma porta "domínio" (ie. esta é provavelmente a resposta do DNS). Para UDP e TCP, este número é a porta de origem. Para ICMP, ele é o tipo ICMP. Para outros, ele será 65535. 7. "192.168.0.1" é o IP de destino. 8. ":1025" significa que a porta de destino foi 1025. Para UDP e TCP, este némero é a porta de destino. Para ICMP, ele é o código ICMP. Para outros, ele será 65535. 9. "L=34" significa que o pacote teve um total de 34 bytes. 10. "S=0x00" campo que significa o tipo do serviço (dividido por 4 para obter o tipo do serviço com usado pelo ipchains). 11. `I=18' é a identificação do IP. 12. "F=0x0000" é os fragmentos 16-bits offset plus flags. Um valor iniciando com "0x4" ou "0x5" significa que o bit de fragmento não esta configurado. "0x2" ou "0x3" significa que o bit "mais fragmentos" esta configurado; espere mais fragmentos após isto. O resto dos números são o offset deste fragmento, dividido por 8. 13. "T=254" é o tempo de vida do pacote. Um é subtraído deste valor para cada ciclo, e normalmente iniciam em 15 ou 255. 14. "(#5)" este pode ser um número final em parênteses em kernels mais recentes (talvez após 2.2.9). Este é um número de regra que causa o registro do pacotes. Em sistemas linux padrões, esta saída do kernel é capturada por klogd (o daemon de registro do kernel) que o envia para o syslogd (o daemon de registro do sistema). O arquivo "/etc/syslog.conf" controla o funcionamento de syslogd, especificando um destino para cada facilidade (facility - em nosso caso, a facilidade é "kernel") e nível (para ipchains, o nível usado é "info"). Por exemplo, meu (Debian) /dec/syslog.conf contém duas linhas que conferem "kern.info": kern.* -/var/log/kern.log *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages Estas significam que as mensagem são duplicadas em "/var/log/kern.log" e "/var/log/messages". Para mais detalhes, veja "man syslog.conf". 4.1.4.3. Manipulando o tipo do Serviço Existem quatro bits raramente usados no cabealho IP, chamaos de bits de tipo do serviço (TOS). Eles afetam o método como os pacotes são tratados; os quatros bits são "Minima Espera", "Máximo processamento", "Máxima Confiabilidade" e "Mínimo Custo". Somente um destes bits é permitido ser configurado. Rob van Nieuwkerk, o autor do TOS-mangling code, colocou o que segue: Especialmente o "Minimo de Espera" é importante para mim. Eu deixo ele ligado para pacotes "interativos" em meu roteador (Linux). Eu uso um modem de 33k6. O linux inicializa pacotes em 3 meios. Deste meio eu tenho performance interativa aceitável enquando faço downloads grandes ao mesmo tempo. (Ele pode até mesmo ser melhor se lá não tiver tal bit no driver serial, mas a latencia é mantida agora por 1.5 segundos). Nota: Obviamente, você tem o controle através de pacotes de entrada: você pode somente controlar a prioridade dos pacotes deixando seu computador. Para negociar prioridades com o outro computador, um protocolo como RSVP (que não conheço nada sobre ele, não me pergunte sobre isto) deve ser usado. O uso mais comum é configurar telnet e conexões de controle FTP para o "Minima Espera" e dados FTP para "Máximo Processamento". Isto pode ser feito como segue: ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10 ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10 ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08 A opção "-t" pede dois parâmetros extras, ambos em hexadecimal. Estes permitem giros complexos dos bitos TOS: o primeira mascara é ANDed com o pacote atual TOS, e então a segunda máscara é XORed com ele. Se isto é muito confuso, apenas use a seguinte tabela: TOS Name Value Typical Uses Minimum Delay 0x01 0x10 ftp, telnet Maximum Throughput 0x01 0x08 ftp-data Maximum Reliability 0x01 0x04 snmp Minimum Cost 0x01 0x02 nntp Andi Klenn foi ao ponto fora dos seguintes (também editado para postaridade): Talvez ele pode ser £til para incluir uma referência para de ifconfig para a discussão sobre bits TOS. O tamanho do dispositivo padrão é afinado para placas ethernet, em modems ele é muito grande e faz os 3 agendamentos das bandas (que possui canais baseados no TOS) funcionarem subótimamente. É uma boa idéia configura-lo para um valor entre 4-10 no modem ou simples canal b para links ISDN: em dispositivos empacotados é necessário um grande canal. Este é uma problema 2.0 e não 2.1, mas em 2.1 ele é um opção do ifconfig (com nettools recentes), enquanto em 2.0 ele requer patches fontes nos controladores de dispositivos para alterar. Assim, para ver máximos beneficios da manipulação TOS para links de modems PPP, faça "ifconfig $1 txqueuelen" em seu /etc/ppp/ip-up script. O número usado depende da velocidade do modem e da quantidade de buffer no modem; aqui configurações que Andi me passou denovo: O melhor valor para dadas configurações precisam ser testadas. Se os canais são muito pequenos em um roteador então os pacotes serão derrubados. Também é claro que um obtém o benefício até mesmo sem regravação TOS, apenas aquela regravação TOS ajuda obter benefícios para programas não coperativos (mas todos os programas padrões do linux são coperativos). 4.1.4.4. Marcando um Pacote Isto permite complexas e poderosas interações com Alexey Kuznetsov's nova Qualidade de implementações de Serviço, também como forwarding baseado em marcas em kernels da série 2.1. Esta opção é no entanto ignorada em kernels da série 2.0. 4.1.4.5. Operações em todo o chain Uma característica muito útil do ipchains é a abilidade de agrupar regras relacionadas em chains. Você pode chamar chains do que quiser, desde que não sejam nomes utilizados pelos chains embutidos (input, output e forward) ou os alvos (MASQ, REDIRECT, ACCEPT, DENY, REJECT ou RETURN). Eu sugiro evitar totalmente identificações em maiúsculas, porque que eu posso usar estas para futura extensão. O nome do chain pode ser maior que 8 caracteres. 4.1.4.6. Criando um novo chain Vou criar um novo chain. Porque eu sou como um imaginador da mesma categoria, eu chamarei isto de test. # ipchains -N test # É muito simples. Agora você pode colocar regras nele como detalhado acima. 4.1.4.7. Apagando um chain Apagar um chain também é simples. # ipchains -X test # Porque "-X"? Bem, todas as boas letras foram usadas. Existem um par de restrições para apagar chains: elas devem ser vazias (veja "Limpando um Chain" abaixo) e eles não devem ser o alvo de qualquer regra. Você não pode deletar qualquer destes três chains embutidos. 4.1.4.8. Limpando um Chain Existe um método simples de esvaziar todas as regras fora do chain, usando o comando "-F". # ipchains -F forward # Se você não especificar um chain, então todos os chains serão limpos. 4.1.4.9. Listando um chain Você pode listar todas as regras em um chain usando o comando "-L". # ipchains -L input Chain input (refcnt = 1): (policy ACCEPT) target prot opt source destination ports ACCEPT icmp ----- anywhere anywhere any # ipchains -L test Chain test (refcnt = 0): target prot opt source destination ports DENY icmp ----- localnet/24 anywhere any # O "refcnt" listado para test é o número de regras que tem test como seu alvo. Este pode ser zero (e o chain ser vazio) antes deste chain ser apagado. Se o nome do chain é omitido, todos os chains são listados. Existem três opções que podem acompanhar "-L". A "-n" (numérica) opção é muito útil porque ela previne ipchains de tentar localizar endereços IP, que (se você esta usando DNS como muitas pessoas) causa larga espera se seu DNS se não estiver configurado corretamente, ou se você filtrará suas requisições DNS. Ele faz as portas serem listadas como números ao invés de nomes. A opção "-v" mostra os detalhes das regras, como o pacote e contadores de byes, as máscaras TOS, a interface, e a marca do pacote. Caso contrário estes valores são omitidos. Por exemplo: # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark sourc e destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywh ere anywhere any Note que o pacote e o contador do byte são mostrados usando os sufixos "K", "M" ou "G" para 100, 1,000,000 e 1,000,000,000 respectivamente. Usando a opção "-x" (n£meros expandidos) são mostrados números completos, não discutirei como eles são grandes. 4.1.4.10. Resetando (Zerando) Contadores Isto é útil para permitir resetar os contadores. Isto pode ser feito com a opção "-Z" (zero counters). Por exemplo: # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark sourc e destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywh ere anywhere any # ipchains -Z input # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark sourc e destination ports 0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywh ere anywhere any # O problema disto é que muitas vezes você precisa conhecer os valores do contador imediatamente antes dele ser resetado. No exemplo acima, muitos pacotes pode passar entre os comandos "-L" e "-Z". Por esta razão, você pode usar "-L" e "-Z" juntos, para resetar os contadores enquando os lê. Infelizmene, se você fizer isto, você não poderá operar em um chain simples: você terá que listar e zerar todos os chains imediatamente. # ipchains -L -v -Z Chain input (policy ACCEPT): pkts bytes target prot opt tosa tosx ifname mark sourc e destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywh ere anywhere any Chain forward (refcnt = 1): (policy ACCEPT) Chain output (refcnt = 1): (policy ACCEPT) Chain test (refcnt = 0): 0 0 DENY icmp ----- 0xFF 0x00 ppp0 local net/24 anywhere any # ipchains -L -v Chain input (policy ACCEPT): pkts bytes target prot opt tosa tosx ifname mark sourc e destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywh ere anywhere any Chain forward (refcnt = 1): (policy ACCEPT) Chain output (refcnt = 1): (policy ACCEPT) Chain test (refcnt = 0): 0 0 DENY icmp ----- 0xFF 0x00 ppp0 local net/24 anywhere any # 4.1.4.11. Configurando o Policiamento Nós mostramos o que acontece quando um pacote atinge o final do chain de entrada embutido quando nós discutimos como um pacote anda através dos chains em "Especificando um Alvo" acima. Neste caso, o policiamento do chain determina o destino do pacote. Somente chains embutidos (input output e forward) tem policiamento, porque se um pacote cai no final de um chain definido pelo usuário, a passagem é resumida no chain anterior. O policiamento pode ser qualquer dos primeiros quatro alvos especiais: ACCEPT, DENY, REJECT, MASQ. MASQ é somente válido para o chain "forward". É também importante notar que o alvo RETURN em uma regra em um dos chains embutidos é útil para acertar o policiamento de um chain quando o pacote se encaixa em uma regra. 4.1.5. Operações em Masquerading Existem diversos parâmetros que você pode usar para IP Masquerading. Eles estão empacotados com ipchains porque não compensa fazer uma ferramenta separada para eles (no entanto isto pode mudar). O comando IP Masquerading é "-M", e ele pode ser combinado com "-L" para listar conexões Masquerade atuais, ou "-S" para configurar parâmetros masquerade. O comando "-L" pode ser acompanhado por "-n" (mostar números ao invés de nomes dos hosts e nomes das portas) ou "-v" (mostra deltas em números sequenciais para conexão masquerade, apenas em caso de preocupação). O comando "-S" deve ser seguido de três valores de timeout, cada um em segundos: para seções TCP, para seções TCP após um pacote FIN, e para pacotes UDP. Se você não desejar alterar um destes valores, simplesmente passe um valor "0". Os valores padrões estão listados em `/usr/src/linux/include/net/ip_masq.h', atualmente 15 minutos, 2 minutos e 5 minutes respectivamente. O valor mais comum para ser alterado é o primeiro, para FTP (veja "Pesadelos FTP" abaixo). Note os problemas com as configurações de timeout listados em "Eu não posso configurar timeouts em masquerade!". 4.1.6. Checando um Pacote Muitas vezes você deseja ver o que esta acontecendo quando um certo pacote entra em sua máquina, tal como para verificar seus chains de entrada. ipchains tem o comando "-C" para permitir isto, usando exatamente as mesmas rotinas que o kernel usa para diagnosticar pacotes reais. Você especifica que chain testará o pacote seguido do argumento "-C" com seu nome. Considerando que o kernel sempre inicia atravessando os chains input, output e forward, você está permitido o inicio da travessia em qualquer chain para fins de testes. Os detalhes do "pacote" são especificados usando a mesma sintaxe usada para expecificar regras do firewall. Em particular, um protocolo ("-p"), endereço de origem ("-s"), endereço de destino ("-d") e interface ("-i") são compulsórios. Se o protoclo é TCP ou UDP, então uma porta simples de origem e destino devem ser especificadas, e um tipo ICMP e um código devem ser especificados para o protocolo ICMP (a não ser que a opção "-f" é espeficada para indicar uma regra de fragmento, em tal caso estas opções são ilegais). Se o protocolo é TCP (e a opção "-f" não é especificada), a opção "-y" deve ser especificada, para indicar que o pacote test deve ter o bit SYN ajustado. Aqui está um exemplo de teste de um pacote TCP SYN de 192.168.1.1 porta 60000 para 192.168.1.2 porta www, vindo na interface eth0, entrando no chain "input". Isto é uma clássica inicialização de conexão WWW. # ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1. 2 www packet accepted # 4.1.7. Multiplas Regras at Once and Watching What Happens Muitas vezes uma simples linha de comando pode resultar em múltiplas regras sendo afetadas. Isto é feito em duas maneiras. Primeiro, se você especificar um hostname que resolve (usando DNS) múltiplos endereços IPs, ipchains pode atuar como se você tivesse digitado m£ltiplos comandos com cada combinação de endereços. Assim se o hostname "www.foo.com" resolve três endereços IPs, e o hostname "www.bar.com" resolve dois endereços IPs, então o comando "ipchains -A input -j reject -s www.bar.com -d www.foo.com" acumula seis regras para o chain de entrada. O outro meio de ter o ipchains fazendo múltiplas ações é usar a opção bidirecional ("-b"). Esta opção faz o ipchains se comportar como se você tivesse digitado o comando duas vezes, a segunda vez com os argumentos "-s" e "-d" invertidos. Assim, para evitar forwarding para ou de 192.168.1.1, você deve fazer o seguinte: # ipchains -b -A forward -j reject -s 192.168.1.1 # Pessoalmente, eu não gosto muito da opção "-b"; se você deseja conveniência, veja "Usando ipchains-save" abaixo. A opção -b pode ser usada com insert ("-I"), delete ("-D") (mas não com variações que pegam regras numúricas), comando append ("-A") e comando check ("-C"). Outra opção útil é "-v" (verbose) que mostra exatamente o que o ipchains está fazendo com seus comandos. Isto é útil se você está negociando com comandos que podem afetar multiplas regras. Por exemplo, aqui nós checamos a ação dos fragmentos entre 192.68.1.1 e 192.168.1.2. # ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * -> * packet accepted tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * -> * packet accepted # 4.2. Exemplos úteis Eu tenho uma conexão dialup PPP (-i ppp0). Eu pego news (-p TCP -s news.virtual.net.au nntp) e mail (-p TCP -s mail.virtual.net.au pop-3) a toda hora que disco. Eu uso o método FTP da Debian para atualizar minha máquina regularmente (-p TCP -y -s ftp.debian.org.au ftp-data). Eu surfo na WEB através do meu proxy ISP enquando isto está sendo feito (-p TCP -d proxy.virtual.net.au 8080), mas odeio os anúncios de doubleclick.net dos arquivos Dilbert (-p TCP -y -d 199.95.207.0/24 e -p TCP -y -d 199.95.208.0/24). Eu não noto pessoas tentando entrar pelo ftp em minha máquina enquando eu estou online (-p TCP -d $LOCALIP ftp), mas não desejo qualquer um de fora pretendendo ter um endereço IP de minha rede interna (-s 192.168.1.0/ 24). Isto é normalmente chamado de IP spoofing, e aqui está um belo meio de proteger você dele em kernels 2.1.x e superiores: veja "Como eu configuro a proteção IP spoof?". A configuração é razoavelmente simples, porque existem atualmente nenhuma outra máquina na minha rede interna. Eu não desejo que nenhum processo local (ie. Netscape, linx etc...) se conecte em doubleclick.net: # ipchains -A output -d 199.95.207.0/24 -j REJECT # ipchains -A output -d 199.95.208.0/24 -j REJECT # Agora eu desejo configurar prioridades em varios pacotes de saída (não existe muitos motivos de se fazer isto em pacotes que entram). Desde que eu tenho diversos números destas regras, é sensato colocar todas elas em um simples chain, chamado ppp-out. # ipchains -N ppp-out # ipchains -A output -i ppp0 -j ppp-out # Minimo de espera para tráfego WEB e telnet. # ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10 # ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10 # Baixo custo para dados ftp, nntp, pop-3: # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02 # Existem algumas restrições em pacotes vindo da inteface ppp0: deixe criar um chain chamado "ppp-in" # ipchains -N ppp-in # ipchains -A input -i ppp0 -j ppp-in # Agora, nenhum pacote vindo de ppp0 deve reivindicar um endereço de origem de 192.168.1.*, assim nós registramos e negamos todos eles: # ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY # Eu permito pacotes UDP para DNS (eu executo um programa de cache de nomes que redireciona todas as requisições para 203.29.16.1, assim eu espero respostas DNS somente dele), entrada FTP, e somente retorno de dados ftp(ftp-data) (que deve somente estar indo para uma porta acima de 1023, e não as portas X11 em torno de 6000). # ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j A CCEPT # ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT # Finalmente, pacotes local-para-local estão OK: # ipchains -A input -i lo -j ACCEPT # Agora, meu policiamento padrão no chain de entrada é DENY, assim qualquer outra coisa é derrubada: # ipchains -P input DENY # NOTA: Eu não configurei meus chains nesta ordem, como os pacotes podem ir através da minha configuração. Seguramente é normalmente feito o DENY (bloqueio) primeiro, então inseridas as regras. É claro, se suas regras requerem chamadas DNS para resolver nomes de hosts, você terá problemas. 4.2.1. Usando ipchains-save Configurar regras de firewall simplesmente do jeito que desejar, e então tente se lembrar dos comandos que usou assim você pode estar na próxima hora em pane. Assim ipchains-save é um script que lê sua configuração atual dos chains e salva em um arquivo. No momento eu mantenho seu suspense sobre o que o ipchains-restore faz. ipchains-save pode salvar uma simples regra, ou todas as regras (se nenhum nome de regra é especificada). A única opção atualmente permitida é "-v" que mostra as regras (para stderr) quando são salvas. O policiamento do chain é também salvo para as regras input, output e forward. # ipchains-save > my_firewall Saving `input'. Saving `output'. Saving `forward'. Saving `ppp-in'. Saving `ppp-out'. # 4.2.2. Usando ipchains-restore ipchains-restore restaura chains que foram salvos com ipchains-save. Ele pode usar duas opções "-v" que descreve cada resgra sendo incluída, e "-f" que força a limpeza de regras definidas pelo usuário se elas existem, como descrito abaixo. Se uma regra definida pelo usuário é encontrada em input, ipchains-restore checa se aquele chain realmente existe. Se existir, então você será perguntado se os chains devem ser limpos (limpeza de todas as regras) ou se a restauração deste chain deve ser ignorada. Se você especificar "-f" na linha de comando, você não será perguntado; a regra será limpa. Por exemplo: # ipchains-restore < my_firewall Restoring `input'. Restoring `output'. Restoring `forward'. Restoring `ppp-in'. Chain `ppp-in' already exists. Skip or flush? [S/f]? s Skipping `ppp-in'. Restoring `ppp-out'. Chain `ppp-out' already exists. Skip or flush? [S/f]? f Flushing `ppp-out'. # 5. Diversos Esta seção contém todas as informações e FAQs que eu pude colocar dentro da estrutura do arquivo abaixo. 5.1. Como organizar suas regras de firewall Esta questão requer muita concentração. Você pode tentar organiza-las para melhorar a velocidade (minimizar o números de checagem de regras para os pacotes mais comuns) ou para diminuir o gerenciamento. Se você tiver um link intermitente, digamos PPP, você pode desejar configurar a primeira regra do chain de entrada para "-i ppp0 -j DENY" na inicialização, então tendo qualquer coisa como esta em seu script ip-up: # Re-create the `ppp-in' chain. ipchains-restore -f < ppp-in.firewall # Replace DENY rule with jump to ppp-handling chain. ipchains -R input 1 -i ppp0 -j ppp-in Seu script ip-down deve se parecer com isto: ipchains -R input 1 -i ppp0 -j DENY 5.2. O que não filtrar Existem muitas coisa que você deve estar atento antes de iniciar a filtragem de tudo o que não desejar. 5.2.1. Pacotes ICMP Pacotes ICMP são usados (entre outras coisas) para indicar falhas de outros protocolos (tal como TCP e UDP). Pacotes "destination-unreachable" em particular. Bloqueando estes pacotes significa que você nunca obterá erros "Host unreachable" ou "No route to host"; qualquer conexão simplesmente aguardará por uma resposta que nunca virá. Isto é irritante, mas raramente fatal. Um problema pior é o papel de pacotes ICMP em na descoberta MTU. Todas as boas implementações TCP (incluindo o Linux) usa a descoberta MTU para tentar entender qual pacote grande que pode ir para um destino sem ser fragmentado (fragmentação diminui a performance, especialmente quando fragmentos ocasionais são perdidos). Descoberta MTU funciona enviando pacotes com o bit "Don't Fragment" ajustado, e então enviando pacotes pequenos se ele obter um pacote ICMP indicando "Fragmentação necessária mas DF ajustado" ("fragmentação necessária"). Este é um tipo de pacote "destination-unreachable", e se ele nunca é recebido, o host local não reduzirá o MTU, e a performance será abismal ou não existente. Note que é comum ele bloquear todas as mensagens de redirecionamento ICMP (tipo 5); estas podem ser usados para manipular roteamento (embora boas stacks IP tem proteções), e assim são frequentemente vistas como ligeiramente ariscadas. 5.2.2. Conexões TCP para DNS (servidores de nomes) Se estiver tentando bloquear conexões TCP de saída, se lembre que DNS nem sempre usa UDP; se a resposta do servidor excede, 512 bytes, o cliente usa uma conexão TCP (ainda indo para o número de porta 53) para obter a resposta. Isto pode ser uma armadilha porque DNS sempre "trabalha principalmente" se você bloquear tais transferências TCP; você pode experimentar esperas longas e estranhas ou outros problemas DNS ocasionais se você o fizer. Se suas requisições DNS sempre são direcionadas para a mesma origem externa (ou diretamente usando a linha nameserver em /etc/resolv.conf ou usando um servidor de nomes cache no modo forward), então você precisará somente permitir conexões TCP para a porta domínio naquele servidor de nomes da porta de domínio local (se usando um servidor de nomes cache) ou de uma porta alta (>1023) se estiver usando /etc/resolv.conf. 5.2.3. Pesadelos FTP O problema clássico de filtragem de pacotes é o FTP. FTP tem dois modos; um é o tradicional que é chamado modo ativo e o mais recente é chamado de modo passivo. Navegadores Web normalmente usam o modo passivo, mas programas FTP de linha de comando normalmente usam o modo ativo. No modo ativo, quando o computador remoto tenta enviar um arquivo (ou até mesmo o resultado de um comando ls ou dir) ele tenta abrir uma conexão TCP com a máquina local. Isto significa que você não pode filtrar estas conexões TCP sem bloquear o FTP ativo. Se você tem a opção de usar o modo passivo, então bem; modo passivo faz as conexäes de dados de cliente para servidor, até mesmo para dados de entrada. Caso contrário, é recomendado que você somente permita conexões TCP para portas acima de 1024 e não entre 6000 e 6010 (6000 é usada pelo X-Window). 5.3. Filtrando o Ping of Death (ping da morte) Computadores Linux são agora imunes aos famosos Ping of Death, que envolve o envio de grandes pacotes ICMP ilegais que sobrecarrega os buffers na pilha TCP no receptor e causa destruição. Se você está protegendo computadores que podem ser vulneráveis, você deve simplesmente bloquear fragmentos ICMP. Pacotes normais ICMP não são grandes o bastante para requerer fragmentação, assim você não deve bloquear nada exceto grandes pings. Eu tenho ouvido (não confirmados) relatos que muitos sistemas requerem somente o último fragmento de um pacote ICMP acima de seu tamanho para o corromper, assim bloquear somente o primeiro fragmento não é recomendado. Sobre os programas exploit e tenho sempre visto que todos usam ICMP, não existem razões que fragmentos TCP ou UDP (ou um protocolo desconhecido) possa ser usado neste ataque, assim bloqueando fragmentos ICMP é somente uma solução temporária. 5.4. Filtrando o Teardrop e Bonk Teardrop e Bonk são dois ataques (principalmente sobre máquinas Microsoft Windows NT) que confiam em fragmentos sobrepostos. Tendo seu roteador Linux fazendo desfragmentação, ou não permitindo todos os fragmentos para suas máquinas vulneráveis são as outras opções. 5.5. Filtrando Bombas de Fragmento Algumas pilhas TCP são comentadas por ter problemas negociando com grandes números de fragmentos de pacotes quando eles não recebem todos os fragmentos. Linux não tem este problema. Você pode filtrar fora fragmentos (que podem interromper legitimos usuários) ou compilar seu kernel com "IP: always defragment" ajustado para "Y" (somente se seu computador linux é o roteador para estes pacotes). 5.6. Modificando regras do firewall Existem alguns assuntos cronometrados envolvidos em alterar regras do firewall. Se você não é cuidadoso, você pode deixar pacotes passarem enquanto estiver fazendo suas alterações. Uma solução simplíssima é fazer o seguinte: # ipchains -I input 1 -j DENY # ipchains -I output 1 -j DENY # ipchains -I forward 1 -j DENY ... faz alterações ... # ipchains -D input 1 # ipchains -D output 1 # ipchains -D forward 1 # Isto bloqueia todos os pacotes durante as alterações. Se suas alterações são restritas para um chain simples, você deve criar um novo chain com novas regras, e então trocar ("-R") a regra que aponta para o antigo chain para a nova que aponta para o novo chain: então você pode apagar o antigo chain. Esta substituição ocorrerá atomicamente. 5.7. Como eu configuro a proteção IP Spoof? IP spoofing é uma técnica onde um host envia pacotes que parecem ser de outro host. Desde que a filtragem de pacotes faz decisões baseadas no endereço de origem, IP spoofing usado para filtros de pacotes bobos. Ele é também usado para ocultar a identidade de atacantes usando ataques SYN, Teardrop, Ping of Death e outros (não se preocupe se não sabe o que eles fazem). O melhor meio para proteger de IP spoofing é chamado Verificação do endereço de Origem, e é feito pelo código de roteamento, e não o firewall completamente. Procure por um arquivo chamado /proc/sys/net/ipv4/conf/all/rp_filter. Se ele existe, então ligando a Verificação do Endereço de Origem (Source Address Verification) em cada inicialização é a solução certa para você. Para fazer isto, insira as seguintes linhas em qualquer lugar de seus scripts init, antes de qualquer placa de rede ser inicializada: # This is the best method: turn on Source Address Verification and get # spoof protection on all current and future interfaces. if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then echo -n "Setting up IP spoofing protection..." for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done echo "done." else echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED. echo "CONTROL-D will exit from this shell and continue system startup. " echo # Start a single user shell on the console /sbin/sulogin $CONSOLE fi Se você não puder fazer isto, você pode inserir manualmente regras para proteger cada interface. Isto requer conhecimento de cada interface. Os kernels 2.1 automáticamente rejeitam pacotes dizendo vir de endereços 127.* (reservados para a interfaceloopback local, lo). Por exemplo, digamos que temos três interfaces, eth0, eth1 e ppp0. Nós podemos usar ifconfig para nos dizer o endereço e netmask das interfaces. Digamos eth0 foi ligada a rede 192.168.1.0 com a netmasq 255.255.255.0, eth1 foi ligada a rede 10.0.0.0 com a netmask 255.0.0.0, e ppp0 conectado com a internet (onde qualquer endereço exceto endereos IP privados são permitodos), nós devemos inserir as seguintes regras: # ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY # ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY # Esta idéia não é tão boa como a Verificação do endereço de origem, porque se sua rede muda, você deve mudar suas regras de firewall para prevenila. Se você está executando um kernel da série 2.0, você pode desejar proteger a interface loopback também, usando uma regra como esta: # ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY # 5.8. Projetos Avançados Existe uma livraria userspace que eu escrevi que está incluida com a distribuição fonte chamada "libfw". Ela usa a abilidade de IP chains 1.3 e acima para copiar pacotes para userspace (usando a opção de configuração IP_FIREWALL_NETLINK). Os valores marcados pode ser usados para especificar os parâmetros da qualidade do serviço para pacotes, ou para especificar como os pacotes devem ser redirecionados para as portas. Eu nunca usei isto, mas se quiser escrever sobre ele, me contacte. Coisas tal como inspeções stateful (eu prefiro o termo firewall dinâmico) pode ser implementado no userspace usando esta biblioteca. Outras idéias bonitas incluem o controle de pacotes em uma base por-usuário fazendo uma procura emum daemos userspace. Isto pode ser muito fácil. 5.8.1. SPF: Condição para Filtragem de Pacotes (Stateful Packet Filtering) ftp://ftp.interlinx.bc.ca/pub/spf no site Brian Murrell;s SPF projeto, que faz conexão localizada no userspace. Ele inclui segurança significativa para sites de baixa largura de banda. Existe uma documentação pequena presente, mas aqui está uma mensagem para a mailing list onde Brian respondeu muitas questões: > I believe it does exactly what I want: Installing a temporary > "backward"-rule to let packets in as a response to an > outgoing request. Yup, that is exactly what it does. The more protocols it understands, the more "backward" rules it gets right. Right now it has support for (from memory, please excuse any errors or omissions) FTP (both active and passive, in and out), some RealAudio, traceroute, ICMP and basic ICQ (inbound from the ICQ servers, and direct TCP connections, but alas the secondary direct TCP connections for things like file transfer, etc. are not there yet) > Is it a replacement for ipchains or a supplement? It is a supplement. Think of ipchains as the engine to allow and prevent packets from travelling across a Linux box. SPF is the driver, constantly monitoring traffic and telling ipchains how to change it's policies to reflect the changes in traffic patterns. 5.8.2. Michael Hasenstein's ftp-data hack Michael Hasenstein da SuSE escreveu um patch para o kernel que incluir localizações de conexões para o ipchains. Ele está atualmente localizado em: http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz 5.9. Avanços Futuros Firewalling e NAT estão sendo redesenhados para 2.3. Planos e discussões estão disponíveis nos arquivos netdev, e na lista ipchains-dev. Estes avanços devem limpar muitos assuntos de usabilidade (realmente, firewall e masquerade não deve ser difícil), e permitir o crescimento de firewalls mais flexíveis. 6. Problemas comuns 6.1. ipchains -L Trava! Você está provavelmente bloqueando chamada DNS; e eventualmente o time out. Tente usar a opção "-n" (númerico) com ipchains, que não mostra nomes. 6.2. Masquerading/Forwarding não funciona! Certifique-se que o forward de pacotes está ativado (em kernels recentes é desativado por padrão, dizendo que pacotes nunca tentam atravessar o chain "forward"). Você pode alterar isto (como root) digitando: # echo 1 > /proc/sys/net/ipv4/ip_forward # Se isto funciona para você, coloque isto em algum lugar em seus scripts de inicialização assim ele será ativado toda hora; você deve configurar seu firewall antes de executar este comando, caso contrário existe uma oportunidade de pacotes escaparem. 6.3. -j REDIR não funciona! Você deve permitir pacotes forward (veja acima) para o redirecionamento funcionar; caso contrário o código de roteamento bloqueia o pacote. Assim se você está simplesmente usando o redirecionamento, e não tem qualquer forward, você deverá estar atento a isto. Note que REDIR (sendo no chain input) não afeta conexões de um processo local. 6.4. Coringas nas Interfaces não funcinam! Existe um bug nas versões 2.1.102 e 2.1.103 do kernel (e alguns patches antigos que produzi) que fazem comandos ipchains falharem ao especificar uma inteface com coringas (tal como -i ppp+). Isto está corrigido nos kernels mais recentes, e no patch 2.0.34 do web site. Você pode também pode corrigir alterando o fonte do kernel alterando a linha 63 ou assim em include/linu/ip_fw.h #define IP_FW_F_MASK 0x002F /* All possible flag bits mask */ Isto deve ser lido como ``0x003F''. Corrija isto e recompile o kernel. 6.5. TOS não funciona! Isto foi meu erro: configurando o campo tipo do serviço não configurava atualmente o tipo do serviço nos kernels versões 2.1.102 entre 2.1.111. Este problema foi corrigido em 2.1.112. 6.6. ipautofw e ipportfw não funcionam! Para 2.0.x, isto é verdade; Eu não tenho tempo para criar e manter um patch gigantesco para ipchains e ipautofw/ipportfw. Para 2.1.x, copia Juan Ciarlante's ipmasqadm de e use-o exetamente como usaria como ipautofw ou ipportfw, exceto ao invés de ipportfw você digita ipmasqadm portfw, e ao invés de ipautofw você deve digitar ipmasqadm autofw. 6.7. xosview está quebrado! Atualize para a versão 1.6.0 ou superior, que não requerem qualquer regra de firewall para kernels 2.1.x. Isto parece ter quebrado denovo no lançamento 1.6.1; por favor fale sobre o erro para o autor (este erro não é meu). 6.8. Falta de Segmentação com "-j REDIRECT"! Este foi um bug no ipchains versão 1.3.3. Por favor atualize. 6.9. Eu não posso configurar tempo limite no masquerade! Verdadeiro (para kernels 2.1.x) até 2.1.123. Em 2.1.124, tentando configurar o tempo limite no masquerading causava uma chamada no kernel (altere return para ret = na linha 1328 de net/ipv4/ip_fw.c). Em 2.1.125, funciona corretamente. 6.10. Eu desejo proteger IPX! Assim como outros, eu vejo. Meu código somente cobre IP, infelizmente. Do lado bom, todos os ganchos estão lá para IPX! Você apenas precisa re-escrever o código; Eu ficaria feliz em ajudar onde for possível. 7. Um exemplo Sério. Este exemplo foi extraído de Michael Neuling e meu tutorial LinuxWorld em Março de 1999; este não é o único meio de resolver o dado problema, mas ele é provavelmente o mais simples. Eu espero que você ache ele informativo. 7.1. O arranjo · Rede interna em Masquerade (vários sistemas opearacionais), que nós chamamos "GOOD". · Servidores expostos em uma rede separada (chamada "DMZ" para Zona Delimitada). · Conexão PPP para a Internet (chamada "BAD"). Rede Externa (BAD) | | ppp0| --------------- | 192.84.219.1| Servidor de Rede (DMZ) | |eth0 | |---------------------------------------------- | |192.84.219.250 | | | | | | | | |192.168.1.250| | | | --------------- -------- ------- ------- | eth1 | SMTP | | DNS | | WWW | | -------- ------- ------- | 192.84.219.128 192.84.219.129 192.84.218.130 | Rede Interna (GOOD) 7.2. Metas Filtragem de Pacotes: PING em qualquer rede Isto é realmente útil para dizer se uma máquina está desativada. TRACEROUTE em qualquer rede Mais uma vez, útil para diagnósticos. Acesso DNS Para fazer ping e DNS mais úteis. Dentro do DMZ: Servidor de Mail · SMTP para externo · Aceitar SMTP da rede interna e externa · Aceitar POP-3 da rede interna Servidor de Nomes · Enviar DNS para externa · Aceitar DNS da rede interna, externa e computador de filtragem de pacotes Servidor Web · Aceitar HTTP da rede interna e externa · Acesso Rsync da rede interna Interna: Permitir WWW, ftp, traceroute, ssh para rede externa Existem coisas razoavelmente padrões para permitir: muitos lugares iniciam permitindo máquinas internas fazer apenas tudo, mas aqui nós estamos sendo restritivos. Permitir SMTP para o Servidor Mail Obviamente, nós desejamos enviar emais para fora. Permitir POP-3 para o Servidor de Mail Isto é como eles lerão seus Emails. Permitor DNS para o servidor de nomes Eles precisam ser capazes de procurar nomes externos para WWW, ftp, traceroute e ssh. Permitir rsync para o servidor Web Isto é como eles sincronizam o servidor web externo com o interno. Permitir WWW para o Servidor WEB Obviamente, eles devem ser capazes de conectar para servidoes web externos. Permitir ping para o computador de filtragem de pacotes Isto é uma coisa cortês para permitir: Isto significa que nós podemos testar se o firewall está operando (assim nós não teremos culpa de um site externos está quebrado). 7.3. Antes da Filtragem de pacotes · Anti-spoofing Desde que nós não temos qualquer roteamento asimétrico, nós podemos simplesmente ligar anti-spoofing para todas as interfaces. # for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done # · Configurando regras de filtragem para NEGAR tudo: Nós ainda permitimos tráfego no loopback local, mas bloqueamos qualquer outra coisa. # ipchains -A input -i ! lo -j DENY # ipchains -A output -i ! lo -j DENY # ipchains -A forward -j DENY # · Configurando Interfaces Isto é normalmente concluído com os scripts de inicialização. Tenha certeza que os passos acima estão concluídos antes das interfaces serem configuradas, para prevenir vazamentos de pacotes antes que as regras sejam definidas. · Inserir módulos masquerade por-protocolo. Nós precisamos inserir o módulo masquerade para FTP, assim que o FTP ativo e passivo "apenas trabalhe" na rede interna. # insmod ip_masq_ftp # 7.4. Filtragem de pacotes por pacotes Com masquerading, é melhor filtrar no chain forward. Divida o chain forward em vários chains de usuários dependendo das interfaces de origem/destino; Isto quebra o problema em pedaços menores. ipchains -N good-dmz ipchains -N bad-dmz ipchains -N good-bad ipchains -N dmz-good ipchains -N dmz-bad ipchains -N bad-good Aceitar (accept) erros simples ICMSs é uma coisa comum a fazer, assim nós criamos um chain para ele. ipchains -N icmp-acc 7.4.1. Configurando pulos para o chain forward Infelizmente, nós somente conhecemos (no chain forward) a interface de saída. Assim, entender que interface o pacote está vindo, nós usamos o endereço de origem (o anti-spoofing previne falsificação de endereço). Note que nós registramos qualquer coisa que não confira com qualquer um destes (obviamente, isto nunca deveria acontecer). ipchains -A forward -s 192.168.1.0/24 -i eth0 -j good-dmz ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j good-bad ipchains -A forward -s 192.84.219.0/24 -i ppp0 -j dmz-bad ipchains -A forward -s 192.84.219.0/24 -i eth1 -j dmz-good ipchains -A forward -i eth0 -j bad-dmz ipchains -A forward -i eth1 -j bad-good ipchains -A forward -j DENY -l 7.4.2. Defina o chain icmp-acc Pacote que são somente um dos erros ICMPs são aceitos, caso contrário, o controle passará ao chain chamado anteriormente. ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCE PT ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT 7.4.3. GOOD (Interno) para DMZ (Servidores) Restrições Internas: · Permitir WWW, ftp, traceroute, ssh para servidores externos · Permitir SMTP para o Servidor de Mail · Permitir POP-3 para o servidor de Mail · Permitir DNS para o servidor de Nomes · Permitir rsync para o servidor Web · Permitir WWW para o servidor Web · Permitir ping para o computador de filtragem de pacotes. Pode fazer o masquerading da rede interna em DMZ, mas aqui nós não faremos. Desde nenhum na rede interna deveria tentar fazer coisas maldosas, nós registramos qualquer pacote que foi negado. ipchains -A good-dmz -p tcp -d 192.84.219.128 smtp -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.219.128 pop-3 -j ACCEPT ipchains -A good-dmz -p udp -d 192.84.219.129 domain -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.219.129 domain -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.218.130 www -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.218.130 rsync -j ACCEPT ipchains -A good-dmz -p icmp -j icmp-acc ipchains -A good-dmz -j DENY -l 7.4.4. Bad (externo) para DMZ (servidores). Restrições DMZ: · Servidor de Mail · SMTP para externo · Aceitar SMTP da rede interna e externa · Aceitar POP-3 da rede interna · Servidores de nomes · Enviar DNS para a rede externa · Aceitar DNS da rede interna, externa e computador de filtragem de pacotes · Servidor Web · Aceitar HTTP da rede interna e externa · Acesso Rsync da rede interna · Nós permitimos coisas da rede externa para DMZ. · Não registrar violações, como elas podem acontecer. ipchains -A bad-dmz -p tcp -d 192.84.219.128 smtp -j ACCEPT ipchains -A bad-dmz -p udp -d 192.84.219.129 domain -j ACCEPT ipchains -A bad-dmz -p tcp -d 192.84.219.129 domain -j ACCEPT ipchains -A bad-dmz -p tcp -d 192.84.218.130 www -j ACCEPT ipchains -A bad-dmz -p icmp -j icmp-acc ipchains -A bad-dmz -j DENY 7.4.5. Good (interna) para Bad (externa). · Restrições Internas: · Permitir WWW, ftp, traceroute, ssh para a rede externa · Permitir SMTP para o servidor de Mail · Permitir POP-3 para servidores de Mail · Permitir DNS para o Servidor de nomes · Permitir rsync para o servidor Web · Permitir WWW para o Servidor Web · Permitir ping para o computador de filtragem de pacotes · Muitas pessoas permitem qualquer coisa da rede interna para a externa, então adicionamos restrições. Nós estamos sendo facistas. · Log de violações. · FTP passivo dirigido pelo módulo masquerade. ipchains -A good-bad -p tcp --dport www -j MASQ ipchains -A good-bad -p tcp --dport ssh -j MASQ ipchains -A good-bad -p udp --dport 33434:33500 -j MASQ ipchains -A good-bad -p tcp --dport ftp --j MASQ ipchains -A good-bad -p icmp --icmp-type ping -j MASQ ipchains -A good-bad -j REJECT -l 7.4.6. DMZ para Good (intena). · Restrições Internas: · Permitir WWW, ftp, traceroute, ssh para a rede externa · Permitir SMTP para o servidor de Mail · Permitir POP-3 para o servidor de Mail · Permitir DNS para o servidor de nomes · Permitir rsync para o servidor Web · Permitir WWW para o servidor Web · Permitir ping para o computador de filtragem · Se nós estamos fazendo o masquerade da rede interna para a DMZ, simplesmente recusamos qualquer outro pacote vindo de outro meio. Permitindo somente pacote que são partes de uma conexão estabelecida. ipchains -A dmz-good -p tcp ! -y -s 192.84.219.128 smtp -j ACCEPT ipchains -A dmz-good -p udp -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-good -p tcp ! -y -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-good -p tcp ! -y -s 192.84.218.130 www -j ACCEPT ipchains -A dmz-good -p tcp ! -y -s 192.84.218.130 rsync -j ACCEPT ipchains -A dmz-good -p icmp -j icmp-acc ipchains -A dmz-bad -j DENY -l 7.4.7. DMZ para bad (externa). · Restrições DMZ: · Servidor de Mail · SMTP para rede externa · Aceitar SMTP da rede interna e externa · Aceitar POP-3 da rede interna · Servidor de Nomes · Enviar DNS para a rede Externa · Aceitar DNS da rede interna, externa e computador de filtragem de pacotes · Servidor Web · Aceitar HTTP da rede interna e externa · Acesso Rsync da rede interna · ipchains -A dmz-bad -p tcp -s 192.84.219.128 smtp -j ACCEPT ipchains -A dmz-bad -p udp -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-bad -p tcp -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-bad -p tcp ! -y -s 192.84.218.130 www -j ACCEPT ipchains -A dmz-bad -p icmp -j icmp-acc ipchains -A dmz-bad -j DENY -l 7.4.8. Bad (externa) para Good (interna). · Nós não permitimos nada (não-masquerade) da rede externa para a rede interna. ipchains -A bad-good -j REJECT 7.4.9. Filtragem de pacote para a própria máquina Linux · Se nós desejamos usar filtragem de pacotes em pacotes vindo da própria máquina, nós precisamos fazer a filtragem no chain de entrada. Nós criamos um chain para cada interface de destino: ipchains -N bad-if ipchains -N dmz-if ipchains -N good-if · Criamos saltos para elas: ipchains -A input -d 192.84.219.1 -j bad-if ipchains -A input -d 192.84.219.250 -j dmz-if ipchains -A input -d 192.168.1.250 -j good-if 7.4.9.1. Bad (externa) interface. · Computador de Filtragem de Pacotes: · PING em qualquer rede · TRACEROUTE em qualquer rede · Acesso DNS · Interface Externa também recebe respostas para pacotes masquerade, e erros ICMP para eles e respostas PING. ipchains -A bad-if -i ! ppp0 -j DENY -l ipchains -A bad-if -p TCP --dport 61000:65096 -j ACCEPT ipchains -A bad-if -p UDP --dport 61000:65096 -j ACCEPT ipchains -A bad-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A bad-if -j icmp-acc ipchains -A bad-if -j DENY 7.4.9.2. Interface DMZ. · Restrições do computador de filtragem de pacotes: · PING em qualquer rede · TRACEROUTE em qualquer rede · Acesso DNS · A interface DMZ recebe respostas DNS, respostas ping e erros ICMP. ipchains -A dmz-if -i ! eth0 -j DENY ipchains -A dmz-if -p TCP ! -y -s 192.84.219.129 53 -j ACCEPT ipchains -A dmz-if -p UDP -s 192.84.219.129 53 -j ACCEPT ipchains -A dmz-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A dmz-if -j icmp-acc ipchains -A dmz-if -j DENY -l 7.4.9.3. Good (interna) Interface. · Restrições do computador de filtragem de pacotes: · PING em qualquer rede · TRACEROUTE em qualquer rede · Acesso DNS · Restrições Internas: · Permitir WWW, ftp, traceroute, ssh para external · Permitir SMTP para o servidor de Mail · Prmitir POP-3 para o servidor de Mail · Permitir DNS para o servidor de Nomes · Permitir rsync para o servidor Web · Permitir WWW para o servidor Web · Permiir ping para o computador de filtragem de pacotes · Interface interna recebe pings, respostas ping e erros ICMP. ipchains -A good-if -i ! eth1 -j DENY ipchains -A good-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A good-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A good-if -j icmp-acc ipchains -A good-if -j DENY -l 7.5. Finalmente · Apaga-se as regras bloqueadas: ipchains -D input 1 ipchains -D forward 1 ipchains -D output 1 8. Apendice: Diferenças entre ipchains e ipfwadm Algumas destas alterações são resultados de alterações no kernel, e alguns resultados do ipchains sendo diferente de ipfwadm. 1. Muitos argumentos foram remapeados: maiúsculas agora indicam um comando, e minúsculas indicam uma opção. 2. Chains arbitrários são suportados, assim até mesmo chains embutidos tem nomes completos ao invés de opções.(eg. "input" ao invés de "-I"). 3. A opção "-k" foi retirada: use "! -y". 4. A opção "-b" atualmente insere/junta/apaga duas regras, em lugar de uma simples regra "bidirecional". 5. A opção "-b" foi passada para "-C" para fazer duas checagens (uma em cada direção). 6. A opção "-x" para "-l" foi substituida por "-v". 7. Multiplas portas de origem e destino não são mais suportadas. Esperançosamente sendo capaz de negar faixa de portas será um pouco feito para aquilo. 8. Interfaces podem somente ser especificadas por nome (não endereço). A sem ântica antiga será silenciosamente alterada nos kernels série 2.1 de qualquer maneira. 9. Fragmentos são examinadas, e não permitidos através do chain. 10. chains de contas foram praticamente apagados. 11. Protocolos arbitrários sobre IP foram testados. 12. O antigo procedimento da conferência SYN e ACK (que foi anteriormente ignorada para pacotes não-TCP) foi alterado; a opção SYN não é válida para regras não específicas TCP. 13. Contadores são agora de 64 bits em máquinas de 32 bits. 14. Opções inversas são agora suportadas. 15. Códigos ICMP são agora suportados. 16. Interfaces curingas são agora suportadas. 17. Manipulações TOS possuem agora checagem de sanidade: O antido código do kernel possuem agora checagem de sanidade: Ipchains agora retorna um erro neste caso, também para outros casos ilegais. 8.1. Tabela de referência rápida. [ Argumentos de comandos são em MAIÚSTULAS, e argumentos de opções são em minúsculas ] Uma coisa a notar, masquerade é especificado por "-j MASQ"; é completamente diferente de "-j ACCEPT", e não é tratado meramente como efeito de um lado, ao contrário do que ipfwadm faz. ================================================================ | ipfwadm | ipchains | Notes ---------------------------------------------------------------- | -A [both] | -N acct | Cria um chain "acct" e tem | |& -I 1 input -j acct | pacotes de saída e entrada | |& -I 1 output -j acct | atravessando-o. | |& acct | ---------------------------------------------------------------- | -A in | input | Uma regra sem alvo ---------------------------------------------------------------- | -A out | output | Uma regra sem alvo ---------------------------------------------------------------- | -F | forward | Use isto como [chain]. ---------------------------------------------------------------- | -I | input | Use isto como [chain]. ---------------------------------------------------------------- | -O | output | Use isto como [chain]. ---------------------------------------------------------------- | -M -l | -M -L | ---------------------------------------------------------------- | -M -s | -M -S | ---------------------------------------------------------------- | -a policy | -A [chain] -j POLICY | (mas veja -r e -m). ---------------------------------------------------------------- | -d policy | -D [chain] -j POLICY | (mas veja -r e -m). ---------------------------------------------------------------- | -i policy | -I 1 [chain] -j POLICY| (mas veja -r e -m). ---------------------------------------------------------------- | -l | -L | ---------------------------------------------------------------- | -z | -Z | ---------------------------------------------------------------- | -f | -F | ---------------------------------------------------------------- | -p | -P | ---------------------------------------------------------------- | -c | -C | ---------------------------------------------------------------- | -P | -p | ---------------------------------------------------------------- | -S | -s | Só pega uma porta de uma | | | faixa, não múltiplas portas. ---------------------------------------------------------------- | -D | -d | Só pega uma porta de uma | | | faixa, não múltiplas portas. ---------------------------------------------------------------- | -V | | Use -i [nome]. ---------------------------------------------------------------- | -W | -i | ---------------------------------------------------------------- | -b | -b | Agora atualmente faz 2 regras. ---------------------------------------------------------------- | -e | -v | ---------------------------------------------------------------- | -k | ! -y | Não funciona ao menos que | | | -p tcp seja também especificado. ---------------------------------------------------------------- | -m | -j MASQ | ---------------------------------------------------------------- | -n | -n | ---------------------------------------------------------------- | -o | -l | ---------------------------------------------------------------- | -r [redirpt] | -j REDIRECT [redirpt] | ---------------------------------------------------------------- | -t | -t | ---------------------------------------------------------------- | -v | -v | ---------------------------------------------------------------- | -x | -x | ---------------------------------------------------------------- | -y | -y | Não funciona ao menos que | | | -p tcp também seja especificado. ---------------------------------------------------------------- 8.2. Exemplos de comandos ipfwadm traduzidos Antigo comando: ipfwadm -F -p deny Novo comando: ipchains -P forward DENY Antigo comando: ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0 Novo comando: ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0 Antigo comando: ipfwadm -I -a accept -V 10.1.2.1 -S 10.0.0.0/8 -D 0.0.0.0/0 Novo comando: ipchains -A input -j ACCEPT -i eth0 -s 10.0.0.0/8 -d 0.0.0.0/0 (Note que não existe equivalente para especificar interfaces por endereço: use o nome da interface. Nesta máquina, 10.1.2.1 corresponde a eth0). 9. Apêndice: Usando o script ipfwadm-wrapper. O shell script ipfwadm-wrapper deve ser um plug-in de substituição do ipfwadm para compatibilidade com ipfwadm 2.3a. A única característica que foi realmente alterada foi a opção "-V". Quando esta é usada, uma alerta é dado. Se a opção "-W" também é usada, a opção "-V" é ignorada. Caso contrário, os scripts tentam encontrar o nome da interface associada com aquele endereço, usando ifconfig. Se aquilo falha (tas como uma interface desativada) então ele sairá com uma mensagem de erro. Este alerta pode ser retirado alterando "-V" para "-W", ou direcionando a saída padrão do script para /dev/null. Se você puder encontrar qualquer erro neste script, ou qualquer alteração entre o ipfwadm e este script, por favor envie um bug para mim: envie um e-mail para ipchains@rustcorp.cm com "BUG-REPORT" no assunto. Por favor liste sua versão antiga do ipfwadm (ipfwadm -h), sua versão do ipchains (ipchains --version), a versão do script ipfwadm wrapper (ipfwadm-wrapper --version). Envie também a saída do ipchains-save. Agradeço antecipadamente. Misture ipchains com este script ipfwadm-wrapper por seu próprio risco. 10. Apêndice: Agradecimentos. Muitos gradecimentos para Michael Neuling, quem escreveu a primeira parte do código do IP chains enquanto trabalhava para mim. Apologias públicas para misturar estas idéias resultantes, enquanto Alan Cox propôs mais tarde e eu começei finalmente a implementar, tendo visto o erro de meus modos. Obrigado a Alan Cox por seu suporte técnico por E-Mail de 24 Horas, e encorajamento. Agradecimento a todos os autores do código ipfw e ipfwadm, especialmetne Jos Vos. Se levantando nos ombros de gigantes e tudo mais... Isto também se aplica a Linus Torvalds e todos os hackers de kernel e do userspace. Agradecimentos aos diligentes testadores de versões beta e caçadores de bugs, especialmente Jordan Mendelson, Shaw Carruthers, Kevin Moule, Dr. Liviu Daia, Helmut Adams, Franck Sicard, Kevin Littlejohn, Matt Kemner, John D. Hardin, Alexey Kuznetsov, Leos Bitto, Jim Kunzman, Gerard Gerritsen, Serge Sivkov, Andrew Burgess, Steve Schmidtke, Richard Offer, Bernhard Weisshuhn, Larry Auton, Ambrose Li, Pavel Krauz, Steve Chadsey, Francesco Potorti` and Alain Knaff.