| |
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 HOWTO excelente sobre Masquerading, que foi um largo sobreposto deste howto. Vocˆ pode 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 seguir
adiante), ou rejeitar o pacote (REJECT - como negar, mas avisa a origem do pacote
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 cabe‡alho 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 source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere 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 source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywhere 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 source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere 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 localnet/24 anywhere any
# ipchains -L -v
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere 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 localnet/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 ACCEPT
# 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 endere‡os 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 ACCEPT
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.
|
