Firewall:

Segurança de redes Linux

Paul Russell
Gleydson Mazioli da Silva
Alexandre Folle de Menezes

Tradução Oficial Alfamídia

Alexandre Folle de Menezes

Versão 1.1, agosto/2002.

As marcas registradas utilizadas no decorrer deste livro são usadas unicamente
para fins didáticos, sendo estas propriedade de suas respectivas companhias.

A Alfamídia não assume qualquer responsabilidade por erros ou omissões, ou por

danos resultantes do uso das informações contidas neste livro.

O capítulo 5 é uma adaptação do texto:

Linux IPCHAINS-HOWTO
Copyright © 1999 - Paul Russell, <ipchains@rustcorp.com
<mailto:ipchains@rustcorp.com>>
Tradução para o português por Gleydson Mazioli da Silva, <gleydson@linuxbr.com.br
<mailto:gleydson@linuxbr.com.br>>

O capítulo 6 é uma adaptação do texto:

Guia Foca GNU/Linux

Copyleft © 1999-2002 - Gleydson Mazioli da Silva.
Fonte: http://focalinux.cipsga.org.br

Os capítulos 1, 2 e 4 foram escritos por:

Copyright © 2002 por Alexandre Folle de Menezes

<mailto:menezes@alfamidia.com.br>

Tradução para português - Brasil, 2002:

Alfamídia Ltda
Rua Félix da Cunha, 818
Porto Alegre - RS - Brasil
Fone/Fax: +55 (51) 3346-7300
E-mail: alfamidia@alfamidia.com.br
URL: http://www.alfamidia.com.br

Esta apostila é uma coletânea de textos com licença GNU ou livres encontrados
na Internet, conforme referências acima.

Este material foi totalmente montado com fins didáticos, sem objetivo
comercial. Foram acrescentados exemplos e exercícios desenvolvidos pela
Alfamídia Ltda.
 CONTEÚDO

CONTEÚDO ................................................................................................................... 5

1 TCP/IP ..................................................................................................................... 11
1.1 A CAMADA FÍSICA ................................................................................................. 11
1.2 A CAMADA DE ENLACE DE DADOS ....................................................................... 12
1.3 A CAMADA DE REDE ............................................................................................. 12
1.3.1 O DATAGRAMA IP............................................................................................... 13
1.3.2 FRAGMENTAÇÃO DOS DATAGRAMAS .................................................................. 14
1.4 CAMADA DE TRANSPORTE .................................................................................... 14
1.4.1 TCP..................................................................................................................... 14
1.4.1.1 O pacote TCP .................................................................................................. 15
1.4.2 UDP .................................................................................................................... 16
1.4.3 ICMP .................................................................................................................. 16
1.5 MONTAGEM DOS PACOTES.................................................................................... 17
1.6 ROTEAMENTO ....................................................................................................... 18
1.6.1 REEMPACOTAMENTO ........................................................................................... 20
EXERCÍCIOS.................................................................................................................... 20

2 ENDEREÇAMENTO............................................................................................. 21
2.1 ENDEREÇAMENTO DE ENLACE (MAC) ................................................................ 21
2.2 ENDEREÇAMENTO DE REDE (IP) .......................................................................... 21
2.2.1 MULTIHOMING .................................................................................................... 22
2.2.2 CLASSES DE REDE IP ........................................................................................... 22
2.2.3 ENDEREÇOS RESERVADOS PARA USO EM REDES PRIVADAS ................................. 23
2.2.4 ENDEREÇOS ESPECIAIS ........................................................................................ 23
2.2.4.1 O endereço de Rede......................................................................................... 23
2.2.4.2 O endereço de Broadcast................................................................................. 23
2.2.4.3 O endereço de Loopback ................................................................................. 24
2.2.5 DIVISÃO EM SUB-REDES ....................................................................................... 24
2.2.5.1 Máscaras de Sub-Rede .................................................................................... 24
2.2.6 SUPER-REDES E CDIR......................................................................................... 25
2.2.7 REFERÊNCIA RÁPIDA DE MÁSCARA DE REDES ...................................................... 25
2.3 ENDEREÇAMENTO DE SESSÃO (PORTAS) ............................................................. 26
EXERCÍCIOS.................................................................................................................... 27

3 CONECTANDO REDES ....................................................................................... 28

3.1 ROTEAMENTO ....................................................................................................... 28
3.1.1 ROTAS ESTÁTICAS E DINÂMICAS .......................................................................... 28
3.1.2 GATEWAY............................................................................................................ 29
3.2 NETFILTER ............................................................................................................ 29
3.2.1 ANATOMIA DO NETFILTER ................................................................................... 30
3.2.2 NAT .................................................................................................................... 30
3.2.2.1 Tipos de NAT .................................................................................................. 31
3.2.3 IMPLEMENTAÇÃO DE UM SERVIÇO NAT .............................................................. 31

4 VULNERABILIDADES NO PROTOCOLO TCP/IP ........................................ 32

4.1 DISPONIBILIDADE DOS DADOS............................................................................... 32
4.2 SOBRE O PROTOCOLO TCP/IP ............................................................................. 32
4.3 IP SPOOFING ......................................................................................................... 32
4.3.1 SERVIÇOS VULNERÁVEIS AO IP SPOOFING:.......................................................... 33
4.3.2 MEDIDAS PARA SE PREVENIR DE ATAQUES IP SPOOFING: .................................... 34
4.4 SOBRE OS ATAQUES ............................................................................................... 34
4.4.1 SYN FLOODING................................................................................................... 34
4.4.2 LAND ................................................................................................................... 34
4.4.3 WINNUKE ............................................................................................................ 35
4.4.4 TEARDROP .......................................................................................................... 35
4.4.5 NEWTEAR............................................................................................................ 36
4.4.6 BONK/BOINK ....................................................................................................... 36
4.4.7 SSPING ................................................................................................................. 36
4.4.8 SMURF ................................................................................................................. 36

5 FIREWALL IPCHAINS........................................................................................ 38
5.1 INTRODUÇÃO ......................................................................................................... 38
5.1.1 O QUE? ................................................................................................................ 38
5.1.2 POR QUE? ............................................................................................................ 38
5.1.3 COMO? ................................................................................................................ 38
5.1.4 ONDE? ................................................................................................................. 39
5.2 BÁSICO SOBRE A FILTRAGEM DE PACOTES........................................................... 39
5.2.1 O QUE É? ............................................................................................................. 39
5.2.2 POR QUE? ............................................................................................................ 39
5.2.3 COMO? ................................................................................................................ 40
5.2.3.1 Um kernel com filtragem de pacotes............................................................... 40
5.2.3.2 O ipchains .................................................................................................. 41
5.2.3.3 Fazendo regras permanentes............................................................................ 41
5.3 ROTEAMENTO, MASQUERADING, PORTFORWARDING, IPAUTOFW...................... 42
5.3.1 GUIA RÁPIDO DE TRÊS LINHAS PARA MASQUERADING ......................................... 42
5.3.2 CONFIGURAÇÕES DE FIREWALL SIMPLES ............................................................. 42
5.3.2.1 Rede Pública .................................................................................................... 43
5.3.2.2 Rede Privada: Masquerading........................................................................... 43
5.3.2.3 Rede Privada: Proxies Transparentes .............................................................. 44
5.3.2.4 Rede Privada: Proxies Tradicionais................................................................. 46
5.3.2.5 Serviços Internos Limitados ............................................................................ 46
5.3.3 MAIS DETALHES SOBRE MASQUERADING ............................................................ 47
5.4 IP FIREWALLING CHAINS ..................................................................................... 47
5.4.1 COMO OS PACOTES ATRAVESSAM OS FILTROS...................................................... 47
5.4.1.1 Usando ipchains......................................................................................... 49
5.4.1.2 Operações em uma regra Simples ................................................................... 50
5.4.1.3 Especificações de Filtragem ............................................................................ 51
5.4.1.4 Efeitos do Lado da Filtragem .......................................................................... 55
5.4.1.5 Operações em Masquerading .......................................................................... 62
5.4.1.6 Checando um Pacote ....................................................................................... 62
5.4.1.7 Multiplas Regras at Once and Watching What Happens ................................ 63
5.4.2 EXEMPLOS ÚTEIS ................................................................................................. 64
5.4.2.1 Usando ipchains-save............................................................................. 65
5.4.2.2 Usando ipchains-restore...................................................................... 66
5.5 DIVERSOS .............................................................................................................. 66
5.5.1 COMO ORGANIZAR SUAS REGRAS DE FIREWALL ................................................... 67
5.5.2 O QUE NÃO FILTRAR ............................................................................................ 67
5.5.2.1 Pacotes ICMP .................................................................................................. 67
5.5.2.2 Conexões TCP para DNS (servidores de nomes)............................................ 68
5.5.2.3 Pesadelos FTP ................................................................................................. 68
5.5.3 FILTRANDO O PING OF DEATH (PING DA MORTE) ................................................. 68
5.5.4 FILTRANDO O TEARDROP E BONK........................................................................ 69
5.5.5 FILTRANDO BOMBAS DE FRAGMENTO ................................................................. 69
5.5.6 MODIFICANDO REGRAS DO FIREWALL ................................................................. 69
5.5.7 COMO EU CONFIGURO A PROTEÇÃO IP SPOOF?.................................................... 69
5.6 PROBLEMAS COMUNS ............................................................................................ 71
5.6.1 IPCHAINS -L TRAVA! ........................................................................................... 71
5.6.2 MASQUERADING/FORWARDING NÃO FUNCIONA!................................................. 71
5.6.3 -J REDIR NÃO FUNCIONA!.............................................................................. 71
5.6.4 CORINGAS NAS INTERFACES NÃO FUNCINAM! ..................................................... 71
5.6.5 TOS NÃO FUNCIONA! .......................................................................................... 71
5.6.6 IPAUTOFW E IPPORTFW NÃO FUNCIONAM! ........................................................... 72
5.6.7 XOSVIEW ESTÁ QUEBRADO! ................................................................................. 72
5.6.8 FALTA DE SEGMENTAÇÃO COM “-J REDIRECT”! ............................................ 72
5.6.9 EU NÃO POSSO CONFIGURAR TEMPO LIMITE NO MASQUERADE! ........................... 72
5.6.10 EU DESEJO PROTEGER IPX! ............................................................................... 72

6 FIREWALL IPTABLES........................................................................................ 73
6.1 INTRODUÇÃO ......................................................................................................... 73
6.1.1 VERSÃO ............................................................................................................... 74
6.1.2 UM RESUMO DA HISTÓRIA DO IPTABLES............................................................... 74
6.1.3 CARACTERÍSTICAS DO FIREWALL IPTABLES ......................................................... 74
6.1.4 FICHA TÉCNICA .................................................................................................... 75
6.1.5 REQUERIMENTOS ................................................................................................. 75
6.1.6 ARQUIVOS DE LOGS CRIADOS PELO IPTABLES ...................................................... 75
6.1.7 INSTALAÇÃO ........................................................................................................ 75
6.1.8 ENVIANDO CORREÇÕES/CONTRIBUINDO COM O PROJETO .................................... 76
6.1.9 O QUE ACONTECEU COM O IPCHAINS E IPFWADM? ............................................... 76
6.1.10 TIPOS DE FIREWALLS ......................................................................................... 76
6.1.11 O QUE PROTEGER?............................................................................................. 77
6.1.12 O QUE SÃO REGRAS?.......................................................................................... 78
6.1.13 O QUE SÃO CHAINS? .......................................................................................... 78
6.1.14 O QUE SÃO TABELAS?........................................................................................ 78
6.1.15 HABILITANDO O SUPORTE AO IPTABLES NO KERNEL .......................................... 79
6.1.16 LIGANDO SUA REDE INTERNA A INTERNET ......................................................... 80
6.2 MANIPULANDO CHAINS ......................................................................................... 80
6.2.1 ADICIONANDO REGRAS - A.................................................................................. 81
6.2.2 LISTANDO REGRAS - L ......................................................................................... 81
6.2.3 APAGANDO UMA REGRA - D ................................................................................ 84
6.2.4 INSERINDO UMA REGRA - I................................................................................... 84
6.2.5 SUBSTITUINDO UMA REGRA - R ........................................................................... 84
6.2.6 CRIANDO UM NOVO CHAIN - N ............................................................................ 85
6.2.7 LISTANDO OS NOMES DE TODOS OS CHAINS ATUAIS ............................................. 86
6.2.8 LIMPANDO AS REGRAS DE UM CHAIN - F.............................................................. 86
6.2.9 APAGANDO UM CHAIN CRIADO PELO USUÁRIO - X............................................... 86
6.2.10 ZERANDO CONTADOR DE BYTES DOS CHAINS - Z ............................................... 87
6.2.11 ESPECIFICANDO O POLICIAMENTO PADRÃO DE UM CHAIN - P............................. 87
6.3 OUTRAS OPÇÕES DO IPTABLES ............................................................................. 88
6.3.1 ESPECIFICANDO UM ENDEREÇO DE ORIGEM/DESTINO .......................................... 88
6.3.2 ESPECIFICANDO A INTERFACE DE ORIGEM/DESTINO ............................................. 89
6.3.3 ESPECIFICANDO UM PROTOCOLO ......................................................................... 90
6.3.3.1 Especificando portas de origem/destino .......................................................... 90
6.3.3.2 Especificando mensagens do protocolo ICMP................................................ 91
6.3.3.3 Especificando pacotes syn............................................................................... 92
6.3.4 ESPECIFICANDO FRAGMENTOS ............................................................................. 92
6.3.5 ESPECIFICANDO UMA EXCEÇÃO ........................................................................... 93
6.3.6 ESPECIFICANDO UM ALVO.................................................................................... 93
6.3.6.1 Alvo REJECT .................................................................................................. 94
6.3.6.2 Especificando LOG como alvo ....................................................................... 94
6.3.6.3 Especificando RETURN como alvo................................................................ 97
6.4 A TABELA NAT (NETWORK ADDRESS TRANSLATION) - FAZENDO NAT ............... 98
6.4.1 CRIANDO UM NOVO CHAIN NA TABELA NAT....................................................... 98
6.4.2 FAZENDO IP MASQUERADING (PARA OS APRESSADOS) ........................................ 98
6.4.3 FAZENDO SNAT.................................................................................................. 99
6.4.3.1 Fazendo IP Masquerading ............................................................................. 100
6.4.4 FAZENDO DNAT ............................................................................................... 101
6.4.4.1 Redirecionamento de portas .......................................................................... 101
6.4.5 MONITORANDO CONEXÕES FEITAS NA TABELA NAT .......................................... 102
6.5 A TABELA MANGLE ............................................................................................. 102
6.5.1 ESPECIFICANDO O TIPO DE SERVIÇO ................................................................... 102
6.5.1.1 Especificando o TOS para tráfego de saída................................................... 103
6.5.1.2 Especificando o TOS para o tráfego de entrada ............................................ 103
6.6 OUTROS MÓDULOS DO IPTABLES ........................................................................ 104
6.6.1 CONFERINDO DE ACORDO COM O ESTADO DA CONEXÃO .................................... 104
6.6.2 LIMITANDO O NÚMERO DE VEZES QUE A REGRA CONFERE ................................. 104
6.6.3 PROTEÇÃO CONTRA PING DA MORTE .................................................................. 105
6.6.4 PROTEÇÃO CONTRA SYN FLOOD ......................................................................... 105
6.6.5 PROTEÇÃO CONTRA IP SPOOFING ...................................................................... 106
6.6.6 ESPECIFICANDO MÚLTIPLAS PORTAS DE ORIGEM/DESTINO................................. 106
6.6.7 ESPECIFICANDO O ENDEREÇO MAC DA INTERFACE........................................... 107
6.6.8 CONFERINDO COM QUEM CRIOU O PACOTE ........................................................ 107
6.7 CAMINHO PERCORRIDO PELOS PACOTES NAS TABELAS E CHAINS .................... 107
6.7.1 PING DE 192.168.1.1 PARA 192.168.1.1 ............................................ 108
6.7.2 CONEXÃO FTP DE 192.168.1.1 PARA 192.168.1.1 ............................................ 109
6.7.3 CONEXÃO FTP DE 192.168.1.1 PARA 192.168.1.4 ............................................ 109
6.7.4 CONEXÃO FTP DE 200.217.29.67 PARA FTP.DEBIAN.ORG.BR ................. 110
6.7.5 PING DE 192.168.1.4 PARA 192.168.1.1 ............................................................ 111
6.7.6 CONEXÃO FTP DE 192.168.1.4 PARA 192.168.1.1 ............................................ 112
6.7.7 CONEXÃO FTP DE 192.168.1.4 PARA FTP.DEBIAN.ORG.BR ................................ 113
6.7.8 CONEXÃO FTP DE 200.198.129.162 PARA 200.217.29.167 .............................. 114
6.7.9 GRÁFICO GERAL DA PASSAGEM DOS PACOTES ................................................... 114
6.8 EXEMPLOS DE CONFIGURAÇÕES DO IPTABLES ................................................... 115
6.8.1 BLOQUEANDO CONEXÕES DE FORA PARA SUA MÁQUINA ................................... 115
6.8.2 MONITORANDO TENTATIVA DE CONEXÃO DE TROJANS EM SUA MÁQUINA ......... 115
6.8.3 CONECTANDO SUA REDE INTERNA A INTERNET ................................................. 116
6.8.4 UM EXEMPLO DE FIREWALL SIMPLES ................................................................. 116

7 O PROXY SQUID ................................................................................................ 121

7.1 INTRODUÇÃO ....................................................................................................... 121
7.2 REQUISITOS BÁSICOS .......................................................................................... 121
7.3 O FEIJÃO COM ARROZ ......................................................................................... 122
7.3.1 INSTALAÇÃO ...................................................................................................... 122
7.3.2 CONFIGURAÇÃO ................................................................................................ 123
7.4 CONTROLANDO OS USUÁRIOS ............................................................................. 124
7.5 EXEMPLOS DE CONFIGURAÇÃO .......................................................................... 126
7.5.1 PERMITIR HTTP_ACCESS PARA APENAS UMA MÁQUINA COM MAC ADDRESS IGUAL A
00:08:C7:9F:34:41 :....................................................................................................... 126
7.5.2 PARA RESTRINGIR ACESSO NAS HORAS DE TRABALHO (9 HORAS - 17 HORAS, DE
SEGUNDA SEXTA) DA FAIXA DE IP 192.168.2.0 MÁSCARA 255.255.255.0 :................... 126
7.5.3 POSSO USAR UMA LISTA DE CONTROLE COM MULTIPLOS HORÁRIOS PARA DIFERENTES
USUÁRIOS?..................................................................................................................... 126
7.5.4 QUERO CRIAR UMA ACL PARA BLOQUEAR SITES COM A PALAVRA SEXO POIS MEUS
FUNCIONÁRIOS FICAM BAIXANDO FILMES EM DIVX DE PORNOGRAFIA:.......................... 127
7.5.5 A IDÉIA ACIMA E ÓTIMA, MAS EU TENHO UMA LISTA DE PALAVRAS PARA FAZER O
MESMO. TEREI QUE REPETIR ESSE COMANDO VÁRIAS VEZES?........................................ 127
7.5.6 AINDA EXISTEM SITES QUE ESCAPAM A ESSE CONTROLE. GOSTARIA DE BLOQUEÁ-LOS
DIRETAMENTE................................................................................................................ 127
7.5.7 MEU DIRETOR RECLAMA QUE AGORA NÃO CONSEGUE MAIS LER AS ENTREVISTAS NO
SITE DA PLAYBOY.......................................................................................................... 127
7.5.8 E UMA LISTA DE DIRETÓRIOS? ........................................................................... 127
7.6 RECURSOS NA INTERNET .................................................................................... 128

APÊNDICE A. LICENÇA DE PUBLICAÇÃO LIVRE...................................... 129

1 TCP/IP
O TCP/IP é um protocolo que conecta redes LAN ou WAN, homogêneas ou
heterogêneas. Ele pode fazer tanto a comunicação entre hosts ponto-a-ponto,
como a comunicação entre cliente e servidor.
Existem dois tipos de interação entre aplicações.
Comunicação Orientada à Conexão é apropriada quando as aplicações
precisam de uma troca contínua de dados.
Em contraste, a Comunicação Não Orientada à Conexão é apropriada
quando as aplicações trocam mensagens isoladas, geralmente com quantidades
pequenas de dados.
Para conseguir uma troca de dados confiável entre os nós, são necessários
vários procedimentos: empacotamento dos dados, determinação do caminho a ser
seguido pelos pacotes, transmissão dos dados, adaptação da taxa de transmissão
de acordo com a capacidade do destino de receber dados, gerenciamento de
erros e retransmissão de dados.
Isso resulta em uma implementação complicada. Para facilitar essa tarefa,
pode se usar uma implementação modular, agrupando as tarefas relacionadas em
camadas distintas.
Para o TCP/IP foi adotado um modelo de comunicação dividido em
camadas, que depois viria a influenciar o modelo OSI que hoje é considerado
padrão.

Cada camada acrescenta informações de controle ao pacote de dados e

transmite seu pacote para a camada inferior, que também adiciona seus dados.

1.1 A camada Física

A camada física trabalha com a mídia física, conectores, e os sinais que
representam 0 e 1. Por exemplo, um modem padrão V.90 ou V.92 implementam
as funções da camada física.

1.2 A camada de Enlace de Dados

A camada de enlace de dados usa a capacidade de transmissão de dados
brutos da camada física e transforma-a em uma linha que pareça à camada de
rede ser livre de erros de transmissão. O protocolo PPP é um exemplo de
camada de enlace de dados.
Na camada de Enlace de Dados, os dados são organizados em quadros.
 Cada quadro tem um cabeçalho que inclui o endereço e controla a
informação e um trailer que é usado para detecção de erros.
Um cabeçalho de quadro de LAN contém a os endereços “físicos” de
origem e destino, que identificam as placas de rede.
Note que o Enlace pode ser uma rede local ou uma conexão Ponto-a-
Ponto.

1.3 A camada de Rede

O IP (Internet Protocol) executa as funções da camada de rede. O IP roteia
os dados entre sistemas. Os dados podem atravessar um único enlace ou podem
ser retransmitidos por vários enlaces pela internet. As unidades de dados são
chamadas datagramas.

Os datagramas têm um cabeçalho IP que contém endereçamento de rede.

Os roteadores examinam o endereço de destino no cabeçalho IP para direcionar
os datagramas para seu destino.
A camada IP é dita Não-Orientada à Conexão porque cada datagrama é
roteado independentemente e o IP não garante a entrega confiável ou em
seqüência dos datagramas.

1.3.1
 O Datagrama IP
O cabeçalho de um datagrama IP pode ser visto na figura abaixo:

Os campos do cabeçalho têm o seguinte significado:

• VERS: versão do protocolo IP que foi usada para criar o datagrama
(4bits)
• HLEN: comprimento do cabeçalho, medido em palavras de 32 bits (4
bits)
• TOTAL-LENGTH: este campo proporciona o comprimento do
datagrama medido em bytes, incluindo cabeçalho e dados.
• SERVICE-TYPE: este campo especifica como o datagrama poderia ser
manejado
• TTL(Time To Live): especifica o tempo que o datagrama está permitido
a permanecer no sistema Internet. Gateways e hosts que processam o
datagrama devem decrementar o campo TTL cada vez que um
datagrama passa por eles e devem removê-lo quando seu tempo
expirar.
• PROTOCOL: especifica qual protocolo de alto nível foi usado para criar
a mensagem que está sendo transportada na área de dados do
datagrama.
• HEADER-CHECKSUM: assegura integridade dos valores do cabeçalho.
• SOURCE AND DESTINATION IP ADDRESS: especifica o endereço IP
de 32 bits do remetente e receptor.
• IDENTIFICATION, FLAGS e FRAGMENTS: estes três campos
controlam a fragmentação e a união dos datagramas. O campo de
identificação contém um único inteiro que identifica o datagrama, é um
campo muito importante porque quando um gateway fragmenta um
datagrama, ele copia a maioria dos campos do cabeçalho do datagrama
em cada fragmento, então a identificação também deve ser copiada,
com o propósito de que o destino saiba quais fragmentos pertencem a
quais datagramas. Cada fragmento tem o mesmo formato que um
datagrama completo.
• FRAGMENT OFFSET: especifica o início do datagrama original dos
dados que estão sendo transportados no fragmento. É medido em
unidades de 8 bytes.

1.3.2 Fragmentação dos Datagramas

Ao realizar trocas de pacotes, os aplicativos da Internet se deparam com
um problema: A diferença do tamanho das mensagens nas diversas redes. Nesse
caso, o protocolo IP suporta o processo de fragmentação, onde os datagramas
são divididos em unidades menores.
O procedimento de fragmentação é realizado por um gateway, onde as
mensagens são partidas em unidades menores e adequadamente identificadas. a
estação destino então reagrupará as instruções baseado nas identificações do
gateway.
Na identificação dos fragmentos o gateway cria um header para cada
fragmento.O header contém os endereços iniciais das redes e uma identificação
referente à mensagem a qual faz parte.
Já na fase de reagrupamento, a estação destino, ao receber o primeiro
fragmento, independentemente de estar na ordem correta, aciona um timer. Se
uma margem de tempo padrão for ultrapassada e a mensagem não estiver
completamente recontituida, a estação destino descarta os fragmentos recebidos
e retorna à origem uma mensagem de erro.

1.4 Camada de Transporte

1.4.1 TCP
O TCP (Transmission Control Protocol) proporciona conexões de dados
confiáveis para as aplicações. O TCP conta com mecanismos que garantem que
os dados são entregues às suas aplicações locais:
• Íntegros
• Em seqüência
• Completos
• Sem duplicatas
Os mecanismos básicos que o TCP usa para conseguir isso são:
• Numeração dos segmentos
• Estabelecimento de Timeout
• Retransmissão dos segmentos
O lado que recebe os dados deve colocá-los em na seqüência correta,
descartando duplicatas e confirmando o recebimento dos mesmos.
O TCP é implementado apenas nos hosts. O TCP é um protocolo full-
duplex, ou seja, ambos os lados podem enviar dados ao mesmo tempo.
O TCP adiciona um cabeçalho ao pacote de dados da aplicação, formando
um segmento.
O TCP passa os segmentos ao IP, que então roteia os mesmos até seu
destino. O TCP aceita segmentos do IP, determina qual aplicação é o destino, e
passa os dados para a aplicação apropriada.

1.4.1.1 O pacote TCP

Os campos do cabeçalho têm o seguinte significado:

• Porta Origem e Destino: estes campos no cabeçalho TCP contêm os
números de portas TCP que identificam os programas de aplicação dos
extremos de uma conexão.
• Número de sequência (32 bits): identifica a posição no fluxo de bytes do
segmento enviado pelo transmissor.
• Número de Reconhecimento (32 bits): este campo identifica a posição
do byte mais alto (ou último byte) que o fonte recebeu.
• Offset: contém um inteiro que especifica o início da porção de dados do
segmento. Este campo é necessário já que o campo Options varia em
comprimento dependendo de quais opções tenham sido incluídas.
• Reserv: reservado para uso futuro.
• Flags (6 bits): determina o propósito e conteúdo do segmento, codificado
assim:
o URG - Campo de ponteiro Urgente é válido
o ACK - Campo de Reconhecimento é válido
o PSH - Este segmento solicita um PUSH
o RST - Reset da conexão
o SYN - Sincroniza numeros de sequências
o FIN - O transmissor chega ao fim do fluxo de bytes.
• WINDOW: através deste campo o software TCP indica quantos dados
ele tem capacidade de receber em seu buffer.
• URGENT POINTER: TCP através deste campo permite que o
transmissor especifique que alguns dados são urgentes, isto significa
que os dados serão expedidos tão rápido quanto seja possível.
• OPTIONS: o software TCP usa este campo para se comunicar com o
software do outro extremo da conexão.
• CHECKSUM: é usado para verificar a integridade tanto do cabeçalho
como dos dados do segmento TCP.
1.4.2 UDP
O UDP não faz nenhuma garantia quanto à entrega dos dados, e é dever
da aplicação trocar informações que confirmem a chegada dos dados. O UDP é
implementado apenas nos hosts.
Com o UDP (User Datagram Protocol), uma aplicação manda uma
mensagem isolada para outra aplicação. O UDP adiciona um cabeçalho,
formando um datagrama UDP.
O UDP passa os segmentos ao IP, que então roteia os mesmos até seu
destino. O UDP aceita segmentos do IP, determina qual aplicação é o destino, e
passa os dados para a aplicação apropriada.

1.4.3 ICMP
O IP tem um projeto simples e elegante. Em condições normais, o IP faz
um uso muito eficiente da memória e recursos de transmissão.
Como IP provê um serviço de expedição de datagramas sem conexão e
não confiável, e além disso um datagrama viaja de um gateway a outro até
alcançar um gateway que possa expedí-lo diretamente à estação destino; é
necessário um mecanismo que emita informações de controle e de erros quando
acontecerem problemas na rede. Alguns dos problemas típicos que podem
acontecer são:
• Um gateway não pode expedir ou rotear um datagrama;
• Um gateway detecta uma condição não usual, tal como
congestionamento.
O mecanismo de controle que emite mensagens quando acontece algum
erro é a função principal do protocolo ICMP. O ICMP permite aos gateways enviar
mensagens de erros ou de controle a outros gateways ou hosts. ICMP provê
comunicação entre o software de IP numa máquina e o software de IP numa outra
máquina.
Tabela 1-1 Mensagens ICMP

Tipo Mensagem
0 Echo Reply
3 Destination Unreachable
4 Source Quench
5 Redirect
8 Echo
11 Time Exceeded
12 Parameter Problem
13 Time Stamp
14 Time Stamp Reply
ICMP somente reporta condições de erros à fonte original. A fonte deve
relatar os erros aos programas de aplicação individuais e tomar ação para corrigir
o problema. Uma das mensagens que o ICMP pode enviar é: Destination
Unreachable, o qual, por sua vez pode ser dos seguintes tipos:
• Network Unreachable (rede não alcançável)
• Host Unreachable (máquina não alcançável)
• Port Unreachable (porta não alcançável)
• Destination Host Unknown (máquina destino desconhecido)
• Destination Network Unknown (rede destino desconhecida)

1.5 Montagem dos pacotes

Na maioria das redes, a informação é dividida em várias partes, chamadas
de pacotes, por duas razões: compartilhamento de recursos e detecção/correção
de erros.
Obviamente não é justo que um único usuário da domine os recursos da
rede por muito tempo. Com a divisão da informação em pacotes, cada um dos
pacotes pode ser enviado/recebido individualmente, permitindo assim que outros
pacotes possam trafegar pela rede. Isso possibilita um compartilhamento justo
dos recursos.
Na maioria dos casos, os dispositivos são conectados através de cabos.
Em alguns casos, usa-se ondas de rádio ou mesmo luz infravermelha. Ambas as
formas de conexão física estão sujeitas a interferências, que podem corromper os
dados que trafegam na rede. Grande parte do trabalho complexo em redes é
detectar e solucionar os erros no tráfego dos dados.
A maioria das técnicas de detecção e correção de erros é baseada no uso
de checksums. Quando a informação é enviada, é anexado em seu final um
número indicando a soma de todos os bytes da mesma. Na recepção, esse
número é comparado com a soma dos dados recebidos. Se houver diferença, a
informação está corrompida e deve ser retransmitida.
Caso o bloco de dados seja muito grande, o reenvio vai tomar muito tempo,
degradando a performance da rede. Para minimizar este problema, divide-se a
informação em pacotes. Se houver algum erro, basta retransmitir apenas os
pacotes corrompidos.

1.6 Roteamento
O TCP/IP pode ser usado em redes locais e para interligação de redes. As
diversas redes locais conversam através dos roteadores. Pode haver mais de um
caminho entre dois pontos.
As redes isoladas são conectadas por meio de Roteadores IP. Roteadores
modernos são equipados com vários slots que podem receber diferentes tipos de
adaptadores de rede: Ethernet, Token-Ring, FDDI, PPP, etc.
O software de IP roda nos hosts e nos roteadores.
• Se o destino está no mesmo enlace, manda-se o datagrama diretamente
para ele;
• Se o destino não está no mesmo enlace, manda-se o pacote para o
roteador local;
• Se o destino não estiver no mesmo enlace do roteador, este irá repassá-
lo ao próximo roteador. Este processo continua até que o destino seja
atingido.
Pode ser útil ilustrar isto com um exemplo. Imagine um simples roteador de
escritório, ele pode ter um link intermitente com a Internet, um número de
segmentos Ethernet alimentando as estações de trabalho e outro link PPP
intermitente fora de outro escritório. Quando o roteador recebe um datagrama de
qualquer de suas conexões de rede, o mecanismo que usa determina qual a
próxima interface deve enviar o datagrama. Computadores simples também
precisam rotear, todos os computadores na Internet têm dois dispositivos de rede.
Um é a interface loopback (explicada acima), o outro é usado para falar com o
resto da rede, talvez uma interface Ethernet, talvez uma interface serial PPP ou
SLIP.

Cada computador mantém uma lista de regras especiais de roteamento,

chamada tabela de roteamento. Esta tabela contém colunas que tipicamente
contém no mínimo três campos, o primeiro é o endereço de destino, o segundo é
o nome da interface que o datagrama deve ser roteado e o terceiro é
opcionalmente o endereço IP da outra máquina que levará o datagrama em seu
próximo passo através da rede. No GNU/Linux você pode ver a tabela de
roteamento usando um dos seguintes comandos:

cat /proc/net/route
route -n
netstat -r

O processo de roteamento é muito simples: um datagrama (pacote IP) é

recebido, o endereço de destino (para quem ele é) é examinado e comparado com
cada item da tabela de roteamento. O item que mais corresponder com o
endereço é selecionado e o datagrama é direcionado a interface especificada.
Se o campo gateway estiver preenchido, então o datagrama é direcionado
para aquele computador pela interface especificada, caso contrário o endereço de
destino é assumido sendo uma rede suportada pela interface.
 Em uma LAN pequena, as tabelas de roteamento podem ser feitas
manualmente. Em redes maiores, os roteadores mantém suas tabelas atualizadas
trocando informações entre si. Roteadores podem descobrir eventos como:
• Uma nova rede adicionada a internet;
• Um caminho foi interrompido, e um destino não pode ser atingido;
• Uma nova rota foi estabelecida para um destino.
Não existe um padrão único para troca de informação entre roteadores. A
liberdade de escolha do protocolo estimulou a competição e levou a grandes
melhorias nos protocolos.
Os protocolos de roteamento mais usados são o RIP e o OSPF.

1.6.1 Reempacotamento
Existe um evento olímpico onde um competidor nada uma parte do
percurso, pega uma bicicleta e pedala outra parte, e corre uma terceira etapa. O
IP funciona da mesma maneira. O datagrama foi projetado para poder ser
mudado de uma mídia para outra até chegar ao seu destino.
Antes de um datagrama ser transmitido por um enlace, ele é empacotado
em um quadro apropriado para o enlace. Quando um roteador recebe o quadro:
• O roteador desempacota o quadro e extrai o datagrama
• O roteador analisa o endereço de destino e descobre a mídia do
próximo trecho
• O roteador reempacota o datagrama em um novo quadro, apropriado
para o próximo laço

Exercícios
1. Em que nível de TCP/IP rodam o telnet e o ftp?
a) Físico
b) Sessão
c) Aplicação
d) Transporte
e) Enlace
2. Qual das seguintes aplicações não usa o protocolo UDP?
a) TFTP
b) DNS
c) RPC
d) FTP
e) SNMP
2 ENDEREÇAMENTO
Em uma rede, o endereço de um dispositivo é uma forma de identificar esse
dispositivo como sendo único. Normalmente, os endereços de rede possuem um
formato padronizado e bem definido.

2.1 Endereçamento de Enlace (MAC)

Os endereços MAC (Media Access Control) são atribuídos aos adaptadores
de rede durante sua fabricação, sendo que cada adaptador tem um endereço que
o identifica como único. Cada fabricante tem um código que o diferencia dos
demais.
Os endereços MAC são escritos no seguinte formato:
00-c0-49-3f-c6-0c
Os primeiros bytes contêm o código do fabricante, os demais contêm o
modelo e número serial do adaptador de rede.

2.2 Endereçamento de Rede (IP)

O protocolo IP usa Endereços IP para identificar estações e para rotear os
dados para elas. À cada estação deve ser atribuído um endereço IP exclusivo.
Um endereço IP é um número de 32 bits. Este tamanho foi escolhido para
caber convenientemente em um registrador de 32 bits. O espaço de
32
endereçamento resultante possui 2 (ou 4.294.967.296) números possíveis.
A notação de ponto foi inventada para facilitar a leitura e escrita dos
números IP. Cada octeto do endereço é convertido para um número decimal, e os
números são separados por pontos. Por exemplo, o endereço da estação
blintz.med.yale.edu é 130.132.19.31.Em redes roteadas, o endereço é
composto de pelo menos dois números: o da rede e o do nó. Se dois dispositivos
possuírem endereços com o mesmo número de rede, então eles estão
localizados na mesma rede. Do contrário, estão em redes distintas, mas unidas
através de um roteador. O número que irá diferencia-los dentro desta rede é o
número do nó.
Os endereços IP são números que identificam seu computador em uma
rede TCP/IP. Inicialmente você pode imaginar o IP como um número de telefone.
O IP é composto por quatro bytes e a convenção de escrita dos números é
chamada de "notação decimal pontuada". Por convenção, cada interface (placa
usada p/ rede) do computador ou roteador tem um endereço IP. Também é
permitido que o mesmo endereço IP seja usado em mais de uma interface de uma
mesma máquina, mas normalmente cada interface tem seu próprio endereço IP.
 As Redes do Protocolo Internet são seqüências contínuas de endereços IP.
Todos os endereços dentro da rede têm um número de dígitos dentro dos
endereços em comum. A porção dos endereços que são comuns entre todos os
endereços de uma rede é chamada de porção da rede. O conjunto dos dígitos
restantes é chamado de porção dos hosts. O número de bits que são
compartilhados por todos os endereços dentro da rede é chamado de netmask
(máscara da rede) e o papel da netmask é determinar quais endereços pertencem
ou não a rede. Por exemplo, considere o seguinte:
Tabela 2-1 Formação de Endereços IP

Endereço do Host 192.168.110.23

Máscara da Rede 255.255.255.0
Porção da Rede 192.168.110.
Porção do Host .23
Endereço da Rede 192.168.110.0
Endereço Broadcast 192.168.110.255
Qualquer endereço que é finalizado em zero em sua netmask revelará o
endereço da rede a que pertence. O endereço de rede é então sempre o menor
endereço numérico dentro da escalas de endereços da rede e sempre possui a
porção host dos endereços codificada como zeros.
O endereço de broadcast é um endereço especial que cada computador em
uma rede "escuta" em adição a seu próprio endereço. Este é um endereço onde
os datagramas enviados são recebidos por todos os computadores da rede.
Certos tipos de dados, como informações de roteamento e mensagens de alerta,
são transmitidos para o endereço broadcast, assim todo computador na rede pode
recebê-las simultaneamente.
Existem dois padrões normalmente usados para especificar o endereço de
broadcast. O mais amplamente aceito é para usar o endereço mais alto da rede
como endereço broadcast. No exemplo acima este seria 192.168.110.255. Por
algumas razões outros sites têm adotado a convenção de usar o endereço de rede
como o endereço broadcast. Na prática não importa muito se usar este endereço,
mas você deve ter certeza que todo computador na rede esteja configurado para
escutar o mesmo endereço broadcast.

2.2.1 Multihoming
Os sistemas não tem endereços IP, as suas interfaces é que os têm. Um
roteador com quatro interfaces de rede precisa de quatro endereços IP.
Um sistema que está ligado a mais de uma sub-rede é chamado de
multihomed.

2.2.2 Classes de Rede IP

Por razões administrativas após pouco tempo no desenvolvimento do
protocolo IP alguns grupos arbitrários de endereços foram formados em redes e
estas redes foram agrupadas no que foram chamadas de classes. Estas classes
armazenam um tamanho padrão de redes que podem ser usadas. As faixas
alocadas são:
Tabela 2-2 Classes de Endereçamento

Bits Mais Máscara de Endereços Possíveis na

Classe Significativos Rede Rede
A 00000 255.0.0.0 0.0.0.0 - 127.255.255.255
B 10000 255.255.0.0 128.0.0.0 - 191.255.255.255
C 11000 255.255.255.0 192.0.0.0 - 223.255.255.255
D 11100 240.0.0.0 224.0.0.0 - 239.255.255.255
E 11110 240.0.0.0 - 255.255.255.255

2.2.3 Endereços reservados para uso em Redes Privadas

Se você estiver construindo uma rede privada que nunca será conectada a
Internet, então você pode escolher qualquer endereço que quiser. No entanto,
para sua segurança e padronização, existem alguns endereços IP's que foram
reservados especificamente para este propósito. Eles estão especificados no
RFC1597 e são os seguintes:
Tabela 2-3 Endereços IP Reservados Para Redes Privadas

Classe Máscara de Rede Endereços Possíveis na Rede

A 255.0.0.0 10.0.0.0 - 10.255.255.255
B 255.255.0.0 172.16.0.0 - 172.31.255.255
C 255.255.255.0 192.168.0.0 - 192.168.255.255

Você deve decidir primeiro qual será a largura de sua rede e então escolher
a classe de rede que será usada.
Pode-se obter um software de Proxy que repassa a informação entre os
computadores internos e o mundo exterior através do endereço de Classe C
registrado.

2.2.4 Endereços Especiais

Nem todos os números podem ser atribuídos a uma sub-rede ou estação.
Por exemplo, alguns endereços são reservados para broadcast, outros são
reservados para tabelas de roteamento.

2.2.4.1 O endereço de Rede

Se um número IP tiver todos os bits da estação em 0, ele se refere à rede, e
não à uma estação específica. Por outro lado, se os bits da sub-rede fossem
todos 0, a identificação seria ambígua, por isso essa combinação é inválida.
2.2.4.2 O endereço de Broadcast
O endereço IP 255.255.255.255 é reservado para broadcast para todos os
sistemas no link local.
Se os bits da estação forem todos 1, é feito um broadcast para a sub-rede
correspondente. Por exemplo, o Endereço 192.18.7.255 significa um broadcast
para a rede 192.18.7.0.
Se os bits da estação e sub-rede forem todos 1, é feito um broadcast para
todas as estações da rede indicada.
Um boa regra é nunca usar endereços de rede ou estação cujos bits sejam
todos iguais (0 ou 1). Daí pode-se deduzir que um campo nunca pode ter menos
do que 2 bits.

2.2.4.3 O endereço de Loopback

No extremo oposto do broadcast, existem mensagens que nunca deixam a
estação local. Existem muitas estações que contém processos clientes e
servidores. Os clientes locais comunicam-se com o servidor por IP. Para fazer
isso, eles geralmente usam um endereço especial chamado Endereço de
Loopback. Por convenção, qualquer endereço começando com 127 é reservado
para esse propósito. Na prática, apenas o endereço 127.0.0.1 é usado.2.2.5
Divisão em sub-redes

Uma rede de Classe A tem 16.777.216 endereços, uma rede de Classe B

suporta 65.536 e uma de Classe C apenas 256. A grande diferença entre esses
números levam à uma alocação muito ineficiente dos blocos e contribui para o
esgotamento dos endereços IP.
Por outro lado, uma organização com um endereço de classe C só tem um
espaço de endereçamento de 1 byte. Pode ser feito então a divisão de 4 bits para
o endereço de sub-rede e 4 bits para o endereço do sistema2.2.5.1
Máscaras de Sub-Rede

O tráfego é roteado para uma estação olhando para as partes de rede e

sub-rede do seu endereço IP. Um endereço de Classe A, B ou C tem a parte de
rede com tamanho fixo. Mas em organizações que escolhem os seus campos de
sub-rede, como as estações e roteadores reconhecem o campo?
A resposta é que os sistemas tem que ser configurados para conhecer o
tamanho da parte de sub-rede do endereço. O tamanho do campo da sub-rede é
armazenado em um parâmetro chamado Máscara de Sub-rede, ou Subnet Mask.
É uma seqüência de 32 bits, onde os bits correspondentes à rede e sub-rede são
setados em 1, e os bits do sistema são setados em 0.
Por exemplo, se quisermos usar o terceiro byte de um endereço classe C
para indicar a sub-rede, a máscara seria:
11111111 11111111 11111111 00000000
As máscaras geralmente são expressas usando a notação decimal, então a
máscara acima seria escrita como 255.255.255.0.
Já no caso de querermos dividir um endereço Classe C usando 4 bits para
o campo da sub-rede, a máscara ficaria assim:
11111111 11111111 11111111 11110000
Ou, na forma decimal, 255.255.255.240.
Bits de Números de Bits da Número de Máscara
Sub-Rede Sub-Rede Estação Máquinas
0 0 8 254 255.255.255.0
1 2 7 128 255.255.255.128
2 4 6 62 255.255.255.192
3 8 5 30 255.255.255.224
4 16 4 14 255.255.255.240
5 32 3 6 255.255.255.248
6 64 2 2 255.255.255.252
7 - 1 - Inválido
A tabela acima mostra as várias maneiras em que um endereço local de
classe C pode ser dividido. Ele também mostra o número de sub-redes e
estações para cada partição. O número de sub-redes e estações é menor do que
o que se espera porque alguns endereços são reservados para propósitos
específicos.2.2.6 Super-Redes e CDIR

O método de atribuir blocos de endereços de classe A, B e C era muito

ineficiente. Um bloco de Classe C proporciona 254 endereços, que pode ser
muito ou pouco, dependendo do tamanho da organização. Pode haver escassez
ou desperdício de endereços.
Faria mais sentido atribuir às organizações o número de bits que elas
realmente precisam. Isso é feito facilmente. Se uma organização precisa de 4000
endereços, ela ganha 12 bits para usar como parte local de seu endereçamento.
Os 20 bits restantes são o prefixo, usado como endereço de super-rede ou prefixo.
A maneira de nomear esse endereço “sem classe” é “/20”. Obter um prefixo de 20
bits é equivalente a obter 16 blocos contínuos de classe C.
Para rotear para uma organização, o roteador precisa saber o número de
bits no prefixo e o padrão de bits designado para o prefixo da organização. O
roteador pode então enviar tráfego para a organização com uma única entrada na
tabela de roteamento. Isto é chamado Classless Internet-Domain Routing
(CDIR).2.2.7 Referência rápida de máscara de redes
A tabela abaixo faz referência às máscaras de rede mais comuns e a
quantidade de máquinas máximas que ela atinge. Note que a especificação da
máscara tem influência direta na classe de rede usada:
 Máscara Máscara (32 bits) Número de
(octal) Máquinas
Classe A:
/8 /255.0.0.0 16,777,214
/9 /255.128.0.0 8,388,606
/10 /255.192.0.0 4,194,302
/11 /255.224.0.0 2,197,150
/12 /255.240.0.0 1,048,574
/13 /255.148.0.0 524,286
/14 /255.252.0.0 262,142
/15 /255.254.0.0 131,070
Classe B:
/16 /255.255.0.0 65,534
/17 /255.255.128.0 32,766
/18 /255.255.192.0 16,382
/19 /255.255.224.0 8,190
/20 /255.255.240.0 4,094
/21 /255.255.248.0 2,046
/22 /255.255.252.0 1,022
/23 /255.255.254.0 510
Classe C:
/24 /255.255.255.0 254
/25 /255.255.255.128 126
/26 /255.255.255.192 62
/27 /255.255.255.224 30
/28 /255.255.255.240 14
/29 /255.255.255.248 6
/30 /255.255.255.252 2
/32 /255.255.255.255 1
Qualquer outra máscara fora desta tabela (principalmente para a classe A),
deverá ser redimensionada com uma calculadora de IP para chegar a um número
aproximado de redes/máquinas aproximados que deseja.

2.3 Endereçamento de Sessão (Portas)

Todo processo que deseje estabelecer comunicação com outro processo
deve se identificar de alguma forma. O TCP/IP implementa essa comunicação
através do uso do conceito de portas (ou ports).
A porta é um número de 16 bits que identifica processos (ou serviços de
rede). O número da porta de origem e o número da porta de destino estão
incluídos no cabeçalho de cada segmento TCP ou pacote UDP.

Um socket é uma combinação de um endereço IP com um número de

porta, e identifica um processo como único na rede.

Exercícios
1. O que significa a sigla MAC?
a) Media Assynchronous Connection
b) Master Assynchronous Connection
c) Media Access Connection
d) Media Access Control
e) Master Access Control

2. Que endereço de rede não é roteado na internet?

a) 128.9.0.0
b) 10.0.0.0
c) 191.168.72.0
d) 171.20.20.0
e) 8.0.0.0

3. São máscaras padrão de redes classe A, B e C:

a) 0.0.0.255, 0.0.255.255, 0.255.255.255
b) 0.0.0.0, 0.0.0.255, 0.0.255.255
c) 255.0.0.0, 255.255.0.0, 255.255.255.0
d) 0.0.0.0, 255.0.0.0, 255.255.0.0
e) 255.255.255.0, 255.255.0.0, 255.0.0.0
3 CONECTANDO REDES
Adaptado de
<http://www.conectiva.com/doc/livros/online/8.0/servidor/conectividade.html#CONECTANDO-
REDES>
A criação de grandes redes de computadores é possível graças à
interligação de pequenas redes de computadores. No entanto, essa divisão de
redes em pequenas unidades gera a necessidade de se criar meios que permitam
que essas unidades sejam capazes de se conectar e trocar informações.
Além dos meios físicos (cabos, hubs, roteadores, etc.) são necessários
também os meios lógicos que permitam essa troca de informação. Serão
estudados a seguir os conceitos básicos sobre roteamento, e em seguida será
visto um tipo particular de roteamento chamado NAT (Network Address
Translation).

3.1 Roteamento
Para entender melhor como funciona o processo de transmissão de um
pacote de dados dentro de uma rede, pode ser feita uma analogia com o processo
de uma ligação telefônica. Ao se discar o número do telefone com quem se deseja
falar, a sua central telefônica verifica se o número está conectado a ela, se não
estiver ela "encaminha" a sua ligação para outra central que por sua vez faz o
mesmo teste, até chegar a central onde se localiza o número de destino. Os
códigos de país, área e o prefixo do telefone são utilizados para determinar para
qual central sua ligação deve ser encaminhada. Cada central por onde a ligação
passa, além de decidir para onde encaminhar a ligação, funciona também como
uma espécie de retransmissora ao receber sua ligação de uma central e repassá-
la para outra.
Um processo bastante semelhante acontece em uma rede de
computadores, ou seja, quando um computador tenta se comunicar com outro que
não esteja diretamente ligado a ele (ou em sua sub-rede), ele deve enviar seus
datagramas para uma máquina especial, ligada a duas ou mais redes e que
encaminhará os datagramas para o destino. Essa máquina especial recebe o
nome de gateway ou roteador, e ao processo de decidir para onde repassar os
datagramas chamamos de roteamento.
A idéia básica do roteamento é a criação de regras que estabeleçam que
caminho um datagrama deve tomar baseado no endereço de destino dele. Em
uma máquina cliente essa regra é bastante simples: tudo que não for para a rede
local deve ser enviado para a máquina gateway (essa regra é chamada rota
padrão). Já em uma máquina gateway podem ser necessárias muito mais regras,
principalmente se essa máquina está conectada a um grande número de redes.

3.1.1 Rotas estáticas e dinâmicas

Existem dois tipos de rotas que podem ser utilizadas por um roteador: rotas
estáticas e dinâmicas. As rotas estáticas são explicitamente configuradas pelo
administrador, enquanto que as rotas dinâmicas podem ser "aprendidas" através
da utilização de um serviço especial para esse fim.
As rotas dinâmicas utilizam protocolos especiais como o RIP (Routing
Information Protocol <http://www.conectiva.com/doc/livros/online/8.0/servidor/>),
OSPF (Open Shortest Path First) e BGP (Border Gateway Protocol) para divulgar
e aprender rotas. O Linux possui o serviço routed que é capaz de utilizar estes
protocolos.
As rotas estáticas podem ser configuradas com o auxílio do Linuxconf, e
não necessitam de nenhum serviço adicional. Será visto aqui apenas a
configuração de rotas estáticas, já que a utilização de rotas dinâmicas
normalmente só é necessária em grandes redes e Sistemas Autonômos (AS).

3.1.2 Gateway
Um gateway ou roteador funciona como uma porta de saída de uma rede;
ele é um máquina equipada com duas ou mais interfaces ou dispositivos de rede e
é capaz de fazer o repasse de datagramas para fora ou para dentro da rede.
Essa máquina possui diferentes números IPs associados a cada interface.
O Linux é capaz de decidir automaticamente por qual interface de rede ele deve
enviar datagramas baseado nos IPs de cada interface e na definição da rota
padrão.
Existem alguns casos nos quais é necessário informar ao seu gateway
como alcançar uma determinada rede, por exemplo, no caso dessa rede estar por
trás de um outro gateway. Para esses casos especiais é necessário inserir uma
rota estática para esta rede (caso não se esteja usando um serviço de rotas
dinâmicas).

3.2 Netfilter
O kernel do Linux possui recursos bastante sofisticados para filtrar e
transformar pacotes IP. Esses recursos, agrupados sob o nome de netfilter,
podem ser configurados com o auxílio do comando iptables. O netfilter permite a
construção de firewalls e de gateways com NAT (Network Address Translation). O
site oficial do netfilter é <http://netfilter.gnumonks.org/>.
• Serão estudados aqui os conceitos básicos do netfilter e como utilizar o
recurso de NAT.

3.2.1
 Anatomia do netfilter

O netfilter possui um conjunto de ganchos (também chamados de cadeias

ou chain) em vários pontos da pilha de um protocolo (será considerado aqui
somente o protocolo IPv4). Cada gancho é um ponto no caminho que um pacote
IP percorre ao entrar ou sair de uma máquina, conforme a figura abaixo:

O gancho PRE-ROUTING está ligado à entrada de pacotes na máquina;

após a decisão de roteamento os pacotes que não são destinados à máquina local
atravessam o gancho FORWARD e finalmente saem da máquina passando pelo
gancho POST-ROUTING. O gancho INPUT é atravessado pelos pacotes que
chegam com destino à máquina local enquanto que o gancho OUTPUT é utilizado
pelos pacotes originados na máquina local.
Para filtrar ou transformar pacotes IP, o netfilter possui estruturas chamadas
tabelas, que se ligam a conjuntos de ganchos. Essas tabelas são implementadas
através de módulos do kernel. Por padrão o kernel possui três tabelas: filter, nat e
mangle.
Cada tabela possui regras ligadas a cada um dos ganchos usados por ela.
Estas regras podem ser criadas pelo administrador, de acordo com suas
necessidades (isto é, um firewall, NAT, etc.). Cada regra especifica um padrão ou
critério a ser comparado com pacotes IPs e um alvo, ou o que fazer com cada
pacote que casa com o padrão especificado. Os alvos podem ser ações pré-
definidas de cada tabela, como por exemplo, DROP ou MASQUERADE, que,
respectivamente, descartam ou mascaram um pacote, ou ainda uma outra regra.
A tabela nat, que será utilizada a seguir, está ligada aos ganchos PRE-
ROUTING, POST-ROUTING e OUTPUT.
3.2.2 NAT
Os números IPs da Internet são finitos e cada número deve ser único. O
crescimento explosivo da Internet tem transformado estes números em um recurso
escasso, e para se obter um número ou conjunto de IPs válidos é necessário
requisitá-los a um órgão regulador e pagar por eles. Logo, em muitos casos não
se justifica construir redes locais utilizando-se números IPs válidos.
Como alternativa certos intervalos de números IPs são considerados
inválidos, isto é, não são utilizados na Internet, permitindo assim que eles possam
ser utilizados em intranets sem problemas, ou seja, várias intranets podem utilizá-
los desde que não estejam diretamente conectadas umas às outras. No entanto,
isso cria um dilema: como conectar uma intranet que utiliza números IPs inválidos
à Internet?
A resposta a essa pergunta é através da utilização de um roteador que
possua um número IP válido e que seja capaz de fazer uma tradução de
endereços de rede (NAT). Para entender melhor o que isso significa considere o
seguinte cenário: uma rede local ligada à Internet através de um roteador com
conexão discada. Ao se conectar na Internet, a máquina gateway recebe um
número IP válido do provedor de acesso. Quando uma máquina da intranet
precisa se conectar a um site (por exemplo), ela envia seus pacotes IPs com a
requisição à máquina gateway, que por sua vez altera os cabeçalhos destes
pacotes inserindo o número IP que ela recebeu do provedor e os envia através de
sua conexão. O site responde à requisição enviando a resposta para a máquina
gateway que altera novamente os cabeçalhos dos pacotes e os envia à máquina
que originalmente os requisitou. Dessa forma, cada máquina da intranet se
comporta como se estivesse ligada diretamente à Internet, enquanto que as várias
máquinas na Internet "enxergam" apenas a sua máquina gateway.

3.2.2.1 Tipos de NAT

É possível dividir o NAT em dois tipos: o NAT de origem (SNAT) e o NAT de
destino (DNAT).
O NAT de origem é quando você altera o endereço de origem de um
pacote, isto é, a conexão passa a ter um outro endereço de origem. Esse tipo de
NAT é sempre criado utilizando-se o gancho POSTROUTING, logo antes do
pacote sair da máquina. O mascaramento (como é também conhecido) é uma
forma de SNAT.
O NAT de destino se caracteriza pela alteração do endereço de destino do
pacote, isto é, alterando o destino de uma conexão que passa pela máquina. Este
tipo de NAT é sempre criado utilizando-se o gancho PRE-ROUTING.
Balanceamento de carga, proxys transparentes e repasse de portas são tipos de
DNAT.

3.2.3 Implementação de um serviço NAT

Um serviço de NAT é necessário em soluções de Conexão Discada, mas
pode ser utilizado também como uma forma de aumentar a segurança de uma
intranet, uma vez que ele "esconde" as máquinas da rede mostrando para o resto
do mundo apenas a máquina gateway.
4 VULNERABILIDADES NO PROTOCOLO TCP/IP
Ultimamente temos presenciado um novo fenômeno no underground digital.
O fenômeno em si não é novo, mas tornou-se muito fácil acessar as ferramentas
necessárias para fazer más ações, temos experimentado muitas instâncias.O
fenômeno é conhecido por diferentes nomes (Smurph, Land, Bonk,etc). O intuito
de todos, contudo, é o mesmo: impedir computadores desabilitando seu uso como
pretendido.
Esse capítulo tenta explicar esses ataques.

4.1 Disponibilidade dos dados

Podemos dividir a segurança dos dados em três partes diferentes:
integridade, confidencialiade e disponibilidade. Se alguém, que não é autorizado,
gerencia e muda seus dados, a integridade é comprometida. Você não poderá
mais acreditar que o valor dessa informação é verdadeiro.
A confidencialidade da sua informação é comprometida se uma pessoa for
capaz de entrar no seu computador. Se puder conhecer uma informação a qual
não se pretendia que essa pessoa conhecesse. Ela poderá também distribuir a
informação.
A última categoria - disponibilidade - é onde os ataques aqui discutidos
pertencem. A disponibilidade dos dados é importante no decorrer dos negócios e
grandes perdas podem ocorrer se a informação importante não estiver disponível
devido a um ataque contra um computador. Tais ataques são frequentemente
chamados de "Denial-of-Service" (DoS).

4.2 Sobre o protocolo TCP/IP

Todos os ataques discutidos aqui se beneficiam de vulnerabilidades na
implementação do protocolo TCP/IP visando a interrupção da atividade do
computador atacado. Para entender os ataques é necessário um conhecimento
básico de como o protocolo foi projetado para funcionar.
TCP/IP é uma abreviação de Transmission Control Protocol/Internet
Protocol e é um dos vários protocolos desenvolvidos pelo Departamento de
Defesa dos Estados Unidos no final da década de 70. A razão pela qual o
protocolo foi desenhado era a necessidade de construir uma rede de
computadores capaz de se conectar com outra rede do mesmo tipo (roteamento).
Essa rede chamou-se ARPANET (Advanced Research Project Agency
Internetwork), e é a irmã mais nova da Internet.
Antes de ler sobre os ataques, recomendo que você leia a seção sobre
TCP/IP.
4.3 IP Spoofing
Um ataque spoofing envolve a falsificação do endereço de origem. É o ato
de usar uma máquina para representar o papel de outra. A maioria das aplicações
e ferramentas no UNIX baseam-se na autenticação do IP de origem. Muitos
programadores têm usado controle de acesso baseado na máquina para
segurança das suas redes. O endereço IP de origem é um identificador único mas
não é fiável. Ele pode facilmente ser forjado (spoofed). Para entender o processo
de spoofing, Primeiro vou explicar o o processo de autenticação do TCP e do IP
e depois como um atacante pode enganar a sua rede.
O sistema cliente começa por enviar uma mensagem SYN para o servidor.
O servidor então confirma a mensagem SYN enviando uma mensagem de SYN-
ACK para o cliente. O cliente então completa estabelecendo a conexão
respondendo com uma mensagem de ACK. A conexão entre o cliente e o servidor
é então aberta, e os dados específicos do serviço podem ser trocado entre o
cliente e o servidor. Cliente e servidor podem agora enviar dados específicos do
serviço.
O TCP usa números seqüenciais. Quando um circuito virtual é estabelecido
entre duas máquinas, o TCP designa para cada pacote um número com um índice
identificador. Amboa as máquinas usam este número para verificarem erros e
fazerem relatórios.
Rik Farrow, no seu artigo "Sequence Number Attacks", explica o sistema de
números seqüenciais como sendo o seguinte:
"Os números seqüenciais são usados para confirmar a
recepção de dados. No início de uma ligação TCP, o cliente envia
um pacote TCP com uma número seqüencial inicial, mas nenhum
reconhecimento. Se existir um servidor de aplicação a correr na
outra ponta da ligação, o servidor envia de volta um pacote TCP com
o seu próprio número seqüencial, e o reconhecimento; o número
inicial do pacote do cliente mais um. Quando o sistema cliente
recebe este pacote, ele deve enviar de volta o seu próprio
reconhecimento; a sequência de número inicial do servidor mais um."
Desta forma um atacante tem dois problemas:
1) Ele deve falsificar o endereço origem.
2) Ele deve manter um número seqüencial com o destino.
A segunda tarefa é a mais complicada porque quando o destino ajusta o
número seqüencial inicial, o agressor deve responder corretamente. Assim que o
agressor adivinhe o número seqüencial correcto, pode então sincronizar com o
destino e estabelecer uma sessão válida.

4.3.1 Serviços vulneráveis ao IP Spoofing:

Configurações e serviços que são vulneráveis ao IP spoofing :
 • RPC (Serviços de Invocação Remota de Funções)
• Qualquer serviço que use autenticação de endereço IP
• O sistema X Window
• O conjunto de serviços R (rlogin, rsh, etc.)

4.3.2 Medidas para se prevenir de ataques IP Spoofing:

• Evite usar autenticação de endereço de origem. Implemente criptografia na
autenticação em todo o sistema.
• Configure a sua rede para rejeitar pacotes de redes externas que declaram
ser de um endereço local. Isto é geralmente feito com um router.
• Se você permitir ligações externas de máquinas seguras, possibilite
encriptação da sessão no router.

4.4 Sobre os ataques

Os ataques descritos nesse documento são apenas alguns dos que estão
disponíveis na Internet. Seu denominador comum é que todos usam
vulnerabilidades ou implementações errôneas do protocolo TCP/IP ou ainda,
vulnerabilidades na especificação do TCP/IP em si.
Qualquer um mais interessado pode dar uma olhada no site
www.rootshell.com <http://www.rootshell.com/> que descreve vários
ataques. Esse site também tem links para download de programas que protegem
contra esses ataques.
Todos os ataques descritos abaixo funcionam em computadores com
Windows for Workgroups, Windows 95 ou Windows NT . Podem também
funcionar para outros sistemas operacionais. Uma vez mais indico
www.rootshell.com <http://www.rootshell.com/> para uma lista completa
de ataques que funcionam em diferentes sistemas operacionais.

4.4.1 SYN Flooding

Esta é a família dos ataques DoS (Denial-of-Service) que usa variações da
mesma técnica. O ataque é realizado enviando uma stream de pacotes para o
computador alvo requisitando uma conexão (a flag SYN é setada). A cada vez
que o computador alvo recebe tal requisição, recursos são alocados - mas
nenhuma conexão é efetivada. Quando muitas requisições são recebidas o
computador alvo não pode mais alocar recursos para o tráfego da rede - como
resultado o computador pode parar.
4.4.2 Land
Aqui o ataque acontece enviando-se um pacote com a flag SYN setada (i.e.
requisitando a abertura de uma conexão) para qualquer porta da máquina alvo. O
pacote é modificado de tal maneira que os endereços de envio e de recebimento
do pacote são idênticos (spoofing). Essa situação não é corretamente manipulada
por algumas implementações do TCP/IP - o computador pára. Esse ataque é
direcionado à porta 139 de máquinas rodando o sistema operacional Windows.

4.4.3 WinNuke
O nuke tem sido uma atividade popular, principalmente em escolas. Esse
tipo de ataque é voltado principalmente para computadores rodando Windows. O
efeito principal é o congelamento do computador, que precisa ser reiniciado.
A razão pela qual o computador trava é que a Microsoft não manipula um
flag especial de status no protocolo TCP - a flag URG(para urgente). Esse flag é
setado em um pacote enviado para um computador rodando um sistema
operacional Windows. O computador irá esperar por uma stream (cadeia de
dados) da chamada Out-of-Band (OOB) banda de tráfego do computador que
envia. Esse tipo de tráfego tem prioridade mais alta que o tráfego ordinário da
rede. O problema surge quando tais mensagens não são enviadas: o computador
para. Parece que se trata de resultado de uma má implementação do protocolo
TCP/IP da Microsoft, onde essa situação não é tratada satisfatoriamente.
Esse ataque é muito simples de ser realizado (utiliza um canal legítimo)-
tem sido até mesmo implementado com uma linha de código na linguagem Perl.
Normalmente, o ataque é direcionado contra a porta 139 (Serviço NetBIOS
Session) do computador.
Por exemplo: suponhamos que um computador com IP 200.133.10.126
esteja com a porta 139 aceitando conexões. Na barra de endereços do Browser,
podemos digitar: <http://200.133.10.126:139> e se ficarmos atualizando a
página, estaremos atacando essa máquina. Um simples JavaScript pode
automatizar essa tarefa.
Felizmente, é fácil proteger um computador contra esse tipo de ataque. A
Microsoft desenvolveu patches para download. Quando esse patches são
instalados, você está protegido contra esse tipo de ataque.

4.4.4 TearDrop
Esse ataque utiliza outra vulnerabilidade na implementação do protocolo
TCP/IP. O resultado desse ataque pode variar, mas, normalmente o computador
trava e precisa ser reiniciado. Os sistemas operacionais mais vulneráveis são
Windows(95/98/NT) e Linux.
A razão pela qual o ataque acontece deve-se a um erro em parte do
protocolo TCP/IP que toma conta de pacotes fragmentados. A fragmentação do
pacote pode ocorrer se o pacote que está sendo recebido for maior do que o
tamanho permitido pela rede. Caso positivo, o pacote é dividido em pacotes
menores, consistindo em partes do pacote original. Quando os pacotes menores
chegam ao computador recipiente, ele tenta colocá-los juntos -aqui ocorre o erro e
o computador pára.
Tecnicamente, o ataque é conduzido mandando uma combinação especial
de dois pacotes UDP/IP. O primeiro tem deslocamento 0, a flag MF (mais
fragmentos) setada para 1 e tamanho N. O segundo tem deslocamento menor
que N, flag MF resetada para 0 e tamanho menor que N. O segundo pacote
sobrepões-se ao primeiro. Uma implementação errônea do TCP/IP interpreta o
fim do pacote antes do seu começo e o computador pára.

4.4.5 NewTear
Esse ataque é parecido com o TearDrop. A diferença é o tamanho da
sobreposição dos pacotes (20 bytes, enquanto o TearDrop usa 28) e a
manipulação do tamanho do UDP. Esse ataque funciona contra máquinas
rodando Windows95/98 e NT mesmo que o patch TearDrop esteja instalado, o que
demonstra que a Microsoft não levou as variações do ataque em conta quando o
patch foi programado.

4.4.6 Bonk/Boink
Outra variação do ataque TearDrop. O deslocamento do fragmento do
segundo pacote é ajustado para ser maior do que o comprimento do cabeçalho IP.
Semelhante aos outros ataques, o computador pára. Não se sabe porquê esse
ataque funciona.
O Bonk ataca a porta 55 das máquinas. O Boink é uma variação do Bonk -
a diferença é que esse último permite ataques em outras portas, além da 55.

4.4.7 Ssping
Uma variação do ataque chamado "Ping da Morte". Uma pessoa manda
um pacote ICMP (ECHO_REQUEST) com um tamanho anormal para a máquina
alvo. O tamanho máximo para datagramas TCP/IP é 65536 octetos (1 octeto = 8
bits). Contudo, é possível mandar datagramas maiores do que o tamanho máximo
definido. Quando a máquina alvo recebe tal pacote pode parar. Mais uma vez, o
erro deve-se a má implementação na secção do TCP/IP que manipula pacotes
fragmentados. Um teste simples para testar se você é vulnerável é pingar seu
próprio computador. Use o comando ping -s 65510 seu_ip. Se sua
máquina parar você é vulnerável a esse tipo de ataque.
4.4.8 Smurf
Smurfing é outro tipo de ataque semelhante aos que foram discutidos aqui.
Esse tipo de ataque Smurf pode ser considerado mais perigoso que os outros.
O ataque Smurf não tem intenção de parar um computador, mas sim uma
rede inteira. É realizado enviando contínuas stream (cadeias) de pacote ICMP
modificados para a rede alvo.
Os pacotes são modificados de modo que o endereço da máquina que
envia os dados é idêntico ao endereço do alvo (spoofing). Além disso, os pacotes
são enviados para os chamados endereços broadcast, o que resulta em os
pacotes modificados serem enviados para todos os computadores de uma rede.
Os computadores dessa rede irão responder enviando uma mensagem de ICMP
ECHO_RESPONSE para o computador que eles assumem ter enviado a
mensagem ( o computador alvo da rede).Se o atacante tiver uma conexão
rápida,não é preciso ser um grande matemático para saber que a quantidade de
dados gerados pode parar a rede atacada. A rede irá parar até que o atacante
pare de enviar os pacotes ou o tráfego seja bloqueado.
Esse tipo de ataque tem sido usado para parar vários Provedores de
Acesso à Internet e todos os seus usuários. Efetivamente, é difícil se proteger
desse tipo de ataque.
5 FIREWALL IPCHAINS
Adaptado do Linux IPCHAINS-HOWTO, Paul Russell, <ipchains@rustcorp.com
<mailto:ipchains@rustcorp.com>>, v1.0.7, 12 March 1999
Tradução para o português por Gleydson Mazioli da Silva, <gleydson@linuxbr.com.br
<mailto:gleydson@linuxbr.com.br>>

5.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”.

5.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.

5.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 ICMP, 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).

5.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.

5.1.4 Onde?
A página oficial é The Linux IP Firewall Chains Page
<http://www.rustcorp.com/linux/ipchains>
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@rustcorp.com>>. Para
enviar E-Mails para a lista use “ipchains” ao invés de “ipchains-request”.

5.2 Básico sobre a filtragem de pacotes

5.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.
5.2.2 Por que?
• 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.

5.2.3 Como?

5.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.

5.2.3.2 O 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.
O ipchains substitui o 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.

5.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).

5.3 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 transparent 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.

5.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

5.3.2 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.

5.3.2.1 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.

5.3.2.2 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 slashdot.org.
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.

5.3.2.3 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.

5.3.2.4 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.

5.3.2.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.

5.3.3 Mais detalhes sobre Masquerading

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>
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>.

5.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.

5.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.

5.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™.
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 a política de um chain interno (-P).
 4. Listar as regras em um chain (-L).
5. Esvaziar as regras 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.

5.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 ICMP vindo do endereço IP
127.0.0.1. Assim neste caso nossas condições são que o protocolo deve
ser ICMP 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 ICMP 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 ICMP (“-p ICMP”)
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.
5.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.
5.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 <http://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”.
5.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.
5.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”.

5.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

5.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 pong
3 destination-unreachable Qualquer tráfego TCP/UDP.
5 redirect se não estiver executando
um daemon de roteamento
8 echo-request ping
11 time-exceeded traceroute
Note que os nomes ICMP não podem ser precedidos de “!” no momento.
Atenção: NÃO, bloqueie as mensagems ICMP do tipo 3! (Veja “Pacotes
ICMP” abaixo)
5.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. Logicamente, 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.
5.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.
5.4.1.3.6 Dirigindo Fragmentos
As vezes um pacote é muito grande para passar de uma só vez. Quando
isto acontece, 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

5.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.
5.4.1.4.1 Especificando um alvo
Um alvo diz ao kernel 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.
5.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) /etc/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”.
5.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 possa 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).
5.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.
5.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.
5.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.
5.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.
5.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.

5.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.
5.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

5.4.1.4.11 Configurando a Política

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.

5.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!”.

5.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

5.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 <http://www.foo.com>” resolve três
endereços IPs, e o hostname “www.bar.com <http://www.bar.com>” resolve dois
endereços IPs, então o comando “ipchains -A input -j reject -s www.bar.com
<http://www.bar.com> -d www.foo.com <http://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

5.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://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 não existe 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.

5.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’.

5.4.2.2 Usando ipchains-restore

O 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.5 Diversos
Esta seção contém todas as informações e FAQs que eu pude colocar
dentro da estrutura do arquivo abaixo.

5.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.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.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.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 mais ou menos”
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.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.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.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.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.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.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.6 Problemas comuns

5.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.

5.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.

5.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.

5.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.
5.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.

5.6.6 ipautofw e ipportfw não funcionam!

Para o kernel 2.0.x, isto é verdade: eu não tenho tempo para criar e manter
um patch gigantesco para ipchains e ipautofw/ipportfw.
Para o kernel 2.1.x, copie Juan Ciarlante’s ipmasqadm de
<http://juanjox.linuxhq.com/> 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.

5.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).

5.6.8 Falta de Segmentação com “-j REDIRECT”!

Este foi um bug no ipchains versão 1.3.3. Por favor atualize.

5.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.

5.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.
6 FIREWALL IPTABLES
Adaptado do -Guia Foca GNU/Linux Avançado Capítulo 9
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>.

Este capítulo documenta o funcionamento do firewall iptables que

acompanha a série do kernel 2.4, opções usadas, e aponta alguns pontos
fundamentais para iniciar a configuração e construção de bons sistemas de
firewall.

6.1 Introdução
O Firewall é um programa que como objetivo proteger a máquina contra
acessos indesejados, tráfego indesejado, proteger serviços que estejam rodando
na máquina e bloquear a passagem de coisas que você não deseja receber (como
conexões vindas da Internet para sua segura rede local, evitando acesso aos
dados corporativos de uma empresa ou a seus dados pessoais). No kernel do
Linux 2.4, foi introduzido o firewall iptables (também chamado de netfilter) que
substitui o ipchains dos kernels da série 2.2. Este novo firewall tem como
vantagem ser muito estável (assim como o ipchains e ipfwadm), confiável, permitir
muita flexibilidade na programação de regras pelo administrador do sistema, mais
opções disponíveis ao administrador para controle de tráfego, controle
independente do tráfego da rede local/entre redes/interfaces devido a nova
organização das etapas de roteamento de pacotes.
O iptables é um firewall a nível de pacotes e funciona baseado no
endereço/porta de origem/destino do pacote, prioridade, etc. Ele funciona através
da comparação de regras para saber se um pacote tem ou não permissão para
passar. Em firewalls mais restritivos, o pacote é bloqueado e registrado para que
o administrador do sistema tenha conhecimento sobre o que está acontecendo em
seu sistema.
Ele também pode ser usado para modificar e monitorar o tráfego da rede,
fazer NAT (masquerading, source nat, destination nat), redirecionamento de
pacotes, marcação de pacotes, modificar a prioridade de pacotes que
chegam/saem do seu sistema, contagem de bytes, dividir tráfego entre máquinas,
criar proteções anti-spoofing, contra syn flood, DoS, etc. O tráfego vindo de
máquinas desconhecidas da rede pode também ser bloqueado/registrado através
do uso de simples regras. As possibilidades oferecidas pelos recursos de
filtragem iptables como todas as ferramentas UNIX maduras dependem de sua
imaginação, pois ele garante uma grande flexibilidade na manipulação das regras
de acesso ao sistema, precisando apenas conhecer quais interfaces o sistema
possui, o que deseja bloquear, o que tem acesso garantido, quais serviços devem
estar acessíveis para cada rede, e iniciar a construção de seu firewall.
O iptables ainda tem a vantagem de ser modularizável, funções podem ser
adicionadas ao firewall ampliando as possibilidades oferecidas. Usei por 2 anos o
ipchains e afirmo que este é um firewall que tem possibilidades de gerenciar tanto
a segurança em máquinas isoladas como roteamento em grandes organizações,
onde a passagem de tráfego entre redes deve ser minuciosamente controlada.
Um firewall não funciona de forma automática (instalando e esperar que ele
faça as coisas por você), é necessário pelo menos conhecimentos básicos de rede
tcp/ip, roteamento e portas para criar as regras que farão a segurança de seu
sistema. A segurança do sistema depende do controle das regras que serão
criadas por você, as falhas humanas são garantia de mais de 95% de sucesso nas
invasões.
Enfim o iptables é um firewall que agradará tanto a pessoas que desejam
uma segurança básica em seu sistema, quando administradores de grandes redes
que querem ter um controle minucioso sobre o tráfego que passam entre suas
interfaces de rede (controlando tudo o que pode passar de uma rede a outra),
controlar o uso de tráfego, monitoração, etc.

6.1.1 Versão
É assumido que esteja usando a versão 1.2.3 do iptables e baseadas nas
opções do kernel 2.4.16 (sem o uso de módulos experimentais). As explicações
contidas aqui podem funcionar para versões posteriores, mas é recomendável que
leia a documentação sobre modificações no programa (changelog) em busca de
mudanças que alterem o sentido das explicações fornecidas aqui.

6.1.2 Um resumo da história do iptables

O iptables é um código de firewall das versões 2.4 do kernel, que substituiu
o ipchains (presente nas séries 2.2 do kernel). Ele foi incluído no kernel da série
2.4 em meados de Junho/Julho de 1999.
A história do desenvolvimento (desde o porte do ipfw do BSD para o Linux
até o iptables (que é a quarta geração de firewalls do kernel) está disponível no
documento, Netfilter-howto.

6.1.3 Características do firewall iptables

• Especificação de portas/endereço de origem/destino
• Suporte a protocolos TCP/UDP/ICMP (incluindo tipos de mensagens icmp)
• Suporte a interfaces de origem/destino de pacotes
• Manipula serviços de proxy na rede
• Tratamento de tráfego dividido em chains (para melhor controle do tráfego
que entra/sai da máquina e tráfego redirecionado.
• Permite um número ilimitado de regras por chain
• Muito rápido, estável e seguro
 • Possui mecanismos internos para rejeitar automaticamente pacotes
duvidosos ou mal formados.
• Suporte a módulos externos para expansão das funcionalidades padrões
oferecidas pelo código de firewall
• Suporte completo a roteamento de pacotes, tratadas em uma área diferente
de tráfegos padrões.
• Suporte a especificação de tipo de serviço para priorizar o tráfego de
determinados tipos de pacotes.
• Permite especificar exceções para as regras ou parte das regras
• Suporte a detecção de fragmentos
• Permite enviar alertas personalizados ao syslog sobre o tráfego
aceito/bloqueado.
• Redirecionamento de portas
• Masquerading
• Suporte a SNAT (modificação do endereço de origem das máquinas para
um único IP ou faixa de IP's).
• Suporte a DNAT (modificação do endereço de destino das máquinas para
um único IP ou fixa de IP's)
• Contagem de pacotes que atravessaram uma interface/regra
• Limitação de passagem de pacotes/conferência de regra (muito útil para
criar proteções contra, syn flood, ping flood, DoS, etc).

6.1.4 Ficha técnica

Pacote: iptables
• iptables - Sistema de controle principal para protocolos ipv4
• ip6tables - Sistema de controle principal para protocolos ipv6
• iptables-save - Salva as regras atuais em um arquivo especificado como
argumento. Este utilitário pode ser dispensado por um shell script contendo
as regras executado na inicialização da máquina.
• iptables-restore - Restaura regras salvas pelo utilitário iptables-save.

6.1.5 Requerimentos
É necessário que o seu kernel tenha sido compilado com suporte ao
iptables (veja Habilitando o suporte ao iptables no kernel, Section 9.1.15
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>. O requerimento
mínimo de memória necessária para a execução do iptables é o mesmo do kernel
2.4 (4MB). Dependendo do tráfego que será manipulado pela(s) interface(s) do
firewall ele poderá ser executado com folga em uma máquina 386 SX com 4MB de
RAM.
Como as configurações residem no kernel não é necessário espaço extra
em disco rígido para a execução deste utilitário.

6.1.6 Arquivos de logs criados pelo iptables

Todo tráfego que for registrado pelo iptables é registrado por padrão no
arquivo /var/log/kern.log.

6.1.7 Instalação

apt-get install iptables

O pacote iptables contém o utilitário iptables (e ip6tables para redes ipv6)

necessários para inserir suas regras no kernel. Se você não sabe o que é ipv6,
não precisará se preocupar com o utilitário ip6tables por enquanto.

6.1.8 Enviando Correções/Contribuindo com o projeto

A página principal do projeto é <http://netfilter.filewatcher.org>. Sugestões
podem ser enviadas para a lista de desenvolvimento oficial do iptables:
<http://lists.samba.org>.

6.1.9 O que aconteceu com o ipchains e ipfwadm?

O iptables faz parte da nova geração de firewalls que acompanha o kernel
2.4, mas o suporte ao ipchains e ipfwadm ainda será mantido no kernel até 2004.
Seria uma grande falta de consideração retirar o suporte a estes firewalls do
kernel como forma de obrigar a "aprenderem" o iptables (mesmo o suporte sendo
removido após este período, acredito que criarão patches "externos" para futuros
kernels que não trarão mais este suporte). Se precisa do suporte a estes firewalls
antes de passar em definitivo para o iptables leia Habilitando o suporte ao iptables
no kernel, Section 9.1.15 <http://focalinux.cipsga.org.br/guia/avancado/ch-fw-
iptables.htm>.
Se você é um administrador que gosta de explorar todos os recursos de um
firewall, usa todos os recursos que ele oferece ou mantém uma complexa rede
corporativa, tenho certeza que gostará do iptables.
6.1.10 Tipos de firewalls
Existem basicamente dois tipos de firewalls:
• nível de aplicação - Este tipo de firewall analisam o conteúdo do pacote
para tomar suas decisões de filtragem. Firewalls deste tipo são mais
intrusivos (pois analisam o conteúdo de tudo que passa por ele) e permitem
um controle relacionado com o conteúdo do tráfego. Alguns firewalls a
nível de aplicação combinam recursos básicos existentes em firewalls a
nível de pacotes combinando as funcionalidade de controle de
tráfego/controle de acesso em uma só ferramenta. Servidores proxy, como
o squid, são um exemplo deste tipo de firewall.
• nível de pacotes - Este tipo de firewall toma as decisões baseadas nos
parâmetros do pacote, como porta/endereço de origem/destino, estado da
conexão, e outros parâmetros do pacote. O firewall então pode negar o
pacote (DROP) ou deixar o pacote passar (ACCEPT). O iptables é um
excelente firewall que se encaixa nesta categoria.
Firewall a nível de pacotes é o assunto explicado nesta seção do guia.
Os dois tipos de firewalls podem ser usados em conjunto para fornecer uma
camada dupla de segurança no acesso as suas máquinas/máquinas clientes.

6.1.11 O que proteger?

Antes de iniciar a construção do firewall é bom pensar nos seguintes
pontos:
• Quais serviços precisa proteger. Serviços que devem ter acesso garantido
a usuários externos e quais serão bloqueados a todas/determinadas
máquinas. É recomendável bloquear o acesso a todas portas menores que
1024 por executarem serviços que rodam com privilégio de usuário root, e
autorizar somente o acesso as portas que realmente deseja (configuração
restritiva nesta faixa de portas).
• Que tipo de conexões eu posso deixar passar e quais bloquear. Serviços
com autenticação em texto plano e potencialmente inseguros como rlogin,
telnet, ftp, NFS, DNS, LDAP, SMTP RCP, X-Window são serviços que
devem ser ter acesso garantido somente para máquinas/redes que você
confia. Estes serviços podem não ser só usados para tentativa de acesso
ao seu sistema, mas também como forma de atacar outras pessoas
aproveitando-se de problemas de configuração.
A configuração do firewall ajuda a prevenir isso, mesmo se um serviço
estiver mal configurado e tentando enviar seus pacotes para fora, será
impedido. Da mesma forma se uma máquina Windows de sua rede for
infectada por um trojan não haverá pânico: o firewall poderá estar
configurado para bloquear qualquer tentativa de conexão vinda da internet
(cracker) para as máquinas de sua rede.
 Para cópia de arquivos via rede insegura (como através da Internet),
é recomendado o uso de serviços que utilizam criptografia para login e
cópia de arquivos (veja Servidor ssh, Chapter 14
<http://focalinux.cipsga.org.br/guia/avancado/ch-s-ssh.htm>).
• Que máquinas terão acesso livre e quais serão restritas.
• Que serviços deverão ter prioridade no processamento.
• Que máquinas/redes NUNCA deverão ter acesso a certas/todas máquinas.
• O volume de tráfego que o servidor manipulará. Através disso você pode
ter que balancear o tráfego entre outras máquinas, configurar proteções
contra DoS, syn flood, etc.
• O que tem permissão de passar de uma rede para outra (em máquinas que
atuam como roteadores/gateways de uma rede interna).
• Etc.
A análise destes pontos pode determinar a complexidade do firewall, custos
de implementação, prazo de desenvolvimento e tempo de maturidade do código
para implementação. Existem muitos outros pontos que podem entrar na questão
de desenvolvimento de um sistema de firewall, eles dependem do tipo de firewall
que está desenvolvendo e das políticas de segurança de sua rede.

6.1.12 O que são regras?

As regras são como comandos passados ao iptables para que ele realize
uma determinada ação (como bloquear ou deixar passar um pacote) de acordo
com o endereço/porta de origem/destino, interface de origem/destino, etc. As
regras são armazenadas dentro dos chains e processadas na ordem que são
inseridas.
As regras são armazenadas no kernel, o que significa que quando o
computador for reiniciado tudo o que fez será perdido. Por este motivo elas
deverão ser gravadas em um arquivo para serem carregadas a cada inicialização.
Um exemplo de regra: iptables -A INPUT -s 123.123.123.1 -j
DROP.

6.1.13 O que são chains?

Os Chains são locais onde as regras do firewall definidas pelo usuário são
armazenadas para operação do firewall. Existem dois tipos de chains: os
embutidos (como os chains INPUT, OUTPUT e FORWARD) e os criados pelo
usuário. Os nomes dos chains embutidos devem ser especificados sempre em
maiúsculas (note que os nomes dos chains são case-sensitive, ou seja, o chain
input é completamente diferente de INPUT).
6.1.14 O que são tabelas?
Tabelas são os locais usados para armazenar os chains e conjunto de
regras de um mesmo conjunto que cada um possui. As tabelas podem ser
referenciadas com a opção -t tabela e existem 3 tabelas disponíveis no iptables:
• filter - Esta é a tabela padrão, contém 3 chains padrões:

o INPUT - Consultado para dados que chegam a máquina

o OUTPUT - Consultado para dados que saem da máquina

o FORWARD - Consultado para dados que são redirecionados para

outra interface de rede ou outra máquina.
Os chains INPUT e OUTPUT somente são atravessados por conexões
indo/se originando de localhost. OBS: Para conexões locais, somente os
chains INPUT e OUTPUT são consultados na tabela filter.
• nat - Usada para dados que gera outra conexão (masquerading, source nat,
destination nat, port forwarding, proxy transparente são alguns exemplos).
Possui 3 chains padrões:
o PREROUTING - Consultado quando os pacotes precisam ser
modificados logo que chegam. É o chain ideal para realização de
DNAT e redirecionamento de portas (Fazendo DNAT, Section 9.4.4
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>).
o OUTPUT - Consultado quando os pacotes gerados localmente
precisam ser modificados antes de serem roteados. Este chain
somente é consultado para conexões que se originam de IPs de
interfaces locais.

o POSTROUTING - Consultado quando os pacotes precisam ser

modificados após o tratamento de roteamento. É o chain ideal para
realização de SNAT e IP Masquerading (Fazendo SNAT, Section
9.4.3 <http://focalinux.cipsga.org.br/guia/avancado/ch-fw-
iptables.htm>).
• mangle - Utilizada para alterações especiais de pacotes (como modificar o
tipo de serviço (TOS) ou outros detalhes que serão explicados no decorrer
do capítulo. Possui 2 chains padrões:

o PREROUTING - Consultado quando os pacotes precisam ser

modificados logo que chegam.

o OUTPUT - Consultado quando pacotes gerados localmente precisam

ser modificados antes de serem roteados.
Veja A tabela mangle, Section 9.5
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm> para mais
detalhes sobre a tabela mangle.
6.1.15 Habilitando o suporte ao iptables no kernel
Para usar toda a funcionalidade do firewall iptables, permitindo fazer o
controle do que tem ou não permissão de acessar sua máquina, fazer
Masquerading/NAT em sua rede, etc., você precisará dos seguintes componentes
compilados em seu kernel (os módulos experimentais fora ignorados
intencionalmente):

*
* Network Options:
*

Network packet filtering (replaces ipchains) [Y/m/n/?]

Network packet filtering debugging [Y/m/n/?]

e na Subseção:

*
* IP: Netfilter Configuration
*
Connection tracking (required for masq/NAT) (CONFIG_IP_NF_CONNTRACK) [M/n/y/?]
FTP protocol support (CONFIG_IP_NF_FTP) [M/n/?]
IRC protocol support (CONFIG_IP_NF_IRC) [M/n/?]
IP tables support (required for filtering/masq/NAT) (CONFIG_IP_NF_IPTABLES)
[Y/m/n/?]
limit match support (CONFIG_IP_NF_MATCH_LIMIT) [Y/m/n/?]
MAC address match support (CONFIG_IP_NF_MATCH_MAC) [M/n/y/?]
netfilter MARK match support (CONFIG_IP_NF_MATCH_MARK) [M/n/y/?]
Multiple port match support (CONFIG_IP_NF_MATCH_MULTIPORT) [M/n/y/?]
TOS match support (CONFIG_IP_NF_MATCH_TOS) [M/n/y/?]
LENGTH match support (CONFIG_IP_NF_MATCH_LENGTH) [M/n/y/?]
TTL match support (CONFIG_IP_NF_TTL) [M/n/y/?]
tcpmss match support (CONFIG_IP_NF_MATCH_TCPMSS) [M/n/y/?]
Connection state match support (CONFIG_IP_NF_MATCH_STATE) [M/n/?]
Packet filtering (CONFIG_IP_NF_FILTER) [M/n/y/?]
REJECT target support (CONFIG_IP_NF_TARGET_REJECT) [M/n/?]
Full NAT (CONFIG_IP_NF_NAT) [M/n/?]
MASQUERADE target support (CONFIG_IP_NF_TARGET_MASQUERADE) [M/n/?]
REDIRECT target support (CONFIG_IP_NF_TARGET_REDIRECT) [M/n/?]
Packet mangling (CONFIG_IP_NF_MANGLE) [M/n/y/?]
TOS target support (CONFIG_IP_NF_TARGET_TOS) [M/n/?]
MARK target support (CONFIG_IP_NF_TARGET_MARK) [M/n/?]
LOG target support (CONFIG_IP_NF_TARGET_LOG) [M/n/y/?]
TCPMSS target support (CONFIG_IP_NF_TARGET_TCPMSS) [M/n/y/?]

Esta configuração permite que você não tenha problemas para iniciar o uso
e configuração do seu firewall iptables, ela ativa os módulos necessários para
utilização de todos os recursos do firewall iptables. Quando conhecer a função de
cada um dos parâmetros acima (durante o decorrer do texto), você poderá
eliminar muitas das opções desnecessárias para seu estilo de firewall ou continuar
fazendo uso de todas ;-)
OBS1: A configuração acima leva em consideração que você NÃO
executará os códigos antigos de firewall ipfwadm e ipchains. Caso deseje utilizar
o ipchains ou o ipfwadm, será preciso responder com "M" a questão "IP tables
support (required for filtering/masq/NAT) (CONFIG_IP_NF_IPTABLES)". Será
necessário carregar manualmente o módulo correspondente ao firewall que deseja
utilizar (modprobe iptables_filter.o no caso do iptables).
Não execute mais de um tipo de firewall ao mesmo tempo!!!
OBS2: É recomendável ativar o daemon kmod para carga automática de
módulos, caso contrário será necessário compilar todas as partes necessárias
embutidas no kernel, carregar os módulos necessários manualmente ou pelo
iptables (através da opção --modprobe=módulo).

6.1.16 Ligando sua rede interna a Internet

Se a sua intenção (como da maioria dos usuários) é conectar sua rede
interna a Internet de forma rápida e simples, leia Fazendo IP masquerading (para
os apressados), Section 9.4.2 <http://focalinux.cipsga.org.br/guia/avancado/ch-fw-
iptables.htm> ou Fazendo SNAT, Section 9.4.3
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>. Um exemplo
prático de configuração de Masquerading deste tipo é encontrado em Conectando
sua rede interna a Internet, Section 9.8.3
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>.
Após configurar o masquerading, você só precisará especificar o endereço
IP da máquina masquerading (servidor) como Gateway da rede. No Windows
9x/NT/2000 isto é feito no Painel de Controle/Rede/Propriedades de Tcp/IP. No
Linux pode ser feito com route add default gw IP_do_Servidor.

6.2 Manipulando chains

As opções passadas ao iptables usadas para manipular os chains são
SEMPRE em maiúsculas. As seguintes operações podem ser realizadas com os
chains:

6.2.1 Adicionando regras - A

Como exemplo vamos criar uma regra que bloqueia o acesso a nosso
própria máquina (127.0.0.1 - loopback). Primeiro daremos um ping para verificar
seu funcionamento:

#ping 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=255 time=0.6 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.5 ms

--- 127.0.0.1 ping statistics ---

2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.6 ms

Ok, a máquina responde, agora vamos incluir uma regra no chain INPUT (-
A INPUT) que bloqueie (-j DROP) qualquer acesso indo ao endereço 127.0.0.1 (-d
127.0.0.1):

iptables -t filter -A INPUT -d 127.0.0.1 -j DROP

Agora verificamos um novo ping:
#ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes

--- 127.0.0.1 ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss

Desta vez a máquina 127.0.0.1 não respondeu, pois todos os pacotes com
o destino 127.0.0.1 (-d 127.0.0.1) são rejeitados (-j DROP). A opção -A é usada
para adicionar novas regras no final do chain. Além de -j DROP que serve para
rejeitar os pacotes, podemos também usar -j ACCEPT para aceitar pacotes. A
opção -j é chamada de alvo da regra ou somente alvo pois define o destino do
pacote que atravessa a regra (veja Especificando um alvo, Section 9.3.6
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>). Bem vindo a
base de um sistema de firewall :-)
OBS1: - O acesso a interface loopback não deve ser de forma alguma
bloqueado, pois muitos aplicativos utilizam soquetes tcp para realizarem
conexões, mesmo que você não possua uma rede interna.
OBS2: - A tabela filter será usada como padrão caso nenhuma tabela seja
especificada através da opção -t.

6.2.2 Listando regras - L

A seguinte sintaxe é usada para listar as regras criadas:
iptables [-t tabela] -L [chain] [opções]
Onde:
tabela
É uma das tabelas usadas pelo iptables. Se a tabela não for
especificada, a tabela filter será usada como padrão. Veja O que são
tabelas?, Section 9.1.14 <http://focalinux.cipsga.org.br/guia/avancado/ch-
fw-iptables.htm> para detalhes.
chain
 Um dos chains disponíveis na tabela acima (veja O que são
tabelas?, Section 9.1.14 <http://focalinux.cipsga.org.br/guia/avancado/ch-
fw-iptables.htm>) ou criado pelo usuário (Criando um novo chain - N,
Section 9.2.6 <http://focalinux.cipsga.org.br/guia/avancado/ch-fw-
iptables.htm>). Caso o chain não seja especificado, todos os chains da
tabela serão mostrados.
opções
As seguintes opções podem ser usadas para listar o conteúdo de
chains:
• -v - Exibe mais detalhes sobre as regras criadas nos chains.
• -n - Exibe endereços de máquinas/portas como números ao invés de
tentar a resolução DNS e consulta ao /etc/services. A resolução de
nomes pode tomar muito tempo dependendo da quantidade de
regras que suas tabelas possuem e velocidade de sua conexão.
• -x - Exibe números exatos ao invés de números redondos. Também
mostra a faixa de portas de uma regra de firewall.
• --line-numbers - Exibe o número da posição da regra na primeira
coluna da listagem.
Para listar a regra criada anteriormente usamos o comando:

#iptables -t filter -L INPUT

Chain INPUT (policy ACCEPT)

target prot opt source destination
DROP all -- anywhere localhost

O comando iptables -L INPUT -n tem o mesmo efeito, a diferença é que são

mostrados números ao invés de nomes:

#iptables -L INPUT -n

Chain INPUT (policy ACCEPT)

target prot opt source destination
DROP all -- 0.0.0.0/0 127.0.0.1

#iptables -L INPUT -n --line-numbers

Chain INPUT (policy ACCEPT)

num target prot opt source destination
1 DROP all -- 0.0.0.0/0 127.0.0.1
#iptables -L INPUT -n -v
Chain INPUT (policy ACCEPT 78 packets, 5820 bytes)
pkts bytes target prot opt in out source destination
2 194 DROP icmp -- * * 0.0.0.0/0 127.0.0.1

Os campos assim possuem o seguinte significado:

Chain INPUT
Nome do chain listado
(policy ACCEPT 78 packets, 5820 bytes)
Policiamento padrão do chain (veja Especificando o policiamento
padrão de um chain - P, Section 9.2.11
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>).
pkts
Quantidade de pacotes que atravessaram a regra (veja Zerando
contador de bytes dos chains - Z, Section 9.2.10
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>).
bytes
Quantidade de bytes que atravessaram a regra. Pode ser
referenciado com K (Kilobytes), M (Megabytes), G (Gigabytes).
target
O alvo da regra, o destino do pacote. Pode ser ACCEPT, DROP ou
outro chain. Veja Especificando um alvo, Section 9.3.6
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm> para
detalhes sobre a especificação de um alvo.
prot
Protocolo especificado pela regra. Pode ser udp, tcp, icmp ou all.
Veja Especificando um protocolo, Section 9.3.3
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm> para
detalhes.
opt
Opções extras passadas a regra. Normalmente "!" (veja
Especificando uma exceção, Section 9.3.5
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>) ou "f"
(veja Especificando fragmentos, Section 9.3.4
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>).
in
Interface de entrada (de onde os dados chegam). Veja
Especificando a interface de origem/destino, Section 9.3.2
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>.
 out
Interface de saída (para onde os dados vão). Veja Especificando a
interface de origem/destino, Section 9.3.2
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>.
source
Endereço de origem. Veja Especificando um endereço de
origem/destino, Section 9.3.1
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>.
destination
Endereço de destino. Veja Especificando um endereço de
origem/destino, Section 9.3.1
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>.
outras opções
Estas opções normalmente aparecem quando são usadas a opção -
x:
• dpt ou dpts - Especifica a porta ou faixa de portas de destino.
• reject-with icmp-port-unreachable - Significa que foi usado o alvo
REJECT naquela regra (veja Alvo REJECT, Section 9.3.6.1
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>).

6.2.3 Apagando uma regra - D

Para apagar um chain, existem duas alternativas:
1. Quando sabemos qual é o número da regra no chain (listado com a opção -
L) podemos referenciar o número diretamente. Por exemplo, para apagar a
regra criada acima:
iptables -t filter -D INPUT 1
Esta opção não é boa quando temos um firewall complexo com um
grande número de regras por chains, neste caso a segunda opção é a mais
apropriada.
2. Usamos a mesma sintaxe para criar a regra no chain, mas trocamos -A por
-D:
iptables -t filter -D INPUT -d 127.0.0.1 -j DROP
Então a regra correspondentes no chain INPUT será
automaticamente apagada (confira listando o chain com a opção "-L").
Caso o chain possua várias regras semelhantes, somente a primeira será
apagada.
6.2.4 Inserindo uma regra - I
Precisamos que o tráfego vindo de 192.168.1.15 não seja rejeitado pelo
nosso firewall. Não podemos adicionar uma nova regra (-A) pois esta seria
incluída no final do chain e o tráfego seria rejeitado pela primeira regra (nunca
atingindo a segunda). A solução é inserir a nova regra antes da regra que
bloqueia todo o tráfego ao endereço 127.0.0.1 na posição 1:
iptables -t filter -I INPUT 1 -s 192.168.1.15 -d 127.0.0.1 -j ACCEPT
Após este comando, temos a regra inserida na primeira posição do chain
(repare no número 1 após INPUT) e a antiga regra número 1 passa a ser a
número 2. Desta forma a regra acima será consultada, se a máquina de origem
for 192.168.1.15 então o tráfego estará garantido, caso contrário o tráfego com o
destino 127.0.0.1 será bloqueado na regra seguinte.

6.2.5 Substituindo uma regra - R

Após criar nossa regra, percebemos que a nossa intenção era somente
bloquear os pings com o destino 127.0.0.1 (pacotes ICMP) e não havia
necessidade de bloquear todo o tráfego da máquina. Existem duas alternativas:
apagar a regra e inserir uma nova no lugar ou modificar diretamente a regra já
criada sem afetar outras regras existentes e mantendo a sua ordem no chain (isso
é muito importante). Use o seguinte comando:
iptables -R INPUT 2 -d 127.0.0.1 -p icmp -j DROP
O número 2 é o número da regra que será substituída no chain INPUT, e
deve ser especificado. O comando acima substituirá a regra 2 do chain INPUT (-R
INPUT 2) bloqueando (-j DROP) qualquer pacote icmp (-p icmp) com o destino
127.0.0.1 (-d 127.0.0.1).

6.2.6 Criando um novo chain - N

Em firewalls organizados com um grande número de regras, é interessante
criar chains individuais para organizar regras de um mesmo tipo ou que tenha por
objetivo analisar um tráfego de uma mesma categoria (interface, endereço de
origem, destino, protocolo, etc) pois podem consumir muitas linhas e tornar o
gerenciamento do firewall confuso (e conseqüentemente causar sérios riscos de
segurança). O tamanho máximo de um nome de chain é de 31 caracteres e
podem conter tanto letras maiúsculas quanto minúsculas.

iptables [-t tabela] [-N novochain]

Para criar o chain internet (que pode ser usado para agrupar as regras de
internet) usamos o seguinte comando:

iptables -t filter -N internet

Para inserir regras no chain internet basta especifica-lo após a opção -A:
 iptables -t filter -A internet -s 200.200.200.200 -j DROP

E então criamos um pulo (-j) do chain INPUT para o chain internet:

iptables -t filter -A INPUT -j internet
OBS: O chain criando pelo usuário pode ter seu nome tanto em maiúsculas
como minúsculas.
Se uma máquina do endereço 200.200.200.200 tentar acessar sua
máquina, o iptables consultará as seguintes regras:
`INPUT' `internet'
---------------------------- -----------------------------
| Regra1: -s 192.168.1.15 | | Regra1: -s 200.200.200.200|
|--------------------------| |---------------------------|
| Regra2: -s 192.168.1.1 | | Regra2: -d 192.168.1.1 |
|--------------------------| -----------------------------
| Regra3: -j DROP |
----------------------------
O pacote tem o endereço de origem
200.200.200.200, ele passa pela
primeira e segunda regras do chain
INPUT, a terceira regra direciona
para o chain internet _______________________________________
v / v
/-------------------------|-\ / /-------------------------------------|-\
| Regra1: -s 192.168.1.15 | | / | Regra1: -s 200.200.200.200 -j DROP \_____\
|-------------------------|-| / |---------------------------------------| /
| Regra2: -s 192.168.1.1 | | / | Regra2: -d 200.200.200.202 -j DROP |
|-------------------------|-|/ \---------------------------------------/
| Regra3: -j internet /|
|---------------------------| No chain internet, a primeira regra confere
| Regra4: -j DROP | com o endereço de origem 200.200.200.200 e
\---------------------------/ o pacote é bloqueado.

Se uma máquina com o endereço de origem 200.200.200.201 tentar

acessar a máquina, então as regra consultadas serão as seguintes:
O pacote tem o endereço de origem
200.200.200.201, ele passa pela
primeira e segunda regras do chain
INPUT, a terceira regra direciona
para o chain internet ______________________________________
v / v
/-------------------------|-\ / /-------------------------------------|-\
| Regra1: -s 192.168.1.15 | | / | Regra1: -s 200.200.200.200 -j DROP | |
|-------------------------|-| / |-------------------------------------|-|
| Regra2: -s 192.168.1.1 | | / | Regra2: -s 200.200.200.202 -j DROP | |
|-------------------------|-|/ \-------------------------------------|-/
| Regra3: -j internet /| v
|---------------------------| /
 | Regra4: -j DROP --+-------------------------------------------
\------------------------/-/ O pacote passa pelas regras 1 e 2 do chain
| internet, como ele não confere com nenhuma
v das 2 regras ele retorna ao chain INPUT e é
Esta regra é a número 4 analisado pela regra seguinte.
que diz para rejeitar o
pacote.

6.2.7 Listando os nomes de todos os chains atuais

Use o comando cat /proc/net/ip_tables_names para fazer isto. É
interessante dar uma olhada nos arquivos dentro do diretório /proc/net, pois
podem lhe ser interessantes.

6.2.8 Limpando as regras de um chain - F

Para limpar todas as regras de um chain, use a seguinte sintaxe:
iptables [-t tabela] [-F chain]
Onde:
tabela
Tabela que contém o chain que desejamos zerar.
chain
Chain que desejamos limpar. Caso um chain não seja especificado,
todos os chains da tabela serão limpos.
iptables -t filter -F INPUT
iptables -t filter -F

6.2.9 Apagando um chain criado pelo usuário - X

Para apagarmos um chain criado pelo usuário, usamos a seguinte sintaxe:
iptables [-t tabela] [-X chain]
Onde:
tabela
Nome da tabela que contém o chain que desejamos excluir.
chain
Nome do chain que desejamos apagar. Caso não seja especificado,
todos os chains definidos pelo usuário na tabela especificada serão
excluídos.
OBS: - Chains embutidos nas tabelas não podem ser apagados pelo
usuário. Veja os nomes destes chains em “6.1.14 O que são tabelas?”.

iptables -t filter -X internet

iptables -X
6.2.10 Zerando contador de bytes dos chains - Z
Este comando zera o campo pkts e bytes de uma regra do iptables. Estes
campos podem ser visualizados com o comando iptables -L -v. A seguinte sintaxe
é usada:
iptables [-t tabela] [-Z chain] [-L
Onde:
tabela
Nome da tabela que contém o chain que queremos zerar os
contadores de bytes e pacotes.
chain
Chain que deve ter os contadores zerados. Caso não seja
especificado, todos os chains da tabela terão os contadores zerados. Note
que as opções -Z e -L podem ser usadas juntas, assim o chain será listado
e imediatamente zerado. Isto evita a passagem de pacotes durante a
listagem de um chain.

iptables -t filter -Z INPUT

6.2.11 Especificando o policiamento padrão de um chain - P

O policiamento padrão determina o que acontecerá com um pacote quando
ele chegar ao final das regras contidas em um chain. O policiamento padrão do
iptables é "ACCEPT" mas isto pode ser alterado com o comando:
iptables [-t tabela] [-P chain] [ACCEPT/DROP]
Onde:
tabela
Tabela que contém o chain que desejamos modificar o policiamento
padrão.
chain
Define o chain que terá o policiamento modificado. O chain deve ser
especificado.
ACCEPT/DROP
ACCEPT aceita os pacotes caso nenhuma regra do chain conferir
(usado em regras permissivas). DROP rejeita os pacotes caso nenhuma
regra do chain conferir (usado em regras restritivas).
O policiamento padrão de um chain é mostrado com o comando iptables -L:

# iptables -L INPUT
 Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- anywhere localhost

No exemplo acima, o policiamento padrão de INPUT é ACCEPT (policy

ACCEPT), o que significa que qualquer pacote que não seja rejeitado pela regra
do chain, será aceito. Para alterar o policiamento padrão deste chain usamos o
comando:

iptables -t filter -P INPUT DROP

OBS: Note que policiamentos PERMISSIVOS (ACCEPT) normalmente são

usados em conjunto com regras restritivas no chain correspondentes (tudo é
bloqueado e o que sobrar é liberado) e policiamentos RESTRITIVOS (DROP) são
usados em conjunto com regras permissivas no chain correspondente (tudo é
liberado e o que sobrar é bloqueado pelo policiamento padrão).

6.3 Outras opções do iptables

6.3.1 Especificando um endereço de origem/destino

As opções -s (ou --src/--source)e -d (ou --dst/--destination) servem para
especificar endereços de origem e destino respectivamente. É permitido usar um
endereço IP completo (como 192.168.1.1), um hostname (debian), um endereço
fqdn (www.debian.org) ou um par rede/máscara (como
200.200.200.0/255.255.255.0 ou 200.200.200.0/24).
Caso um endereço/máscara não sejam especificados, é assumido 0/0 como
padrão (todos as máquinas de todas as redes). A interpretação dos endereços de
origem/destino dependem do chain que está sendo especificado (como INPUT e
OUTPUT por exemplo).
OBS: Caso seja especificado um endereço fqdn e este resolver mais de um
endereço IP, serão criadas várias regras, cada uma se aplicando a este endereço
IP específico. É recomendável sempre que possível a especificação de endereços
IP's nas regras, pois além de serem muito rápidos (pois não precisar de resolução
DNS) são mais seguros para evitar que nosso firewall seja enganado por um
ataque de IP spoofing.

# Bloqueia o tráfego vindo da rede 200.200.200.*:

iptables -A INPUT -s 200.200.200.0/24 -j DROP

# Bloqueia conexões com o destino 10.1.2.3:

iptables -A OUTPUT -d 10.1.2.3 -j DROP
 # Bloqueia o tráfego da máquina www.dominio.teste.org a rede 210.21.1.3
# nossa máquina possui o endereço 210.21.1.3
iptables -A INPUT -s www.dominio.teste.org -d 210.21.1.3 -j DROP

6.3.2 Especificando a interface de origem/destino

As opções -i (ou --in-interface) e -o (ou --out-interface) especificam as
interfaces de origem/destino de pacotes. Nem todos as chains aceitam as
interfaces de origem/destino simultaneamente, a interface de entrada (-i) nunca
poderá ser especificada em um chain OUTPUT e a interface de saída (-o) nunca
poderá ser especificada em um chain INPUT. Abaixo uma rápida referência:
+---------------------+--------------------------------+
TABELA | CHAIN | INTERFACE |
| +----------------+---------------+
| | ENTRADA (-i) | SAÍDA (-o) |
+---------+---------------------+----------------+---------------+
| | INPUT | SIM | NÃO |
| filter | OUTPUT | NÃO | SIM |
| | FORWARD | SIM | SIM |
+---------+---------------------+----------------+---------------+
| | PREROUTING | SIM | NÃO |
| nat | OUTPUT | NÃO | SIM |
| | POSTROUTING | NÃO | SIM |
+---------+---------------------+----------------+---------------+
| | PREROUTING | SIM | NÃO |
| mangle | | | |
| | OUTPUT | NÃO | SIM |
+---------+---------------------+----------------+---------------+
A definição de qual interface é permitida em qual chain é determinada pela
posição dos chains nas etapas de roteamento do pacote. O chain OUTPUT da
tabela filter somente poderá conter a interface de saída (veja a tabela acima). O
chain FORWARD da tabela filter é o único que aceita a especificação de ambas as
interfaces, este é um ótimo chain para controlar o tráfego que passa entre
interfaces do firewall.
Por exemplo para bloquear o acesso do tráfego de qualquer máquina com o
endereço 200.123.123.10 vinda da interface ppp0 (uma placa de fax-modem):

iptables -A INPUT -s 200.123.123.10 -i ppp0 -j DROP

A mesma regra pode ser especificada como

iptables -A INPUT -s 200.123.123.10 -i ppp+ -j DROP

O sinal de "+" funciona como um coringa, assim a regra terá efeito em

qualquer interface de ppp0 a ppp9. As interfaces ativas no momento podem ser
listadas com o comando ifconfig, mas é permitido especificar uma regra que faz
referência a uma interface que ainda não existe, isto é interessante para conexões
intermitentes como o PPP. Para bloquear qualquer tráfego local para a Internet:

iptables -A OUTPUT -o ppp+ -j DROP

Para bloquear a passagem de tráfego da interface ppp0 para a interface

eth1 (de uma de nossas redes internas):

iptables -A FORWARD -i ppp0 -o eth1 -j DROP

6.3.3 Especificando um protocolo

A opção -p (ou --protocol) é usada para especificar protocolos no iptables.
Podem ser especificados os protocolos tcp, udp e icmp. Por exemplo, para rejeitar
todos os pacotes UDP vindos de 200.200.200.200:

iptables -A INPUT -s 200.200.200.200 -p udp -j DROP

OBS1: Tanto faz especificar os nomes de protocolos em maiúsculas ou

minúsculas.

6.3.3.1 Especificando portas de origem/destino

As portas de origem/destino devem ser especificadas após o protocolo e
podem ser precedidas por uma das seguintes opções:
• --source-port ou --sport - Especifica uma porta ou faixa de portas de origem.
• --destination-port ou --dport - Especifica uma porta ou faixa de portas de
destino.
Uma faixa de portas pode ser especificada através de
PortaOrigem:PortaDestino:

# Bloqueia qualquer pacote indo para 200.200.200.200 na faixa de

# portas 0 a 1023
iptables -A OUTPUT -d 200.200.200.200 -p tcp --dport :1023 -j DROP

Caso a PortaOrigem de uma faixa de portas não seja especificada, 0 é

assumida como padrão, caso a Porta Destino não seja especificada, 65535 é
assumida como padrão. Caso precise especificar diversas regras que envolvam o
tratamento de portas diferentes, recomendo da uma olhada em “6.6.6
Especificando múltiplas portas de origem/destino”, antes de criar um grande
número de regras.
6.3.3.2 Especificando mensagens do protocolo ICMP
O protocolo ICMP não possui portas, mas é possível fazer um controle
maior sobre o tráfego ICMP que entra/sai da rede através da especificação dos
tipos de mensagens ICMP. Os tipos de mensagens devem ser especificados com
a opção "--icmp-type CódigoICMP" logo após a especificação do protocolo icmp:

iptables -A INPUT -s 200.123.123.10 -p icmp --icmp-type time-exceeded -i ppp+ -j DROP

A regra acima rejeitará mensagens ICMP do tipo "time-exceeded" (tempo

de requisição excedido) que venham do endereço 200.123.123.10 através da
interface ppp+.
Alguns tipos de mensagens ICMP são classificados por categoria (como o
próprio "time-exceeded"), caso a categoria "time-exceeded" seja especificada,
todas as mensagens daquela categoria (como "ttl-zero-during-transit", "ttl-zero-
during-reassembly") conferirão na regra especificada.Os tipos de mensagens
ICMP podem ser obtidos com o comando iptables -p icmp -h:

echo-reply (pong)
destination-unreachable
network-unreachable
host-unreachable
protocol-unreachable
port-unreachable
fragmentation-needed
source-route-failed
network-unknown
host-unknown
network-prohibited
host-prohibited
TOS-network-unreachable
TOS-host-unreachable
communication-prohibited
host-precedence-violation
precedence-cutoff
source-quench
redirect
network-redirect
host-redirect
TOS-network-redirect
TOS-host-redirect
echo-request (ping)
router-advertisement
router-solicitation
time-exceeded (ttl-exceeded)
ttl-zero-during-transit
 ttl-zero-during-reassembly
parameter-problem
ip-header-bad
required-option-missing
timestamp-request
timestamp-reply
address-mask-request
address-mask-reply

OBS1: Não bloqueie mensagens do tipo "host-unreachable" senão terá

sérios problemas no controle de suas conexões.

6.3.3.3 Especificando pacotes syn

Pacotes syn são usados para iniciarem uma conexão, o uso da opção --syn
serve para especificar estes tipos de pacotes. Desta maneira é possível bloquear
somente os pacotes que iniciam uma conexão, sem afetar os pacotes restantes.
Para que uma conexão ocorra é necessário que a máquina obtenha a resposta a
pacotes syn enviados, caso ele seja bloqueado a resposta nunca será retornada e
a conexão não será estabelecida.

iptables -A INPUT -p tcp --syn --dport 23 -i ppp+ -j DROP

A regra acima bloqueia (-j DROP) qualquer tentativa de conexão (--syn)

vindas da interface ppp+ ao telnet (--dport 23) da máquina local, conexões já
efetuadas ão são afetadas por esta regra. A opção --syn somente pode ser
especificada para o protocolo tcp.
ATENÇÃO: - A situação de passagem de pacotes durante deve ser levada
em conta durante a inicialização do firewall, bloqueando a passagem de pacotes
durante o processo de configuração, criando regras que bloqueiam a passagem
de pacotes (exceto para a interface loopback) até que a configuração do firewall
esteja completa, pode ser uma solução eficiente.
Outra alternativa segura é configurar as regras de firewall antes das
interfaces de rede se tornarem ativas (usando a opção "pre-up comando_firewall"
no arquivo de configuração /etc/network/interfaces em sistemas Debian.

6.3.4 Especificando fragmentos

A opção "-f" (ou --fragment) permite especificar regras que confiram com
fragmentos. Fragmentos são simplesmente um pacote maior dividido em pedaços
para poder ser transmitido via rede TCP/IP para remontagem do pacote pela
máquina de destino.
Somente o primeiro fragmento possui detalhes de cabeçalho para ser
processado, os segundos e seguintes somente possuem alguns cabeçalhos
necessários para dar continuidade ao processo de remontagem do pacote no
destino.
 Uma regra como

iptables -A INPUT -s 200.200.200.1 -f -j DROP

derrubará os fragmentos de 200.200.200.1 que cheguem até nós.

OBS1: Note que se o cabeçalho do pacote não tiver detalhes suficientes
para checagem de regras no iptables, a regra simplesmente não ira conferir.
OBS2: Não é preciso especificar a opção "-f" para conexões NAT, pois os
pacotes são remontados antes de entrarem no código de filtragem.
OBS3: A opção "-f" também pode ser usada para evitar o flood por
fragmentos (bomba de fragmentos) que, dependendo da intensidade, podem até
travar a máquina.

6.3.5 Especificando uma exceção

Muitos parâmetros como o endereço de origem/destino, protocolo, porta,
mensagens ICMP, fragmentos, etc) podem ser precedidos pelo sinal "!" que
significa exceção. Por exemplo:

iptables -t filter -A INPUT ! -s 200.200.200.10 -j DROP

Diz para rejeitar todos os pacotes EXCETO os que vem do endereço

200.200.200.10.

iptables -A INPUT -p tcp ! --syn -s 200.200.200.10 ! -i eth0 -j DROP

Diz para bloquear todos os pacotes EXCETO os que iniciam conexões (! --

syn), EXCETO para pacotes vindos na interface eth0 (! -i eth0).

iptables -A INPUT -s 200.200.200.10 ! -p tcp -j DROP

Bloqueia todos os pacotes vindos de 200.200.200.10, EXCETO os do

protocolo tcp.

6.3.6 Especificando um alvo

O alvo (-j) é o destino que um pacote terá quando conferir com as
condições de uma regra, um alvo pode dizer para bloquear a passagem do pacote
(-j DROP), aceitar a passagem do pacote (-j ACCEPT), registrar o pacote no
sistema de log (-j LOG), rejeitar o pacote (-j REJECT), redirecionar um pacote -j
REDIRECT, retornar ao chain anterior sem completar o processamento no chain
atual (-j RETURN), passar para processamento de programas externos (-j
QUEUE), fazer source nat (-j SNAT), destination nat (-j DNAT), etc. Podem existir
mais alvos, pois o iptables é modularizável, e módulos que acrescentam mais
funções podem ser carregados em adição aos já existentes no kernel.
Nos exemplos anteriores vimos o uso de diversos alvos como o DROP e o
ACCEPT. Apenas farei uma breve referência sobre os alvos mais usados em
operações mais comuns dos chains. Os alvos REDIRECT, SNAT e DNAT serão
explicados em uma seção seguinte:
• ACCEPT: O pacote é ACEITO e o processamento das regras
daquele chains é concluído. Pode ser usado como alvo em todos os
chains de todas as tabelas do iptables e também pode ser especificado
no policiamento padrão das regras do firewall (veja “6.2.11
Especificando o policiamento padrão de um chain - P”).
• DROP: Rejeita o pacote e o processamento das regras daquele chain
é concluído. Pode ser usado como alvo em todos os chains de todas as
tabelas do iptables e também pode ser especificado no policiamento
padrão das regras do firewall (veja “6.2.11 Especificando o policiamento
padrão de um chain - P”).
• REJECT: Este é um módulo opcional que faz a mesma função do alvo
DROP com a diferença de que uma mensagem ICMP do tipo "icmp-port-
unreachable" é retornada para a máquina de origem. Pode ser usado
como alvo somente nos chains da tabela filter.
• LOG: Este módulo envia uma mensagem ao syslog caso a
regra confira, o processamento continua normalmente para a próxima
regra (o pacote não é nem considerado ACEITO ou REJEITADO).
• RETURN: Retorna o processamento do chain anterior sem
processar o resto do chain atual.
• QUEUE: Passa o processamento para um programa a nível de usuário.

6.3.6.1 Alvo REJECT

Para ser usado, o módulo ipt_REJECT deve ser compilado no kernel ou
como módulo. Este alvo rejeita o pacote (como o DROP) e envia uma mensagem
ICMP do tipo "icmp-port-unreachable" para a máquina de origem.
É um alvo interessante para bloqueio de portas TCP, pois em alguns casos
da a impressão que a máquina não dispõe de um sistema de firewall (o alvo
DROP causa uma parada de muito tempo em alguns portscanners e tentativas de
conexão de serviços, revelando imediatamente o uso de um sistema de firewall
pela máquina). O alvo REJECT vem dos tempos do ipchains e somente pode ser
usado na tabela filter. Quando um pacote confere, ele é rejeitado com a
mensagem ICMP do tipo "port unreachable", é possível especificar outro tipo de
mensagem ICMP com a opção --reject-with tipo_icmp.
OBS: REJECT pode ser usado somente como alvo na tabela filter e não é
possível especifica-lo como policiamento padrão do chain filter (como acontecia no
ipchains. Uma forma alternativa é inserir como última regra uma que pegue todos
os pacotes restantes daquele chain e tenha como alvo REJECT (como iptables -A
INPUT -j REJECT), desta forma ele nunca atingirá o policiamento padrão do chain.

# Rejeita pacotes vindos de 200.200.200.1 pela interface ppp0:

 iptables -A INPUT -s 200.200.200.1 -i ppp+ -j REJECT

6.3.6.2 Especificando LOG como alvo

Este alvo é usado para registrar a passagem de pacotes no syslog do
sistema. É um alvo muito interessante para ser usado para regras que bloqueiam
determinados tráfegos no sistema (para que o administrador tome conhecimento
sobre tais tentativas), para regras de fim de chain (quando você tem um grande
conjunto de regras em um firewall restritivo e não sabe onde suas regras estão
sendo bloqueadas), para satisfazer sua curiosidade, etc.

# Para registrar o bloqueio de pacotes vindos de 200.200.200.1 pela interface ppp0

iptables -A INPUT -s 200.200.200.1 -i ppp+ -j LOG
# Para efetuar o bloqueio
iptables -A INPUT -s 200.200.200.1 -i ppp+ -j REJECT

Note que a regra que registra o pacote (-j LOG) deve aparecer antes da
regra que REJEITA (-j REJECT), caso contrário a regra de LOG nunca funcionará.
A única coisa que muda nas regras de log é o alvo da regra, isto facilita a
implementação de grandes conjuntos de regras de firewall.
A regra acima mostrará a seguinte saída no syslog do sistema:

Aug 25 10:08:01 debian kernel: IN=ppp0 OUT= MAC=10:20:30:40:50:60:70:80:90:00:00:00:08:00

SRC=200.200.200.1 DST=200.210.10.10 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1031
DPT=53 LEN=41

Os campos possuem o seguinte significado:

Aug 25 10:08:01
Mês, dia e hora do registro do pacote.
debian
Nome do computador que registrou o pacote.
kernel:
Daemon que registrou a mensagem, no caso o iptables faz parte do
próprio kernel.
IN=ppp0
Especifica a interface de entrada (de onde o pacote veio).
OUT=
Especifica a interface de saída (para onde o pacote foi).
MAC=10:20:30:40:50:60:70:80:90:00:00:00:08:00
Endereço mac da interface de rede (pode ser obtido com arp
interface).
 SRC=200.200.200.1
Endereço de origem do pacote.
DST=200.210.10.10
Endereço de destino do pacote.
LEN=61
Tamanho do pacote.
TOS=0x00
Prioridade do cabeçalho TOS (prioridade normal neste caso). Veja a
seção Especificando o tipo de serviço, Section 9.5.1
<http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm> para mais
detalhes.
PROTO=UDP
Nome do protocolo. Pode ser TCP, UDP ou ICMP
SPT=1031
Porta de origem da requisição.
DPT=53
Porta de destino da requisição.
LEN=41
Tamanho do pacote.
O log acima mostra uma consulta DNS (porta destino 53) para nossa
máquina (INPUT) de 200.200.200.1 para 200.210.10.10.
O problema é que em um grande número de regras será difícil saber qual
regra conferiu (pois teríamos que analisar o endereço/porta origem/destino) e o
destino do pacote (se ele foi ACEITO ou BLOQUEADO) pois você pode ter regras
para ambas as situações. Por este motivo existem algumas opções úteis que
podemos usar com o alvo LOG:
--log-prefix "descrição"
Permite especificar uma descrição para a regra do firewall de até 29
caracteres. Caso tiver espaços, devem ser usadas "aspas".
--log-level nível
Especifica o nível da mensagem no syslog.
--log-tcp-options
Registra campos do cabeçalho TCP nos logs do sistema.
--log-ip-options
Registra campos do cabeçalho IP nos logs do sistema
--log-tcp-sequence
 Registra os números de seqüencia TCP. Evite ao máximo o uso
desta opção, pois a seqüencia de números TCP pode ser a chave para um
seqüestro de seção ou IP spoofing em seu sistema caso algum usuário
tenha acesso a estes logs.
Lembre-se que estas opções são referentes ao alvo LOG, e devem ser
usadas após este, caso contrário você terá um pouco de trabalho para analisar e
consertar erros em suas regras do firewall.

# Complementando o exemplo anterior:

# Para registrar o bloqueio de pacotes vindos de 200.200.200.1 pela interface ppp0
iptables -A INPUT -s 200.200.200.1 -i ppp+ -j LOG --log-prefix "FIREWALL: Rejeitado "
# Para efetuar o bloqueio
iptables -A INPUT -s 200.200.200.1 -i ppp+ -j REJECT

Retornará a seguinte mensagem no syslog:

Aug 25 10:08:01 debian kernel: FIREWALL: Rejeitado IN=ppp0 OUT=

MAC=10:20:30:40:50:60:70:80:90:00:00:00:08:00 SRC=200.200.200.1 DST=200.210.10.10 LEN=61
TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1031 DPT=53 LEN=41

Agora você sabe o que aconteceu com o pacote (Rejeitado). A

padronização de mensagens de firewall é também importante para a criação de
scripts de análise que poderão fazer a análise dos logs do seu firewall (para
criação de estatísticas que podem servir como base para a criação de novas
regras de firewall ou eliminação de outras).
OBS: Se você sente falta da função "-l" do ipchains que combina o alvo e
log na mesma regra você pode criar um alvo como o seguinte:

iptables -N log-drop
iptables -A log-drop -j LOG
iptables -A log-drop -j DROP

E usar "log-drop" como alvo em suas regras. Mesmo assim esta solução é
"limitada" em relação a "-l" do ipchains porque o iptables não inclui detalhes de
qual chain bloqueou o pacote/qual pacote foi bloqueado, assim é necessário a
especificação da opção --log-prefix para as mensagens se tornarem mais
compreensíveis. Infelizmente o iptables não aceita variáveis, senão esta limitação
seria facilmente contornada.

6.3.6.3 Especificando RETURN como alvo

O alvo RETURN diz ao iptables interromper o processamento no chain atual
e retornar o processamento ao chain anterior. Ele é útil quando criamos um chain
que faz um determinado tratamento de pacotes, por exemplo bloquear conexões
vindas da internet para portas baixas, exceto para um endereço IP específico.
Como segue:
iptables -t filter -A INPUT -i ppp0 -j internet
iptables -t filter -j ACCEPT
iptables -t filter -N internet
iptables -t filter -A internet -s www.debian.org -p tcp --dport 80 -j RETURN
iptables -t filter -A internet -p tcp --dport 21 -j DROP
iptables -t filter -A internet -p tcp --dport 23 -j DROP
iptables -t filter -A internet -p tcp --dport 25 -j DROP
iptables -t filter -A internet -p tcp --dport 80 -j DROP

Quando um pacote com o endereço www.debian.org tentando acessar a

porta www (80) de nossa máquina através da internet (via interface ppp0), o chain
número 1 confere, então o processamento continua no chain número 4, o chain
número 4 confere então o processamento volta para a regra número 2, que diz
para aceitar o pacote.
Agora se um pacote vem com o endereço www.dominio.com.br tentando
acessar a porta www *80) de nossa máquina através da internet (via interface
ppp0), o chain número 1 confere, então o processamento continua no chain
número 4, que não confere. O mesmo acontece com os chains 5, 6 e 7. O chain
número 8 confere, então o acesso é bloqueado.
Como pode ter notado, o alvo RETURN pode facilitar bastante a construção
das regras do seu firewall, caso existam máquinas/redes que sejam exceções as
suas regras. Se ela não existisse, seria necessário especificar diversas opções -s,
-d, etc para poder garantir o acesso livre a determinadas máquinas.

6.4 A tabela nat (Network Address Translation) - fazendo nat

A tabela nat serve para controlar a tradução dos endereços que atravessam
o código de roteamento da máquina Linux. Existem 3 chains na tabela nat:
PREROUTING, OUTPUT e POSTROUTING (veja “6.1.14 O que são tabelas?”
para maiores detalhes).
A tradução de endereços tem inúmeras utilidades, uma delas é o
Masquerading, onde máquinas de uma rede interna podem acessar a Internet
através de uma máquina Linux, redirecionamento de porta, proxy transparente,
etc. Esta seção abordará os tipos de NAT, exemplos de como criar rapidamente
uma conexão IP masquerading e entender como a tradução de endereços
funciona no iptables.
Se sua intenção é ligar sua rede a Internet existem duas opções:
• Você possui uma conexão que lhe oferece um endereço IP dinâmico (a
cada conexão é dado um endereço IP - como uma conexão PPP) então o
IP masquerading é o que precisa (veja “6.4.2 Fazendo IP masquerading
(para os apressados)” ou “6.4.3.1 Fazendo IP Masquerading”).
• Você tem uma conexão que lhe oferece um endereço IP permanente
(ADSL, por exemplo) então o SNAT é o que precisa (veja “6.4.3 Fazendo
SNAT”).
6.4.1 Criando um novo chain na tabela NAT
O procedimento para criação de um novo chain nesta tabela é o mesmo
descrito em “6.2.6 Criando um novo chain - N” será necessário somente
especificar a tabela nat (-t nat) para que o novo chain não seja criado na tabela
padrão (-t filter).

iptables -t nat -N intra-inter

Que criará o chain chamado intra-inter na tabela nat. Para inserir regras
neste chain será necessário especificar a opção "-t nat".

6.4.2 Fazendo IP masquerading (para os apressados)

Você precisará de um kernel com suporte ao iptables (veja “6.1.15
Habilitando o suporte ao iptables no kernel” e ip_forwarding e então digitar os dois
comandos abaixo para habilitar o masquerading para todas as máquinas da rede
192.168.1.*:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

echo "1" >/proc/sys/net/ipv4/ip_forwarding

A configuração do servidor Linux está completa, agora os clientes da rede

precisarão ser configurados para usar o endereço IP do servidor Linux como
gateway. É recomendável instalar um servidor proxy e DNS na máquina Linux
para acelerar o desempenho das requisições/resolução de nomes das máquinas
em rede. A utilização de bits TOS também pode trazer um grande aumento de
velocidade para os diferentes serviços da rede (veja “6.5.1 Especificando o tipo de
serviço”).

6.4.3 Fazendo SNAT

SNAT (source nat - nat no endereço de origem) consiste em modificar o
endereço de origem das máquinas clientes antes dos pacotes serem enviados. A
máquina roteadora é inteligente o bastante para lembrar dos pacotes modificados
e reescrever os endereços assim que obter a resposta da máquina de destino,
direcionando os pacotes ao destino correto. Toda operação de SNAT é feita no
chain POSTROUTING.
É permitido especificar endereços de origem/destino, protocolos, portas de
origem/destino, interface de entrada/saída (dependendo do chain), alvos, etc. É
desnecessário especificar fragmentos na tabela nat, pois eles serão remontados
antes de entrar no código de roteamento.
O SNAT é a solução quando você tem acesso a internet através de um
único IP e deseja fazer que sua rede tenha acesso a Internet através da máquina
Linux. Nenhuma máquina da Internet poderá ter acesso direto as máquinas de
sua rede interna via SNAT.
OBS: A observação acima não leva em conta o controle de acesso externo
configurado na máquina que estiver configurando o iptables, uma configuração
mau realizada pode expor sua máquina a acessos externos indesejados e
comprometer sua rede interna caso alguém consiga acesso direto ao servidor.
É necessário especificar SNAT como alvo (-j SNAT) quando desejar que as
máquinas de sua rede interna tenha acesso a Internet através do IP fixo da
máquina Linux (para conexões intermitentes como PPP, veja “6.4.3.1 Fazendo IP
Masquerading”). O parâmetro --to IP:portas deve ser usado após o alvo SNAT.
Ele serve para especificar um endereço IP, faixa de endereços e opcionalmente
uma porta ou faixa de portas que será substituída. Toda a operação de SNAT é
realizada através do chain POSTROUTING:

# Modifica o endereço IP dos pacotes vindos da máquina 192.168.1.2 da rede interna

# que tem como destino a interface eth1 para 200.200.217.40 (que é o nosso endereço
# IP da interface ligada a Internet).
iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth1 -j SNAT --to 200.200.217.40

Os pacotes indo para a Internet (nossa conexão é feita via eth1, nossa
interface externa) vindo do endereço 192.168.1.2, são substituídos por
200.241.200.40 e enviados para fora. Quando a resposta a requisição é
retornada, a máquina com iptables recebe os pacotes e faz a operação inversa,
modificando o endereço 200.241.200.40 novamente para 192.168.1.2 e enviando
a resposta a máquina de nossa rede interna. Após definir suas regras de NAT,
execute o comando echo "1" >/proc/sys/net/ipv4/ip_forward para habilitar o suporte
a redirecionamento de pacotes no kernel.
Também é possível especificar faixas de endereços e portas que serão
substituídas:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to

200.200.217.40-200.200.217.50

Modifica o endereço IP de origem de todas as máquinas da rede

192.168.1.0/24 que tem o destino a interface eth0 para 200.241.200.40 a
200.241.200.50. O endereço IP selecionado é escolhido de acordo com o último
IP alocado. # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \ -j
SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to

200.200.217.40-200.200.217.50:1-1023

Idêntico ao anterior, mas faz somente substituições na faixa de portas de

origem de 1 a 1023.

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to

200.200.217.40-200.200.217.50 --to 200.200.217.70-200.200.217.73

Faz o mapeamento para a faixa de portas 200.200.217.40 a 200.200.217.50

e de 200.200.217.70 a 200.200.217.73.
 OBS1: Se por algum motivo não for possível mapear uma conexão NAT,
ela será derrubada. OBS2: Tenha certeza que as respostas podem chegar até a
máquina que fez o NAT. Se estiver fazendo SNAT em um endereço livre em sua
rede (como 200.200.217.73).
OBS2: Como notou acima, o SNAT é usado quando temos uma conexão
externa com um ou mais IP's fixos. O Masquerading é uma forma especial de
SNAT usada para funcionar em conexões que recebem endereços IP aleatórios
(PPP).
OBS3: Não se esqueça de habilitar o redirecionamento de pacotes após
fazer suas regra de NAT com o comando: echo "1"
>/proc/sys/net/ipv4/ip_forward, caso contrário o redirecionamento de
pacotes não funcionará.

6.4.3.1 Fazendo IP Masquerading

O IP Masquerading é um tipo especial de SNAT usado para conectar a sua
rede interna a internet quando você recebe um IP dinâmico de seu provedor
(como em conexões ppp). Todas as operações de IP Masquerading são
realizadas no chain POSTROUTING. Se você tem um IP fixo, deve ler “6.4.3
Fazendo SNAT”.
Para fazer IP Masquerading de uma máquina com o IP 192.168.1.2 para ter
acesso a Internet, use o comando:

iptables -t nat -A POSTROUTING -s 192.168.1.2/32 -o ppp0 -j MASQUERADE

A diferença é que o alvo é -j MASQUERADE. O comando acima faz IP

Masquerading de todo o tráfego de 192.168.1.2 indo para a interface ppp0: O
endereço IP dos pacotes vindos de 192.168.1.2 são substituídos pelo IP oferecido
pelo seu provedor de acesso no momento da conexão, quando a resposta é
retornada a operação inversa é realizada para garantir que a resposta chegue ao
destino. Nenhuma máquina da internet poderá ter acesso direto a sua máquina
conectava via Masquerading.
Para fazer o IP Masquerading de todas as máquinas da rede 192.168.1.*:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp0 -j MASQUERADE

Após definir a regra para fazer Masquerading (SNAT), execute o comando

echo "1" >/proc/sys/net/ipv4/ip_forward para habilitar o suporte a
redirecionamento de pacotes no kernel.

6.4.4 Fazendo DNAT

DNAT (Destination nat - nat no endereço de destino) consiste em modificar
o endereço de destino das máquinas clientes. O destination nat é muito usado
para fazer redirecionamento de pacotes, proxyes transparentes e balanceamento
de carga.
 Toda operação de DNAT é feita no chain PREROUTING. As demais
opções e observações do SNAT são também válidas para DNAT (com exceção
que somente é permitido especificar a interface de origem no chain
PREROUTING).

# Modifica o endereço IP destino dos pacotes de 192.168.1.2 vindo da interface eth0

# para 200.200.217.40.
iptables -t nat -A PREROUTING -s 192.168.1.2 -i eth0 -j DNAT --to 200.200.217.40

Também é possível especificar faixas de endereços e portas que serão

substituídas no DNAT:

iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 200.200.217.40-200.200.217.50

Modifica o endereço IP de destino do tráfego vindos da interface

192.168.1.0/24 para um IP de 200.241.200.40 a 200.241.200.50. Este é um
excelente método para fazer o balanceamento de carga entre servidores. O
endereço IP selecionado é escolhido de acordo com o último IP alocado.

iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 200.200.217.40-

200.200.217.50:1024:5000

Idêntico ao anterior, mas faz somente substituições na faixa de portas de

destino de 1024 a 5000. A operação acima é a mesma realizada pelo ipmasqadm
dos kernels da série 2.2.
OBS: Se por algum motivo não for possível mapear uma conexão NAT, ela
será derrubada.

6.4.4.1 Redirecionamento de portas

O redirecionamento de portas permite a você repassar conexões com
destino a uma porta para outra porta na mesma máquina. O alvo REDIRECT é
usado para fazer esta operação, junto com o argumento --to-port especificando a
porta que será redirecionada. Este é o método DNAT específico para se para
fazer proxy transparente (para redirecionamento de endereços/portas, veja “6.4.4
Fazendo DNAT”). Todas as operações de redirecionamento de portas é realizada
no chain PREROUTING.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 81

Redireciona as conexões indo para a porta 80 para a porta 81 (rodando

squid) no firewall.
ATENÇÃO: O squid possui suporte a proxy transparente, e poderá atender
as requisições acima da regra acima.
6.4.5 Monitorando conexões feitas na tabela nat
Use o comando cat /proc/net/ip_conntrack para listar todas as
conexões atuais tratadas pelo módulo nat.

6.5 A tabela mangle

A tabela mangle serve para especificar ações especiais para o tratamento
do tráfego que atravessa os chains. Nesta tabela existem dois chains:
PREROUTING e OUTPUT (veja “6.1.14 O que são tabelas?” para maiores
detalhes).
Opções com o Tipo de Serviço (TOS) é especificada nesta tabela para
classificar e aumentar consideravelmente a velocidade de tráfego considerados
em tempo real.

6.5.1 Especificando o tipo de serviço

O tipo de serviço é um campo existente no cabeçalho de pacotes do
protocolo ipv4 que tem a função especificar qual é a prioridade daquele pacote.
Uma das vantagens da utilização do tipo de serviço é dar prioridade ao tráfego de
pacotes interativos (como os do ICQ, IRC, servidores de chat), etc. Com o TOS
especificado, mesmo que esteja fazendo um download consumindo toda a banda
de sua interface de rede, o tráfego com prioridade interativa será enviado antes,
aumentando a eficiência dos serviços em sua máquina.
Em testes realizados em minha conexão de 56K, o uso de regras TOS
aumentou bastante o desempenho em tráfego interativo (em torno de 300%),
durante o uso total da banda da interface ppp em um grande download.
Usamos o alvo TOS (-j TOS) para especificar a modificação do tipo de
serviço nos pacotes que atravessam as regras do firewall, acompanhada do
argumento --set-tos TOS que define a nova prioridade dos pacotes. Os valores
aceitos são os seguintes:
Espera Mínima
É especificado através de Minimize-Delay, 16 ou 0x10
Máximo Processamento
É especificado através de Maximize-Throughput, 8, ou 0x08.
Máxima Confiança
É especificado através de Maximize-Reliability, 4 ou 0x04.
Custo mínimo
Especificado através de Minimize-Cost, 2 ou 0x02.
Prioridade Normal
Especificado através de Normal-Service, 0 ou 0x00.
Os pacotes vem por padrão com o valor TOS ajustado como prioridade
normal (bits tos ajustados para 0x00). O tipo Mínima Espera é o mais usado, pois
prioriza o tráfego em serviços interativos.

6.5.1.1 Especificando o TOS para tráfego de saída

Este é o mais usado, pois prioriza o tráfego que sai da máquina (com
destino a Internet, por exemplo). Sua operação é realizada através do chain
OUTPUT.
Para priorizar todo o tráfego de IRC de nossa rede interna indo para a
interface ppp0:

iptables -t mangle -A OUTPUT -o ppp0 -p tcp --dport 6666-6668 -j TOS --set-tos 16

O bit TOS é ajustado para Espera mínima e será enviado antes dos pacotes
com prioridade normal para fora. Para priorizar a transmissão de dados ftp saindo
da rede:

iptables -t mangle -A OUTPUT -o ppp0 -p tcp --dport 20 -j TOS --set-tos 8

Para priorizar o tráfego de ICQ da rede:

iptables -t mangle -A OUTPUT -o ppp0 -p udp --dport 4000 -j TOS --set-tos 16

Existem muitas outras otimizações que podem ser feitas, só depende dos
requerimentos e análise de cada serviço da rede pelo administrador.
OBS: - Os pacotes que atravessam o alvo TOS somente tem os bits tipo do
serviço modificados, eles não serão de qualquer forma rejeitados.

6.5.1.2 Especificando o TOS para o tráfego de entrada

Este prioriza o tráfego que entra da máquina. Sua operação é realizada no
chain PREROUTING. Não faz muito sentido o uso deste chain dentro de uma
rede pequena/média, pois o tráfego que recebermos será priorizado pelo saída de
outras máquinas da internet/outras redes antes de chegar a nossa.
Para priorizar o processamento do tráfego interativo vindo de servidores
IRC para nossa rede:

iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 6666-6668 -j TOS --set-tos 0x10

Modifica o tipo de serviço para mínima espera de todo o tráfego enviado por
servidores de IRC vindo da interface eth0.
OBS: - Os pacotes que atravessam o alvo TOS somente tem os bits tipo do
serviço modificados, eles não serão de qualquer forma rejeitados.
6.6 Outros módulos do iptables
Os módulos do iptables são especificados com a opção -m módulo ou --
match módulo e permitem expandir a funcionalidade do firewall através de novas
conferências e recursos de filtragem adicionais, como limitar a conferência de
regras do firewall (um método útil de limitar ping floods, syn floods, etc).

6.6.1 Conferindo de acordo com o estado da conexão

Este módulo permite especificar regras de acordo com o estado da conexão
do pacote, isto é feito através da interpretação da saída do módulo ip_conntrack.
O parâmetro --state OPÇÕES deve acompanhar este módulo. As opções
permitidas são as seguintes:
• NEW - Confere com pacotes que criam novas conexões
• ESTABLISHED - Confere com conexões já estabelecidas
• RELATED - Confere com pacotes relacionados indiretamente a uma
conexão, como mensagens de erro icmp, etc.
• INVALID - Confere com pacotes que não puderam ser identificados por
algum motivo. Como respostas de conexões desconhecidas.
Caso seja necessário especificar mais de uma opções estas devem ser
separadas por vírgulas.

iptables -A INPUT -m state --state NEW -i ppp0 -j DROP

Bloqueia qualquer tentativa de nova conexão vindo da interface ppp0.

iptables -A INPUT -m state --state NEW,INVALID -i ppp0 -j LOG

Permite registrar novas conexões e pacotes inválidos vindos da interface

ppp0.

6.6.2 Limitando o número de vezes que a regra confere

A opção -m limit permite especificar o número de vezes que uma regra
conferirá quando todas as outras condições forem satisfeitas. O número padrão
de conferência é de 3 por hora, a não ser que seja modificado através dos
argumentos aceitos pelo limit:
• --limit num/tempo - Permite especificar a taxa de conferências do limit. O
parâmetro num especifica um número e tempo pode ser

o s - Segundo

o m - Minuto
 o h - Hora

o d - Dia
Assim uma regra como iptables -A INPUT -m limit --limit 5/m -j ACCEPT
permitirá que a regra acima confira apenas 5 vezes por minuto (--limit 2/s).
Este limite pode ser facilmente adaptado para uma regra de log que confere
constantemente não causar uma avalanche em seus logs. O valor padrão
é 3/h.
• --limit-burst num - Especifica o número inicial máximo de pacotes que irão
conferir, este número é aumentado por 1 a cada vez que o parâmetro --limit
acima não for atingido. O valor padrão é 5.

6.6.3 Proteção contra ping da morte

A regra abaixo pode tomada como base para proteção contra ping flood:

iptables -t filter -A ping-chain -p icmp --icmp-type echo-request -m limit --limit

1/s -j ACCEPT
iptables -t filter -A ping-chain -j DROP

A regra acima limita em 1 vez por segundo (--limit 1/s) a passagem de pings
(echo requests) para a máquina Linux.

iptables -t filter -A ping-chain -i ppp0 -p icmp --icmp-type echo-reply -m limit --

limit 1/s -j RETURN
iptables -t filter -A ping-chain -j DROP

Limita respostas a pings (echo reply) vindos da interface ppp0 (-i ppp0) a 1
por segundo.
ATENÇÃO: Os exemplos acima devem são somente exemplos para
criação de suas próprias regras com limitações, caso um pacote não confira com a
regra ele será bloqueado pela próxima regra. Se uma regra como for colocada no
chain INPUT sem modificações obviamente colocará em risco a segurança de seu
sistema.

6.6.4 Proteção contra syn flood

A regra abaixo é uma boa proteção para os ataques syn floods:

iptables -t filter -A syn-chain -p tcp --syn -m limit --limit 2/s -j ACCEPT

iptables -t filter -A syn-chain -j DROP

Esta regra limita o atendimento de requisições de conexões a 2 por

segundo.
ATENÇÃO: Os exemplos acima devem são somente exemplos para
criação de suas próprias regras com limitações, caso um pacote não confira com a
regra ele será bloqueado pela próxima regra. Se uma regra como for colocada no
chain INPUT sem modificações obviamente colocará em risco a segurança de seu
sistema.

6.6.5 Proteção contra IP spoofing

A especificação de endereços de origem/destino junto com a interface de
rede pode ser usado como um detector de ataques spoofing. A lógica é que todos
os endereços que NUNCA devem vir da interface X devem ser negados
imediatamente. As regras abaixo são colocadas no inicio do chain INPUT para
detectar tais ataques:

iptables -A INPUT -s 192.168.1.0/24 -i ! eth0 -j DROP

iptables -A INPUT ! -s 192.168.1.0/24 -i eth0 -j DROP

A primeira regra diz para bloquear todos os endereços da faixa de rede

192.168.1.* que NÃO vem da interface eth0, a segunda regra diz para bloquear
todos os endereços que não sejam 192.168.1.* vindos da interface eth0. O
símbolo "!" serve para especificar exceções (veja “6.3.5 Especificando uma
exceção”). O kernel do Linux automaticamente bloqueia a passagem de pacotes
que dizem ser de 127.0.0.1 e não está vindo da interface loopback.
O método preferido para controlar o ip spoofing é através do código de
roteamento do kernel (a não ser que esteja usando algum tipo de roteamento
assimétrico):

for i in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 >$i
done

Desta forma qualquer endereço dizendo ser 192.168.1.5 vindo de ppp0 será
imediatamente rejeitado. Uma checagem adicional contra IP spoofing pode ser
feita no arquivo /etc/host.conf.

6.6.6 Especificando múltiplas portas de origem/destino

O módulo multiport permite que seja especificado múltiplas portas para um
alvo. Podem ser especificadas até 15 portas em um único parâmetro e basta que
uma porta confira para que a regra entre em ação, pois a comparação é feita
usando condições "or". O parâmetro multiport deve ser acompanhado de um dos
argumentos abaixo:
• --source-port [porta1, porta2...] - Faz a regra conferir se a porta de origem
estiver presente entre as portas especificadas.
• --destination-port [porta1, porta2...] - Faz a regra conferir se a porta de
destino estiver presente entre as portas especificadas.
 • --port [porta1, porta2...] - Faz a regra conferir caso a porta de origem ou
destino esteja presente no parâmetro.
Este módulo pode eliminar muitas regras de firewall que fazem o mesmo
tratamento de pacotes para diversas portas diferentes.

iptables -A INPUT -p tcp -i ppp0 -m multiport --destination-port

21,23,25,80,110,113,6667 -j DROP

Bloqueia todos os pacotes vindo de ppp0 para as portas 21 (ftp), 23 (telnet),

25 (smtp), 80 (www), 110 (pop3), 113 (ident), 6667 (irc).

6.6.7 Especificando o endereço MAC da interface

O módulo mac serve para conferir com o endereço Ethernet dos pacotes de
origem. Somente faz sentido se usado nos chains de PREROUTING (da tabela
nat) ou INPUT (da tabela filter). Aceita como argumento a opção --mac-source
endereço. O símbolo "!" pode ser usado para especificar uma exceção.

iptables -t filter -A INPUT -m mac --mac-source 00:80:AD:B2:60:0B -j DROP

Confere com a máquina com endereço ethernet igual a

00:80:AD:B2:60:0B.

6.6.8 Conferindo com quem criou o pacote

Este módulo confere com o usuário que iniciou a conexão. É somente
válido no chain OUTPUT da tabela filter. Os seguintes argumentos são válidas
para este módulo:
• --uid-owner UID - Confere se o pacote foi criado por um processo com o
UID especificado. Até o momento somente UID numéricos são aceitos.
• --gid-owner GID - Confere se o pacote foi criado por um usuário
pertencente ao grupo GID. Até o momento somente GID numéricos são
aceitos.
• --pid-owner PID - Confere se o pacote foi criado por um processo com o
PID especificado.
• --sid-owner ID - Confere se o pacote foi criado por um processo no grupo
de seção especificado.
OBS: - Lembre-se que pacotes que não possuem detalhes suficientes de
cabeçalho nunca conferirão!

iptables -A OUTPUT -m owner --gid-owner 100 -p udp -j DROP

Rejeita um conexões indo para portas UDP de pacotes criados pelo

usuários pertencentes ao grupo 100.

6.7 Caminho percorrido pelos pacotes nas tabelas e chains

É MUITO importante entender a função de cada filtro e a ordem de acesso
dos chains de acordo com o tipo de conexão e interface de origem/destino. Esta
seção explica a ordem que as regra são atravessadas, isso lhe permitirá planejar a
distribuição das regras nos chains, e evitar erros de localização de regras que
poderia deixar seu firewall com sérios problemas de segurança, ou um sistema de
firewall totalmente confuso e sem lógica.
Nos exemplos abaixo assumirei a seguinte configuração:
• A máquina do firewall com iptables possui o endereço IP 192.168.1.1 e
conecta a rede interna ligada via interface eth0 a internet via a interface
ppp0.
• Rede interna com a faixa de endereços 192.168.1.0 conectada ao firewall
via interface eth0
• Interface ppp0 fazendo conexão com a Internet com o endereço IP
200.217.29.67.
• A conexão das máquinas da rede interna (eth0) com a rede externa (ppp0)
é feita via Masquerading.
Também utilizarei a sintaxe CHAIN-tabela para fazer referência aos chains
e tabelas dos blocos ASCII: INPUT-filter - chain INPUT da tabela filter.
ATENÇÃO: A ordem de processamento das regras do iptables, é diferente
do ipchains devido a inclusão do novo sistema de nat e da tabela mangle.

6.7.1 ping de 192.168.1.1 para 192.168.1.1

• Endereço de Origem: 192.168.1.1
• Endereço de Destino: 192.168.1.1
• Interface de Entrada: lo
• Interface de Saída: lo
• Protocolo: ICMP
• Descrição: Ping para o próprio firewall
SAÍDA DE PACOTES (envio do ping para 192.168.1.1):
+-------------+ +----------+ +-------------+ +----------------+
|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => |POSTROUTING-nat |
+-------------+ +----------+ +-------------+ +----------------+
 ENTRADA DOS PACOTES (Retorno da resposta ping acima):
+-----------------+ +------------+
|PREROUTING-mangle| => |INPUT-filter|
+-----------------+ +------------+
Quando damos o ping (echo request) os pacotes seguem o caminho em
SAÍDA DE PACOTES percorrendo os chains na ordem especificada e retornam
via ENTRADA DOS PACOTES (echo reply).
OBS1: Para conexões com destinos na própria máquina usando um
endereço IP das interfaces locais, a interface será ajustada sempre para lo
(loopback).
OBS2: Em qualquer operação de entrada/saída de pacotes, os dois chains
da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário
para definir a prioridade e controlar outros aspectos especiais dos pacotes que
atravessam os filtros.
OBS3: O chain OUTPUT da tabela filter é consultado sempre quando
existem conexões se originando em endereços de interfaces locais.

6.7.2 Conexão FTP de 192.168.1.1 para 192.168.1.1

• Endereço de Origem: 192.168.1.1
• Endereço de Destino: 192.168.1.1
• Interface de Origem: lo
• Interface de Destino: lo
• Porta Origem: 1404
• Porta Destino: 21
• Protocolo: TCP
• Descrição: Conexão ftp (até o prompt de login, sem transferência de
arquivos).
SAÍDA DOS PACOTES (envio da requisição para 192.168.1.1):
+-------------+ +----------+ +-------------+ +---------------+
|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => |POSTROUTING-nat|
+-------------+ +----------+ +-------------+ +---------------+

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

+-----------------+ +------------+
|PREROUTING-mangle| => |INPUT-filter|
+-----------------+ +------------+
A requisição ftp passa através dos chains especificados em SAÍDA DOS
PACOTES e retorna por ENTRADA DE PACOTES. Após a conexão ser
estabelecida, o caminho de SAÍDA DE PACOTES será:
 +-------------+ +-------------+
|OUTPUT-mangle| => |OUTPUT-filter|
+-------------+ +-------------+
pois os dados de entrada que vem da interface externa, são passados
diretamente a máquina do firewall, não necessitando de tratamento SNAT (os
chains OUTPUT-nat e POSTROUTING-nat são processado somente uma vez a
procura de regras que conferem, principalmente para fazer SNAT).
OBS1: Para conexões com destinos na própria máquina usando um
endereço IP das interfaces locais, a interface será ajustada sempre para lo
(loopback).
OBS2: Em qualquer operação de entrada/saída de pacotes, os dois chains
da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário
para definir a prioridade e controlar outros aspectos especiais dos pacotes que
atravessam os filtros.

6.7.3 Conexão FTP de 192.168.1.1 para 192.168.1.4

• Endereço de Origem: 192.168.1.1
• Endereço de Destino: 192.168.1.4
• Interface de Origem: eth0
• Interface de Destino: eth0
• Porta Origem: 1405
• Porta Destino: 21
• Protocolo: TCP
• Descrição: Conexão ftp (até o prompt de login, sem transferência de
arquivos).
SAÍDA DOS PACOTES (envio da requisição para 192.168.1.4):
+-------------+ +----------+ +-------------+ +---------------+
|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => |POSTROUTING-nat|
+-------------+ +----------+ +-------------+ +---------------+

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

+-----------------+ +------------+
|PREROUTING-mangle| => |INPUT-filter|
+-----------------+ +------------+
A requisição ftp passa através dos chains especificados em SAÍDA DOS
PACOTES com o destino 192.168.1.4 porta 21 e retorna por ENTRADA DE
PACOTES para 192.168.1.1 porta 1405. Após a conexão ser estabelecida, o
caminho de SAÍDA DE PACOTES será:
+-------------+ +-------------+
 |OUTPUT-mangle| => |OUTPUT-filter|
+-------------+ +-------------+
pois os dados não precisam de tratamento SNAT (os chains OUTPUT-nat e
POSTROUTING-nat são processado somente uma vez a procura de regras que
conferem, principalmente para fazer SNAT).
OBS: Em qualquer operação de entrada/saída de pacotes, os dois chains
da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário
para definir a prioridade e controlar outros aspectos especiais dos pacotes que
atravessam os filtros.

6.7.4 Conexão FTP de 200.217.29.67 para ftp.debian.org.br

• Endereço de Origem: 200.217.29.67
• Endereço de Destino: 200.198.129.162
• Interface de Origem: ppp0
• Interface de Destino: ppp0
• Porta Origem: 1407
• Porta Destino: 21
• Protocolo: TCP
• Descrição: Conexão ftp (até o prompt de login, sem transferência de
arquivos).
SAÍDA DOS PACOTES (envio da requisição para 200.198.129.162):
+-------------+ +----------+ +-------------+ +---------------+
|OUTPUT-mangle| => |OUTPUT-nat| => |OUTPUT-filter| => |POSTROUTING-nat|
+-------------+ +----------+ +-------------+ +---------------+

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

+-----------------+ +--------------+ +------------+
|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-filter|
+-----------------+ +--------------+ +------------+
A requisição ftp passa através dos chains especificados em SAÍDA DOS
PACOTES com o destino 200.198.129.162 porta 21 (após a resolução DNS de
www.debian.org.br) e retorna por ENTRADA DE PACOTES para 200.217.29.67
porta 1407. Após a conexão ser estabelecida, o caminho de saída de pacotes é:
+-------------+ +-------------+
|OUTPUT-mangle| => |OUTPUT-filter|
+-------------+ +-------------+
pois os dados não precisam de tratamento SNAT (os chains OUTPUT-nat e
POSTROUTING-nat são processado somente uma vez a procura de regras que
conferem, principalmente para fazer SNAT).
 E após a conexão estabelecida, o caminho de entrada de pacotes passa a
ser:
+-----------------+ +-------------+
|PREROUTING-mangle| => |INPUT-filter |
+-----------------+ +-------------+
pois os dados não precisam de tratamento DNAT (o chain PREROUTING-
nat é processado somente uma vez a procura de regras que conferem,
principalmente para fazer DNAT).
OBS: Para qualquer operação de entrada/saída de pacotes, os dois chains
da tabela mangle são sempre os primeiros a serem acessados. Isto é necessário
para definir a prioridade e controlar outros aspectos especiais dos pacotes que
atravessam os filtros.

6.7.5 Ping de 192.168.1.4 para 192.168.1.1

• Endereço de Origem: 192.168.1.4
• Endereço de Destino: 192.168.1.1
• Interface de Entrada: eth0
• Interface de Saída: eth0
• Protocolo: ICMP
• Descrição: Ping de 192.168.1.4 para a máquina do firewall.
ENTRADA DE PACOTES (recebimento da requisição, vinda de 192.168.1.4):
+-----------------+ +--------------+ +------------+
|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-filter|
+-----------------+ +--------------+ +------------+

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

+-------------+ +-------------+
|OUTPUT-mangle| => |OUTPUT-filter|
+-------------+ +-------------+
Quando damos o ping (echo request) os pacotes seguem o caminho em
ENTRADA DE PACOTES percorrendo os chains na ordem especificada e
retornam via SAÍDA DOS PACOTES (echo reply).
OBS1: Para qualquer operação de entrada/saída de pacotes, os dois
chains da tabela mangle são sempre os primeiros a serem acessados. Isto é
necessário para definir a prioridade e controlar outros aspectos especiais dos
pacotes que atravessam os filtros.

6.7.6 Conexão FTP de 192.168.1.4 para 192.168.1.1

• Endereço de Origem: 192.168.1.4
 • Endereço de Destino: 192.168.1.1
• Interface de Origem: eth0
• Interface de Destino: eth0
• Porta Origem: 1030
• Porta Destino: 21
• Protocolo: TCP
• Descrição: Conexão ftp (até o prompt de login, sem transferência de
dados).
ENTRADA DOS PACOTES (envio da requisição vindas de 192.168.1.4):
+-----------------+ +--------------+ +------------+
|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-filter|
+-----------------+ +--------------+ +------------+

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

+-------------+ +-------------+
|OUTPUT-mangle| => |OUTPUT-filter|
+-------------+ +-------------+
A requisição ftp passa através dos chains especificados em ENTRADA
DOS PACOTES com o destino 192.168.1.1 porta 21 e retorna por SAÍDA DE
PACOTES para 192.168.1.4 porta 1030. Após a conexão ser estabelecida, o
caminho de entrada de pacotes é:
+-----------------+ +------------+
|PREROUTING-mangle| => |INPUT-filter|
+-----------------+ +------------+
pois os dados não precisam de tratamento DNAT (o chain PREROUTING-
nat é processado somente uma vez a procura de regras que conferem,
principalmente para fazer DNAT).
OBS: O roteamento é sempre realizado após o processamento do chain
PREROUTING da tabela nat.

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

• Endereço de Origem: 192.168.1.4
• Endereço de Destino: 200.198.129.162
• Interface de Origem: eth0
• Interface de Destino: ppp0
• Porta Origem: 1032
 • Porta Destino: 21
• Protocolo: TCP
• Descrição: Conexão ftp (até o prompt de login, sem transferência de
dados).
SAÍDA DOS PACOTES (requisição vindas de 192.168.1.4):
+-----------------+ +--------------+ +--------------+ +---------------+
|PREROUTING-mangle| => |PREROUTING-nat| => |FORWARD-filter| => |POSTROUTING-nat|
+-----------------+ +--------------+ +--------------+ +---------------+

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

+-----------------+ +--------------+
|PREROUTING-mangle| => |FORWARD-filter|
+-----------------+ +--------------+
A requisição ftp passa através dos chains especificados em SAÍDA DOS
PACOTES com o destino 200.198.129.162 porta 21 (após a resolução DNS de
ftp.debian.org.br) e retorna por ENTRADA DE PACOTES para 192.168.1.4 porta
1032.
Note que o Masquerading regrava os pacotes; para a máquina
200.198.129.162 a conexão está sendo feita para 200.217.29.67. As respostas de
conexões vindas de 200.198.129.162 e indo para 200.217.29.67 são regravadas
no firewall com o destino 192.168.1.4 e enviadas para a máquina correspondente.
Após a conexão ser estabelecida, o caminho de saída de pacotes é:
+-----------------+ +--------------+
|PREROUTING-mangle| => |FORWARD-filter|
+-----------------+ +--------------+
Isto acontece porque após feita a conexão Masquerading (via
PREROUTING-nat), o firewall já sabe como reescrever os pacotes para realizar a
operação de Masquerading, reescrevendo todos os pacotes que chegam de
www.debian.org.br para 192.168.1.4.
OBS: As conexões Masquerading feitas através da rede interna, são
enviadas para 200.198.129.162 tem o endereço de origem ajustado para
200.217.29.67 que é o IP de nossa interface ppp0. Quando as respostas
atravessam o firewall, os pacotes são checados pra saber se são uma resposta a
uma conexão masquerading e fará a regravação dos pacotes substituindo o
endereço de destino para 192.168.1.4. Caso uma operação de Masquerading
falhe, os pacotes serão Bloqueados.

6.7.8 Conexão FTP de 200.198.129.162 para 200.217.29.167

• Endereço de Origem: 200.198.129.162
• Endereço de Destino: 200.217.29.67
• Interface de Origem: ppp0
• Interface de Destino: ppp0
 • Porta Origem: 3716
• Porta Destino: 21
• Protocolo: TCP
• Descrição: Conexão ao serviço ftp do firewall
ENTRADA DOS PACOTES (envio da requisição vindas de 200.198.129.162):
+-----------------+ +--------------+ +------------+
|PREROUTING-mangle| => |PREROUTING-nat| => |INPUT-filter|
+-----------------+ +--------------+ +------------+

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

+-------------+ +-------------+
|OUTPUT-mangle| => |OUTPUT-filter|
+-------------+ +-------------+
A requisição ftp passa através dos chains especificados em ENTRADA
DOS PACOTES com o destino 200.217.29.67 (nossa interface ppp0 local) porta
21 e retorna por SAÍDA DE PACOTES para 200.198.129.162 porta 3716 (também
via ppp0). Após a conexão ser estabelecida, o caminho de entrada de pacotes é:
+-----------------+ +------------+
|PREROUTING-mangle| => |INPUT-filter|
+-----------------+ +------------+
Isto acontece porque após feita a análise do chain PREROUTING (para
necessidade de DNAT), a máquina já saberá tomar a decisão apropriada para
gerenciar aquela conexão.

6.7.9 Gráfico geral da passagem dos pacotes

Este gráfico foi retirado do documento netfilter-hacking-HOWTO.txt e
mostra a estrutura geral de passagem dos pacotes nas tabelas/chains. Os
exemplos de passagem de pacotes acima poderão ser facilmente comparados
com as etapas abaixo para compreender a estrutura do iptables.
E ---> PREROUTING ------> (ROTEAM.) ---> FORWARD ----------> POSTROUTING --> S
Mangle e | Filter ^ NAT (Src)
NAT (DNAT)) | |
| (ROTEAM.)
V |
IN Filter OUT - Mangle,
| ^ NAT (DNAT)
| | Filter
V |
+----------------------------------------+
| Processo Local |
+----------------------------------------+
6.8 Exemplos de configurações do iptables
Em construção. Exemplo de como bloquear todas as conexões para a
máquina do firewall permitindo somente conexões da máquina Linux para fora.

6.8.1 Bloqueando conexões de fora para sua máquina

As regras a seguir servem para bloquear tentativas de conexões da
interface de Internet (ppp0) a sua rede sem bloquear o tráfego de conexões já
iniciadas. O tráfego de outras interfaces não é afetado com as regras a seguir:

iptables -A INPUT -i ppp0 -m state --state ! ESTABLISHED,RELATED -j DROP

Todas as conexões vindas de ppp0 de estado diferente de ESTABLISHED

e RELATED (NEW e INVALID) serão derrubadas. Veja “6.6.1 Conferindo de
acordo com o estado da conexão” para detalhes.

iptables -A INPUT -i ppp0 --syn -j DROP

Este acima é mais simples e possui o mesmo efeito: Pacotes SYN são
usados para iniciar conexões, derrubando pacotes deste tipo significa bloquear
novas conexões. Pacotes de conexões já estabelecidas ainda são permitidos.
Estas regras acima servem para quem não deseja NENHUM acesso
indevido a sua máquina. Existem outras formas de bloquear conexões de modo
mais seletivo usando chains específicos, endereços de origem/destino, portas,
etc., este tipo de configuração é muito usada caso precise fornecer algum tipo de
serviço que seja acessível externamente e protegendo outros.

6.8.2 Monitorando tentativa de conexão de trojans em sua máquina

As regras abaixo alertam sobre a tentativa de conexão dos trojans "For
Win" mais conhecidos. Coloquei isto aqui por curiosidade de algumas pessoas,
pois máquinas Linux são imunes a este tipo de coisa:

#!/bin/sh

TROJAN_PORTS="12345 31336 31337 31338 3024 4092 5714 5742 2583 8787 5556 5557"

iptables -t filter -N trojans-in

for PORTA in ${TROJAN_PORTS};do

iptables -A trojans-in -p tcp --sport=1024: --dport=${PORTA} -j LOG \
--log-prefix "FIREWALL: Trojan ${PORTA} "
iptables -A trojans-in -p tcp --sport=1024: --dport=${PORTA} -j DROP
done
iptables -t filter -A INPUT -i ppp0 -j trojans-in

A primeira linha do iptables cria o chain trojans-in dentro da tabela filter que
usaremos para armazenar nossas regras de firewall. A segunda (dentro do laço
for) faz uma regra de LOG para registrar as tentativas de acesso de trojans em
nosso sistema, a terceira rejeita o acesso. A quarta regra do iptables cria de todo
o tráfego vindo da interface ppp0 pra o chain trojans-in (queremos que só o tráfego
vindo da internet seja analisado pelo chain trojans-in).
Muitas das portas especificadas na variável TROJAN_PORTS são antigas
conhecidas de quem já brincou ou sofreram com o Back Orifice, Win Crack,
NetBus (quem nunca passou pela fase de ter uma lista com mais de 100 netmasks
e conseguir encontrar centenas de máquinas por dia infectadas pelo BO? :-).
No código acima a única coisa que precisa fazer para adicionar mais portas
é inseri-las na variável TROJAN_PORTS e executar o programa. O laço do for
executará as 2 regras para cada porta processada (economizando linhas e linhas
de regras, me livrando de uma LER e poupando muitos bytes neste guia ;-).
Dependendo do número de portas alvo, este código pode ser muito
simplificado usando o recurso multiport do iptables (veja “6.6.6 Especificando
múltiplas portas de origem/destino” para detalhes).

6.8.3 Conectando sua rede interna a Internet

O seguinte exemplo permite ligar sua rede interna com a faixa de IP's
192.168.1.* a internet (usando uma conexão discada do tipo ppp):

iptables -A nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -j MASQUERADE

echo "1" >/proc/sys/net/ipv4/ip_forward

6.8.4 Um exemplo de firewall simples

Esta seção possui um exemplo mais elaborado de firewall que servirá para
máquinas conectadas via ppp com uma rede interna conectada via Masquerading.
Este exemplo não é tão complexo e cobre as expectativas mais comuns de
pessoas que gostam de explorar os potenciais de rede no Linux ou satisfazer sua
curiosidade. Ele poderá ser facilmente adaptado para atender outro tipo de
necessidade. A configuração assumida é a seguinte:
1. Máquina do firewall com 2 interfaces de rede, uma é eth0 com o IP
192.168.1.1 que serve de ligação a sua rede Interna, a outra é ppp0 que é a
interface Internet.
2. Qualquer acesso externo a máquinas da rede interna é bloqueado.
3. Os usuários da rede local tem acesso livre ao servidor Linux.
4. Qualquer acesso externo a máquina do firewall é bloqueado, exceto
conexões para o serviço Apache (httpd). Outras tentativas de conexões
 devem ser explicitamente registradas nos logs do sistema para
conhecimento do administrador.
5. Todos os usuários possuem acesso livre a Internet via Masquerading,
exceto que o acesso para o serviço www deve ser obrigatoriamente feito via
squid, e o servidor smtp a ser usado deverá ser o do firewall Linux.
6. Prioridades serão estabelecidas para os serviços de telnet, IRC,talk e DNS.

#!/bin/sh
# Modelo de configuração de firewall
# Autor: Gleydson M. Silva
# Data: 05/09/2001
# Descrição: Produzido para ser distribuído livremente, acompanha o guia
# Foca GNU/Linux. http://focalinux.cipsga.org.br
#

# É assumido um sistema usando kmod para carga automática dos módulos usados por
# esta configuração do firewall:
# ipt_filter
# ipt_nat
# ipt_conntrack
# ipt_mangle
# ipt_TOS
# ipt_MASQUERADE
# ipt_LOG

# Se você tem um kernel modularizado que não utiliza o kmod, será necessário
# carregar estes módulos via modprobe, insmod ou iptables --modprobe=modulo

##### Definição de Políticas #####

# Tabela filter
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD DROP
# Tabela nat
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t nat -P POSTROUTING DROP
# Tabela mangle
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

##### Proteção contra IP Spoofing #####

for i in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 >$i
done

##### Ativamos o redirecionamento de pacotes (requerido para NAT) #####

echo "1" >/proc/sys/net/ipv4/ip_forward

# O iptables define automaticamente o número máximo de conexões simultâneas

# com base na memória do sistema. Para 32MB = 2048, 64MB = 4096, 128MB = 8192,
# sendo que são usados 350 bytes de memória residente para controlar
# cada conexão.
# Quando este limite é excedido a seguinte mensagem é mostrada:
# "ip_conntrack: maximum limit of XXX entries exceed"
#
# Como temos uma rede simples, vamos abaixar este limite. Por outro lado isto
# criará uma certa limitação de tráfego para evitar a sobrecarga do servidor.
echo "2048" > /proc/sys/net/ipv4/ip_conntrack_max

###############################################################
# Tabela filter #
###############################################################

##### Chain INPUT #####

# Criamos um chain que será usado para tratar o tráfego vindo da Internet e
iptables -N ppp-input

# Aceita todo o tráfego vindo do loopback e indo pro loopback

iptables -A INPUT -i lo -j ACCEPT
# Todo tráfego vindo da rede interna também é aceito
iptables -A INPUT -s 192.168.1.0/24 -i eth0 -j ACCEPT

# Conexões vindas da interface ppp0 são tratadas pelo chain ppp-input

iptables -A INPUT -i ppp+ -j ppp-input

# Qualquer outra conexão desconhecida é imediatamente registrada e derrubada

iptables -A INPUT -j LOG --log-prefix "FIREWALL: INPUT "
iptables -A INPUT -j DROP

##### Chain FORWARD ####

# Permite redirecionamento de conexões entre as interfaces locais
# especificadas abaixo. Qualquer tráfego vindo/indo para outras
# interfaces será bloqueado neste passo
iptables -A FORWARD -d 192.168.1.0/24 -i ppp+ -o eth0 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -o ppp+ -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "FIREWALL: FORWARD "
iptables -A FORWARD -j DROP

##### Chain ppp-input ####

# Aceitamos todas as mensagens icmp vindas de ppp0 com certa limitação
iptables -A ppp-input -p icmp -m limit --limit 2/s -j ACCEPT

# Primeiro aceitamos o tráfego vindo da Internet para o serviço www (porta 80)
iptables -A ppp-input -p tcp --dport 80 -j ACCEPT

# A tentativa de acesso externo a estes serviços serão registrados no syslog

# do sistema e serão bloqueados pela última regra abaixo.
iptables -A ppp-input -p tcp --dport 21 -j LOG --log-prefix "FIREWALL: ftp "
iptables -A ppp-input -p tcp --dport 25 -j LOG --log-prefix "FIREWALL: smtp "
iptables -A ppp-input -p udp --dport 53 -j LOG --log-prefix "FIREWALL: dns "
iptables -A ppp-input -p tcp --dport 110 -j LOG --log-prefix "FIREWALL: pop3 "
iptables -A ppp-input -p tcp --dport 113 -j LOG --log-prefix "FIREWALL: identd "
iptables -A ppp-input -p udp --dport 111 -j LOG --log-prefix "FIREWALL: rpc"
iptables -A ppp-input -p tcp --dport 111 -j LOG --log-prefix "FIREWALL: rpc"
iptables -A ppp-input -p tcp --dport 137:139 -j LOG --log-prefix "FIREWALL: samba "
iptables -A ppp-input -p udp --dport 137:139 -j LOG --log-prefix "FIREWALL: samba "
# Bloqueia qualquer tentativa de nova conexão de fora para esta máquina
iptables -A ppp-input -m state --state ! ESTABLISHED,RELATED -j LOG --log-prefix
"FIREWALL: ppp-in "
iptables -A ppp-input -m state --state ! ESTABLISHED,RELATED -j DROP
# Qualquer outro tipo de tráfego é aceito
iptables -A ppp-input -j ACCEPT

#######################################################
# Tabela nat #
#######################################################

##### Chain POSTROUTING #####

# Permite qualquer conexão vinda com destino a lo e rede local para eth0
iptables -t nat -A POSTROUTING -o lo -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j ACCEPT

# Não queremos que usuários tenham acesso direto a www e smtp da rede externa, o
# squid e smtpd do firewall devem ser obrigatoriamente usados. Também registramos
# as tentativas para monitorarmos qual máquina está tentando conectar-se
diretamente.
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -p tcp --dport 80 -j LOG --
log-prefix "FIREWALL: SNAT-www "
iptables -t nat -A POSTROUTING -s
log-prefix "FIREWALL: SNAT-smtp "
iptables -t nat -A POSTROUTING -s
iptables -t nat -A POSTROUTING -s
# É feito masquerading dos outros
# ppp0
iptables -t nat -A POSTROUTING -s
192.168.1.0/24 -o ppp+ -p tcp --dport 25 -j LOG --
192.168.1.0/24 -o ppp+ -p tcp --dport 25 -j DROP
192.168.1.0/24 -o ppp+ -p tcp --dport 80 -j DROP
serviços da rede interna indo para a interface
192.168.1.0/24 -o ppp+ -j MASQUERADE

# Qualquer outra origem de tráfego desconhecida indo para eth0 (conexões vindas
# de ppp+) são bloqueadas aqui
iptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.0/24 -j LOG --log-prefix
"FIREWALL: SNAT unknown"
iptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.0/24 -j DROP
# Quando iniciamos uma conexão ppp, obtermos um endereço classe A (10.x.x.x) e após
# estabelecida a conexão real, este endereço é modificado. O tráfego indo para
# a interface ppp não deverá ser bloqueado. Os bloqueios serão feitos no
# chain INPUT da tabela filter
iptables -t nat -A POSTROUTING -o ppp+ -j ACCEPT

# Registra e bloqueia qualquer outro tipo de tráfego desconhecido

iptables -t nat -A POSTROUTING -j LOG --log-prefix "FIREWALL: SNAT "
iptables -t nat -A POSTROUTING -j DROP

###############################################
# Tabela mangle #
###############################################

##### Chain OUTPUT #####

# Define mínimo de espera para os serviços ftp, telnet, irc e DNS, isto
# dará uma melhor sensação de conexão em tempo real e diminuirá o tempo
# de espera para conexões que requerem resolução de nomes.
iptables -t mangle -A OUTPUT -o ppp+ -p tcp --dport 21 -j TOS --set-tos 0x10
iptables -t mangle -A OUTPUT -o ppp+ -p tcp --dport 23 -j TOS --set-tos 0x10
iptables -t mangle -A OUTPUT -o ppp+ -p tcp --dport 6665:6668 -j TOS --set-tos 0x10
iptables -t mangle -A OUTPUT -o ppp+ -p udp --dport 53 -j TOS --set-tos 0x10
7 O PROXY SQUID
Adaptado de “O Squidnomicon”, por <arfreitas@ig.com.br
<mailto:arfreitas@ig.com.br>>,Versão 1.21
<http://www.alceujun.hpg.ig.com.br/linux/squidnomicon.html>

O Squid é amplamente utilizado como servidor cache e servidor de proxy

transparente http.
O Squid como PROXY HTTP é aberto uma porta em TCP, onde o cliente irá
configurar o seu navegador para requisitar pacotes da máquina servidora. O Proxy
http está configurado com algumas proteções de segurança de acesso à páginas.
Algumas páginas serão bloqueadas por conterem em seu link palavras que estão
catalogadas no arquivo blacklist. As páginas que o administrador quiser liberar o
acesso basta colocar a palavra no arquivo whitelist.
O Squid como CACHE é utilizado para armazenar conteúdos de páginas
para que os clientes da rede interna não precisem buscar os dados na internet,
mas primeiro vão buscar as páginas no servidor cache. O Squid faz uma
verificação do conteúdo do cache com o conteúdo da página real e executa uma
atualização automática.

7.1 Introdução
Resolvi escrever esse manual principalmente porque ninguém o havia feito
antes. Dentre todos os inúmeros documentos sobre Linux e software livre em
<http://www.linuxdoc.org> não há nenhum que fale sobre Squid, mesmo em
inglês, quem diria em português.
Você poderá encontrar maiores informações sobre o Squid no seu website
(<http://www.squid-cache.org>) e ainda poderá recorrer a FAQS e a lista de
discussão para dúvidas.
Squidnomicon significa manual do Squid. Eu achei divertido fazer uma
relação com o Necronomicon (Livro dos Mortos). Mas não espere encontrar
nenhuma outra semelhança além desta. Talvez eu use um desenho do grande
Cthullu como logo do manual, mas tenho receio dos direitos autorais.
Este manual é livre e está sobre a licença Free GNU Documentation.
Qualquer ajuda (dicas, comentários) e/ou modificações são muito bem-vindas.

7.2 Requisitos básicos

Você terá que ter:
• um UNIX: o tutorial tem seu foque em Linux, mas com algum esforço
 você pode utilizar o mesmo tutorial em FreeBSD, SUN Solaris, etc.;
• o pacote/fonte do Squid;
• um computador: para testes qualquer um serve, mas para entrar em
operação você terá que ter pelo menos um Pentium 2 com 128MB e um
HD de 4 Gb. Isto é aproximado, e pode variar muito conforme o número
de usuários X requisições. Basta saber que os requisitos de hardware
de um servidor proxy são muito maiores em relação à quantidade de
memória e velocidade do disco do que para um firewall, principalmente
devido ao cache; velocidade de processamento também influirá na
performance do proxy.
• conhecimento básico sobre protocolo TCP-IP e Internet;
• conhecer o UNIX no qual você quer instalar o Squid!

7.3 O feijão com arroz

O Squid é um webproxy que suporta proxying para DNS e FTP, alem do
tradicional HTTP. Ele permite também a criação de árvores de cache via HTCP,
load balance para servidores HTTP (vide http_accelerator) e diversos modos de
autentificação de usuário, o que também inclui a possibilidade de criação de listas
de sites e/ou palavras proibidas para acesso.
Neste capitulo irei mostrar apenas o básico para você ter o Squid rodando.
Com essas configurações, você irá ter o Squid como proxy e efetuando cache das
páginas visitadas.

7.3.1 Instalação
A instalação poderá depender de qual distribuição você estiver usando.
Normalmente você encontrara o Squid nos CDROM de distribuição em formatos
RPM, DEB ou TGZ. Você também pode usar o fonte do Squid e compilar os
binários usando somente as funções que você precisar.
Para distribuições que trabalham com pacotes a instalação é muito simples:
rpm -ivh squid-versao.rpm (para distribuições baseadas em RPM)
ou
apt-get install squid (para o Debian)
O Conectiva (versão 6 e posteriores) também podem usar as mesmas
facilidades do apt-get.
Para instalar a partir do fonte, faca o download do Squid em
<http://www.squid-cache.org> na seção de downloads. Depois execute:
tar -xzvf squid-versao.tar.gz <http://squid-versao.tar.gz>/
cd /diretorio_criado
./configure
make
make install
Ler o arquivo README que acompanha o arquivo fonte também e
essencial para obter os detalhes.
A versão termina em números pares (para versões estáveis) e impares (para
versões de teste) então escolha a ultima de acordo com seus interesses. Procure
sempre pelos arquivos com o RELEASE incluso.

7.3.2 Configuração
Depois de instalado você provavelmente (espero!) terá os binários e
arquivos de configuração, muitos deles comentados e precedidos de comentários
sobre as funções que exercem. O arquivo de configuração do Squid fica em
/etc/squid.conf. Inicialmente você deve configurar apenas 3 parâmetros para que
tenha o Squid ao menos respondendo a requisições e criando cache das páginas
requisitadas:
http_port 3128
cache_mem 8Mb
http_access allow all
Com exceção do ultimo parâmetro (que deve ser inserido) esses
parâmetros estão apenas comentados (com um sinal "#"). Depois disso você pode
iniciar o Squid usando o script de inicialização que fica dentro do diretório
/etc/rc.d/init.d (ou /etc/init.d para o Debian):
# cd /etc/rc.d/init.d
#./squid start
Na maioria das distribuições o cache é criado quando o Squid é iniciado
pela primeira vez (pelo menos para sistemas Linux). Você ainda pode forçar a
criação de cache digitando:
# squid -z
Ainda é possível fazer com que o Squid interprete novos parâmetros no
arquivo de configuração sem interromper os processos atuais:
# squid -k reconfigure
O Squid já está rodando e aceitando conexões. Agora vamos explicar
melhor os parâmetros utilizados:
• http_port 3128: Este parâmetro indica em que porta o Squid estará
aceitando requisições de páginas Web. Várias portas diferentes podem
ser listadas simultaneamente, desde que estejam livres.
• cache_mem 8Mb: Este parâmetro especifica a quantidade ideal de
memória a ser usada pelo Squid, mas isso não significa um limite. O
Squid irá ultrapassar o valor estipulado se assim for necessário.
• http_access allow all: Inicialmente o Squid estará recusando o
serviço de proxy para qualquer requisição que não tenha sido feita a
partir do localhost (127.0.0.1). Essa diretriz, pelo contrário, esta
 permitindo que qualquer um requisite qualquer página.
O Squid permite uma grande flexibilidade sobre o que é permitido ou não
que o cliente requisite (conforme você poderá acompanhar mais à frente).
Agora você pode fazer um teste com um navegador qualquer, como o Netscape
ou o Internet Explorer. Para isso, configure (na parte referente a servidor proxy) o
endereço IP do proxy Squid sem esquecer de indicar a porta 3128.
As solicitações agora serão atendidas pelo Squid, que irá fazer cache das
requisições, como páginas html e figuras, o que aumenta consideravelmente a
rapidez de navegação e diminui a ocupação de banda do link.

7.4 Controlando os usuários

Usuários costumam dar dores de cabeça horríveis a um administrador de
redes, mas também sem eles como você justificaria seu salário?
O Squid fornece meios de evitar que você tenha (muitos) problemas com
seus usuários acessando a Internet para fins não muito ortodoxos. Você pode
bloquear acesso a algum tipo de recurso ou a um site inteiro.
No arquivo /etc/squid.conf existem definições de listas de controle
(ACL em inglês) e como é feito o acesso a recursos definidos
nestas listas.
Antes de mostrar como a lista é feita, procure ter antes em mente a
seguinte idéia:
1 - As regras são interpretadas na ordem que aparecem: quando você
define regras, a primeira é interpretada. Se a regra descrita
não combinar com a requisição a mesma será comparada com a próxima regra, e
assim por diante.
2 - Sempre, SEMPRE coloque como última regra uma ACL que bloqueie
tudo. Se você não fizer isso, seu controle vai para o espaço.
3 - Não crie regras demais e desnecessárias! Procure evitar redundâncias e
regras de controle que exijam resolução de nomes. Isso pode atrasar muita a
resposta do Squid para requisições.
Existem diversos critérios/tipos de listas. Acompanhe abaixo:
• SCR A lista é baseada no endereço IP do cliente (requisitante).
• DST A lista é baseada no endereço IP do servidor (que será
requisitado).
• SCRDOMAIN O domínio da máquina cliente. O domínio serão obtido
por resolução reversa de IP o que pode causar atrasos para a requisição
ter resposta.
• DSTDOMAIN Método de controle sobre um domínio especifico.
 • SRCDOM_REGEX Expressão regular que e avaliada para tentar
marcar um domínio requisitante; esse parâmetro pode causar atrasos
por usar resolução reversa de endereço IP.
• DSTDOM_REGEX O mesmo que srcdom_regex só que para o
domínio de destino.
• TIME Dia da semana e hora da semana.
• URL_REGEX Essa ACL irá procura em na URL uma expressa regular
que você especificar.
• URLPATH_REGEX Semelhante ao url_regex só que ira procurar a
expressão na url toda exceto no nome do protocolo e domínio. Isso ira
tentar combinar com o nome do diretório ao longo da url.
• PORT O acesso pode ser controlado pela porta do endereço do
servidor requisitado.
• PROTO Especifica o protocolo de transferência.
• METHOD Especifica o tipo de método da requisição.
• BROWSER expressão regular cujo padrão tentara combinar com o
contido no cabeçário HTTP de requisição do cliente.
• IDENT Seqüência de caracteres que combinam com o nome do
usuário. Requer um servidor Ident rodando na máquina do cliente.
• IDENT_REGEX O mesmo que ident, mas utilizando-se de uma
expressão regular.
• PROXY_AUTH Permite a autentificação de usuários através do envio
de usuário/senha. Requer um programa externo para realizar essa
autentificação.
• PROXY_AUTH_REGEX O mesmo que proxy_auth, só que ira
tentar combinar o nome do usuário fornecido pelo programa de
autentificação através de uma expressão regular.
• SNMP_COMMUNITY Seqüência de caracteres que tentarão combinar
com o nome da comunidade SNMP.
• REQ_MIME_TYPE Expressão regular que tentara combinar com o
tipo de conteúdo contido no cabeçário de requisição.
• ARP Tenta combinar o MAC ADDRESS.
Como você pode ter notado, existe uma quantidade bem grande de
facilidades com as quais você pode construir uma ACL, ate mais do que você
provavelmente ira precisar (eu me pergunto se alguém usa ident).
Depois de definir as listas de controle você precisa definir para cada linha
da acl o que ela poderá ter como permitido (ou negado). A lista de regras já é um
pouco menor.
 HTTP_ACCESS
sintaxe: http_access allow | deny [!] acl descrição: permite ou nega acesso ao
serviço http baseado na lista de acesso (acl) definida. O uso de "!" indica inversão
(diferente de).
Eu coloquei uma observação um pouco acima de que você sempre tem de
ter como última regra uma regra de bloqueie tudo, a fim de evitar brechas no
conjunto de acl's que você tenha criado. Você pode usar o http_access para
bloquear acesso a http dessa forma:
acl all src 0.0.0.0/0 http_access deny all
Isso diz ao Squid "qualquer requisitante". No final das contas, se um
requisitante não tiver seu pedido encaixado em alguma acl anterior, ele terá seu
pedido negado.
• ICP_ACCESS
sintaxe: icp_access allow | deny [!] acl descrição: use para forçar seus
vizinhos a usarem você como um <sibling> ao invés de pai. Isso e
utilizado quando se trabalha com arvores de cache.
• MISS_ACCESS
sintaxe: miss_access allow | deny [!] acl descrição: limita os domínios
que podem fazer requisições ao cache do servidor utilizando os recursos
acl.
• PROXY_AUTH_REALM
sintaxe: proxy_auth_realm seqüência de caracteres descrição: na
realidade esse comando não exerce nenhum tipo de controle, apenas
informa ao cliente (através da seqüência de caracteres) aonde ele esta
realizando o logon. Não é essencial, mas o padrão aparece como "Squid
proxy"? e você pode mudar isso sem problemas.
• IDENT_LOOKUP_ACCESS
sintaxe: ident_lookup_access allow | deny acl descrição: se a acl
combinar com a requisição do cliente, este cliente será autentificado por
uma procura ident.

7.5 Exemplos de configuração

Agora que todos os itens foram discutidos vou mostrar alguns exemplos
práticos de configuração para controle de acesso.

7.5.1 Permitir http_access para apenas uma máquina com MAC

address igual a 00:08:c7:9f:34:41 :
acl all src 0.0.0.0
acl pl800_arp arp 00:08:c7:9f:34:41
http_access allow pl800_arp
http_access deny all

7.5.2 Para restringir acesso nas horas de trabalho (9 horas - 17 horas,

de segunda sexta) da faixa de IP 192.168.2.0 máscara
255.255.255.0 :
acl all src 0.0.0.0
acl ip_acl src 192.168.2.0/24
acl time_acl time M T W H F 9:00-17:00
http_access allow ip_acl time_acl
http_access deny all

7.5.3 Posso usar uma lista de controle com multiplos horários para
diferentes usuários?
Se você pensou em algo assim:
acl carlos src 192.168.10.1
acl davi src 192.168.10.2
acl cleusa src 192.168.10.3
acl manhã time 06:00-11:00
acl tarde time 14:00-14:30
acl noite time 16:25-23:59
http_access allow carlos manhã almoço
http_access allow davi manhã almoço
http_access allow cleusa noite
você errou !
O Squid interpreta regras desta forma:
http_access REGRA definição1 E definição 2 E definição3
OU
http_access AÇÃO definição1 E definição 2 E definição3
Atenção porque esses E e OU são operadores lógicos! Portanto a acl:
http_access allow carlos manhã almoço
nunca irá funcionar porque manhã E almoço serão sempre falsos, uma vez
que nunca serão verdadeiros na mesma hora. Como é falso (de acordo com a
lógica booleana):
0/1 E 1 = 0 (falso)
http_access allow carlos E manhã OU
http_access allow carlos almoço

7.5.4 Quero criar uma acl para bloquear sites com a palavra sexo pois
meus funcionários ficam baixando filmes em Divx de
pornografia:
acl porno url_regex sexo
http_access deny porno
 Isso tem algumas conseqüências. Primeiro que essa regra deve encabeçar
a lista para você não correr o risco de liberar o acesso antes de bloqueá-lo.
Segundo que um site <http://www.sexoesaude.com.br> estaria encaixado na lista
de bloqueio, apesar do conteúdo não ser o mesmo.

7.5.5 A idéia acima e ótima, mas eu tenho uma lista de palavras para
fazer o mesmo. Terei que repetir esse comando várias vezes?
De forma alguma:
acl porno url_regex "/etc/squid/porno.txt"
http_access deny porno
No arquivo texto, inclua uma palavra sobre a outra, como uma coluna.

7.5.6 Ainda existem sites que escapam a esse controle. Gostaria de

bloqueá-los diretamente.
acl porno2amissao dstdomain playboy.com
ou
acl porno2amissao dstdomain "/etc/squid/pornosites.txt"
http_access deny porno2

7.5.7 Meu diretor reclama que agora não consegue mais ler as
entrevistas no site da Playboy.
Chefe é chefe. Antes que ele deixe de pagar seu salário, inclua no arquivo
/etc/squid.conf :
acl entrevistas urlpath_regex entrevistas
http_access allow entrevistas
Essa regra deve vir ANTES do bloqueio do site da Playboy.

7.5.8 E uma lista de diretórios?

Insira esse conteúdo dentro de um arquivo texto:
batepapo$
batepapo/$
sexo/$
fofoca/$
chat/$
O símbolo de $ indica que a o Squid deve combinar as ocorrências quando
estas palavras aparecerem no final da URL. O símbolo é usado em expressões
regulares e pode ajudar a marcar casos bem específicos.
A essa altura você já sabe como proceder em seguida.
7.6 Recursos na Internet
O site do Squid possui muito mais documentação que esse pequeno tutorial
e é ponto obrigatório de passagem se você entende inglês: <http://www.squid-
cache.org>
Outro site interessante e o ORSO
(<http://web.onda.com.br/orso/index.html>) pois contem conteúdo interessante
sobre o Squid, incluindo o SARG, script para gerar páginas html dos arquivos de
log do Squid. No site você também encontrara listas de palavras para bloqueios de
sites pornográficos.
Você poderá encontrar versões novas desse manual no website
<http://www.imortais.cjb.net/linux/>
 APÊNDICE A. LICENÇA DE PUBLICAÇÃO LIVRE
Esta é uma tradução não-oficial da Open Publication License versão 1.0, de
8 de junho de 1999, e não é substituto legal para a Licença original, disponível em
<http://www.opencontent.org/openpub>. Entretanto, esta tradução poderá auxiliar
pessoas que falem Português a entender melhor a licença. É permitido a qualquer
pessoa copiar e distribuir cópias desse documento de licença, desde que sem a
implementação de qualquer mudança.

OPEN PUBLIC LICENSE

Draft v1.0, 8 june 1999
I. Requisitos comuns às versões modificadas e não
modificadas
Os trabalhos protegidos pela Licença de Livre Publicação (Open Publication
License) podem ser reproduzidos e distribuídos no todo ou em parte, em qualquer
meio físico ou eletrônico, desde que os termos desta licença estejam incluídos, e
que esta licença ou uma incorporação dela por referência (com quaisquer das
opções escolhidas pelo autor ou editor) estejam presentes na reprodução.
A forma apropriada para uma incorporação por referência deste livro é:

Copyright© 2002 Alfamídia Ltda. Este material somente poderá ser

distribuído se sujeito aos termos e condições firmados na Licença de
Livre Publicação (Open Publication License), versão 1.0 ou superior (a
versão mais atual encontra-se disponível em
<http://www.opencontent.org/openpub/>).

Esta referência, devidamente preenchida com os dados da publicação,

deve ser seguida imediatamente com quaisquer opções escolhidas pelos autores
ou editor do documento (consultar a seção Termos opcionais).
É permitida a redistribuição comercial de material licenciado pela Licença
de Livre Publicação (Open Publication License).
Qualquer publicação no formato livro padrão (papel) requer
obrigatoriamente a citação dos autores e editor originais. Os nomes dos autores e
do editor devem aparecer em todas as superfícies externas do livro. Em todas as
faces externas do livro, o nome do editor original deve estar impresso em tamanho
tão grande quanto o título do trabalho, e citado como proprietário em relação
àquele título.
II. Copyright
 O copyright de todo trabalho protegido pela Licença de Livre Publicação
(Open Publication License) pertence aos autores ou proprietários.
III. Escopo da licença
Os termos de licença a seguir aplicam-se a todos os trabalhos protegidos
pela Licença de Livre Publicação (Open Publication License), a não ser que
explicitamente indicado no trabalho.
A mera adição de trabalhos protegidos pela Licença de Livre Publicação
(Open Publication License) ou partes de trabalhos protegidos pela Licença de
Livre Publicação (Open Publication License) em uma mesma mídia que contenha
outros trabalhos ou programas não protegidos por essa licença não decorre em
aplicação da Licença de Livre Publicação (Open Publication License) para esses
outros trabalhos. O trabalho resultante deve explicitamente conter uma nota
especificando a inclusão do material protegido pela Licença de Livre Publicação
(Open Publication License) e o aviso de copyright apropriado.
APLICABILIDADE. Se alguma parte desta licença não puder ser aplicada
em alguma jurisdição, as partes restantes deste documento continuam sendo
aplicadas.
AUSÊNCIA DE GARANTIA. Os trabalhos protegidos pela Licença de Livre
Publicação (Open Publication License) são fornecidos "como estão", sem
garantias de qualquer tipo, explícita ou implícita, incluindo, mas não limitado a, as
garantias implícitas de comercialização e conveniência para um propósito
particular, ou garantia de não-infração.
IV. Requisitos para trabalhos modificados
Todas as versões modificadas de documentos cobertos por esta licença,
incluindo traduções, antologias, compilações e documentação parcial, deve seguir
os requisitos abaixo:
A versão modificada deve ser indicada como tal.
As pessoas que fizerem as modificações e as datas de modificação devem
ser identificadas.
O reconhecimento dos autores e editor originais (se aplicável) deve ser
mantido de acordo com as práticas acadêmicas usuais de citação.
O local da versão não-modificada do documento deve ser indicado.
Os nomes originais dos autores não devem ser utilizados para indicar ou
garantir seu endosso ao documento resultante sem a autorização expressa dos
autores.
V. Práticas recomendadas
Em adição aos requisitos desta licença, é solicitado e extremamente
recomendado aos redistribuidores que:
Se os trabalhos protegidos pela Licença de Livre Publicação (Open
Publication License) estiverem sendo distribuídos em impressos ou CD-ROM, os
autores sejam informados por email, ao menos trinta dias antes, para que os
autores tenham tempo de providenciar documentação atualizada. Esta notificação
deve descrever as modificaçoes introduzidas no documento, se existirem.
Todas as modificações substanciais (incluindo exclusões) devem ser
marcadas claramente no documento, ou então descritas em um anexo ao
documento.
Finalmente, mesmo não sendo obrigatório sob esta licença, é considerado
de bom tom oferecer uma cópia sem ônus de todo o material modificado (impresso
e CD-ROM) para os autores originais.
VI. Termos opcionais
Os autores e editores de documentos protegidos pela Licença de Livre
Publicação (Open Publication License) podem escolher certas opções de licença
simplesmente incluindo alguns parágrafos após a cópia da licença ou sua
referência. Estas opções são consideradas parte da licença e devem ser incluídas
com ela (ou com a referência a ela) nos trabalhos derivados.
As opções que se aplicam a este trabalho são:
A:É vedada a distribuição de versões com modificações substanciais deste
documento sem a expressa permissão dos proprietários do direito autoral.
B:É vedada a distribuição deste trabalho ou qualquer derivado seu em
qualquer formato de livro padrão (papel) sem a prévia autorização dos
proprietários do direito autoral.

Políticas de Publicação Livre

(O texto a seguir não é considerado parte da licença.)
Os trabalhos protegidos pela Licença de Livre Publicação (Open Publication
License) estão disponíveis e podem ser acessados na home page da Open
Publication <http://works.opencontent.org/> .
Os autores de trabalhos protegidos pela Licença de Livre Publicação (Open
Publication License) podem incluir suas próprias licenças nesses trabalhos, desde
que os termos dessa licença não sejam mais restritrivos que os da Licença de
Livre Publicação (Open Publication License).
Em caso de dúvidas sobre a Licença de Livre Publicação (Open Publication
License), contactar David Wiley <dw2@opencontent.org> ou a lista de autores de
publicações <opal@opencontent.org <mailto:opal@opencontent.org>> via email.
Para se inscrever na lista de autores de publicações livres (Open
Publication Author's List), mande um email para <opal-request@opencontent.org
<mailto:opal-request@opencontent.org>> com a palavra subscribe no corpo da
mensagem.
 Para enviar mensagens para a lista de autores de publicações livres (Open
Publication Author's List), mande um email para opal@opencontent.org ou
simplesmente responda a uma mensagem postada.
Para se desinscrever na lista de autores de publicações livres (Open
Publication Author's List), mande um email para opal-request@opencontent.org
com a palavra unsubscribe no corpo da mensagem.