Sistemas de firewall baseados em Software Livre

Prof. João Eriberto Mota Filho

Universidade Católica de Brasília - Graduação Virtual

Curso Superior Tecnológico em Segurança da Informação

eriberto@eriberto.pro.br, joaomf@ucb.br

Brasília, DF, 09 de dezembro de 2009

Resumo. Firewall é uma palavra muito comum no vocabulário de gerentes de

redes de computadores e de segurança em redes. No entanto, para muitos, tal
palavra se resume a um esquema de segurança composto por uma única
máquina. Geralmente, essa máquina possui algum software do tipo filtro de
pacotes e nada mais. Esse tipo de situação, tão corriqueira, na verdade,
quase não agrega segurança às redes. Firewall é um conceito e não uma
máquina. Esse conceito, se corretamente aplicado, irá gerar um ambiente de
segurança composto por vários hosts, com diversos níveis de filtragem de
tráfego. Esse ambiente é conhecido como sistema de firewall.

Abstract. Firewall is a very common word adopted by network managers and

network security managers. However, for many people, this word refers to a
security scheme made with one single machine. Many times, that machine has
some software as packet filter only. This trivial situation, in fact, almost never
add security to the nets. Firewall is a concept and not a machine. That
concept, if properly applied, will go to generate a security framework made by
several hosts, with diverse levels of traffic filtering. That framework is known
as firewall system.

1. Introdução
Washington, DC, 21 de abril de 2009 [CNN, 2009, tradução] 1 - Milhares de arquivos
confidenciais, relativos ao projeto do mais avançado avião de combate dos EUA,
foram comprometidos por "hackers" não identificados nos últimos dois anos, conforme
o relato de oficiais superiores do sistema de defesa americano no Pentágono, que não
quiseram identificar-se, em virtude da sensibilidade da informação. Os invasores
tiveram acesso, pela Internet, não só ao projeto, mas também ao sistema de controle de
tráfego da Força Aérea.
No mundo atual, quase todas as atividades humanas, tanto nas profissões quanto
na vida pessoal, são assistidas por computadores. Em grande parte das vezes, esses
computadores trabalham em rede e tais redes têm contato com a Internet. Esse tipo de
cenário oferece um grande perigo, pois atacantes do mundo inteiro podem utilizar a
Internet como via de acesso para as redes que a ela se ligam. Isso não descarta a

1 Disponível em <http://www.cnn.com/2009/US/04/21/pentagon.hacked/index.html>. Acesso em 22

nov. 2009.
ocorrência de ataques gerados internamente em cada rede, situação muito comuns nos
dias atuais, causados por funcionários insatisfeitos ou pessoas interessadas na sensação
de poder.
Segundo o [JORNAL DA GLOBO, 2009]2, "o Brasil está em quinto lugar em
ataques maliciosos na Internet", por ser um dos países que mais sofrem tentativas de
crimes virtuais. O [NIC.BR, 2009]3 relatou que as notificações de ataques a servidores
Web aumentaram em 149% em 2008. Ainda, a [FOLHA ONLINE, 2009]4 noticiou que
os ataques virtuais aos computadores do governo dos EUA aumentaram em 40% no ano
de 2008; foram 5.488 incidentes registrados em 2008, contra 3.928 em 2007.
A extrema dependência da informática pelo ser humano na atualidade, aliada ao
cenário de ataques cibernéticos cada vez mais crescentes, cria a necessidade de uma
defesa forte e eficiente. É neste ponto que surgem os sistemas de firewall. Sistemas de
firewall atuam como elementos de atenuação de ataques, uma vez que a segurança total
é uma situação que, apesar de utópica, deve ser perseguida agressivamente pelos
administradores de rede e segurança. Em outras palavras, não há como chegar à
segurança total; então, deve-se buscar a maior proximidade possível a ela.

2. Conceitos preliminares
Para entender sistemas de firewall, torna-se necessário o conhecimento de conceitos
básicos como protocolos de rede, modelo OSI e outros itens específicos. Esta seção
abordará tais conceitos.

2.1. Protocolos de rede

Segundo [COMER, 1998]:

Protocolos como TCP e IP fornecem as regras para a comunicação. Eles

contêm os detalhes de formatos de mensagens, descrevem o que um computador
faz ao receber uma mensagem e especificam como um computador trata os erros
ou outras condições anormais. O mais importante é que esses protocolos
permitem que tratemos a comunicação através do computador, independente do
hardware da rede de qualquer fornecedor em particular. De certa forma, os
protocolos estão para a comunicação assim como os algoritmos estão para a
computação. Um algoritmo permite que uma pessoa especifique ou compreenda a
computação sem conhecer os detalhes de um conjunto de instruções de uma CPU
em especial. Da mesma forma, um protocolo de comunicação permite que alguém
especifique ou entenda uma comunicação de dados sem depender de
conhecimentos minuciosos do hardware da rede de um fornecedor específico.

2 Disponível em <http://tiny.cc/jornal_globo_brasil_quinto_lugar_ataques>. Acesso em 22 nov. 2009.

3 Disponível em <http://www.nic.br/imprensa/clipping/2009/midia031.htm>. Acesso em 22 nov.
2009.
4 Disponível em <http://www1.folha.uol.com.br/folha/informatica/ult124u505493.shtml>. Acesso em
22 nov. 2009.
 [FOROUZAN, 2007, tradução] diz:

Em redes de computadores, a comunicação ocorre entre entidades em

diferentes sistemas. Uma entidade é qualquer coisa capaz de enviar ou receber
informações. No entanto, duas entidades não podem simplesmente enviar
sequências de bits para outra e esperar ser entendida. Para a comunicação
acontecer, as entidades devem aderir ao uso de um protocolo. Um protocolo é um
conjunto de regras que gerencia a comunicação de dados. Um protocolo define o
que será comunicado, como será a comunicação e quando haverá tal
comunicação.

Em outras palavras, um protocolo de rede é um conjunto de regras que define

como se dará o tráfego de dados em tal rede. Os protocolos de rede, geralmente,
possuem duas partes: um cabeçalho ou header e uma área de dados ou payload. O
cabeçalho é responsável pelo controle dos dados. O payload contém os dados
propriamente ditos. A Figura 1 mostra a estrutura básica de um protocolo de rede.

Figura 1 - A estrutura de um protocolo de rede.

2.2. Protocolo IP
O protocolo IP é o principal protocolo da família TCP/IP. Segundo [FOROUZAN,
2007, tradução]:

O protocolo IP é o mecanismo de transmissão usado pelo protocolo

TCP/IP. Ele é um protocolo não confiável e não orientado à conexão, em outras
palavras, um protocolo do tipo serviço de entrega pelo melhor esforço. [...] O IP
transporta dados em pacotes chamados datagramas, sendo que cada um trafega
separadamente. Datagramas podem viajar através de diferentes rotas e podem
chegar fora de sequência ou duplicados.

A [RFC 791, 1981]5 e as suas atualizações são responsáveis por especificar o IP.
A Figura 2 mostra a estrutura de um cabeçalho IP.
É importante citar que um dos campos mais interessantes do protocolo IP é o
"protocol". Este campo estabelece o protocolo a ser transportado pelo IP. Isso porque o
IP é um protocolo que transporta outros protocolos. Em outras palavras, dentro do
payload do IP só é possível encontrar um outro protocolo, que deve pertencer à lista dos
"protocolos IP". Essa lista é disponibilizada pela [IANA, 2009]6.

5 Disponível em <http://www.rfc-editor.org/rfc/rfc791.txt>. Acesso em 22 nov. 2009.

6 Disponível em <http://www.iana.org/assignments/protocol-numbers>. Acesso em 22 nov. 2009.
 Figura 2 - A estrutura de um cabeçalho IP. Fonte: [HEADER DRAWINGS, ?]7.

Vários protocolos IP, por serem muito utilizados, são muito populares. A Tabela
1 relaciona alguns desses protocolos IP.
Tabela 1 - Alguns dos protocolos IP mais conhecidos. Fonte: [IANA, 2009]8.
Nr Protocolo
1 ICMP
6 TCP
17 UDP
50 IPSec
51 IPSec

A Figura 3 simboliza o encapsulamento realizado por um protocolo IP. O TCP

foi utilizado como exemplo.

Figura 3 - O encapsulamento do protocolo TCP pelo protocolo IP.

7 Disponível em <http://www.fatpipe.org/~mjb/Drawings>. Acesso em 22 nov. 2009.

8 Disponível em <http://www.iana.org/assignments/protocol-numbers>. Acesso em 29 nov. 2009.
2.3. Protocolos TCP e UDP
Dentre todos os protocolos IP, os que mais se destacam são o TCP e o UDP. Esses são
os dois únicos protocolos IP que possuem porta. Assim, para usar uma porta como a 53
(DNS) ou a 80 (HTTP), é necessário operar com um desses dois protocolos. A Figura 4
mostra a estrutura do cabeçalho do protocolo TCP.

Figura 4 - A estrutura de um cabeçalho TCP. Fonte: [HEADER DRAWINGS, ?]9.

O protocolo TCP foi desenvolvido para ser um protocolo confiável e com

controle de erros. Isso faz com que o mesmo seja robusto, preciso, detalhista e
relativamente lento. Já o UDP foi concebido para fazer a mesma tarefa do TCP, mas de
forma rápida, utilizando menos controles. Isso faz com que o UDP não tenha muito
controle e confiabilidade. O TCP trabalha pela aplicação que o utiliza. No caso do UDP,
a aplicação é responsável pela maior parte do controle do tráfego dos seus dados.
A Figura 5 mostra e estrutura do cabeçalho de um protocolo UDP.

Figura 5 - A estrutura de um cabeçalho UDP. Fonte: [HEADER DRAWINGS, ?]10.

No que tange às verificações de erros, o campo checksum do cabeçalho do

protocolo IP só garante o conteúdo do referido cabeçalho. Isso ocorre para que
operações de tráfego, por ocasião da passagem por roteadores de rede, sejam rápidas. Já
os protocolos TCP e UDP realizam tal verificação com base nos dados contidos nos seus
cabeçalhos, payload e parte do cabeçalho do protocolo IP que os encapsula. Um detalhe
importante é que, segundo a [RFC 768, 1980] 11, no caso do protocolo UDP, essa

9 Disponível em <http://www.fatpipe.org/~mjb/Drawings>. Acesso em 29 nov. 2009.

10 Disponível em <http://www.fatpipe.org/~mjb/Drawings>. Acesso em 29 nov. 2009.
11 Disponível em <http://www.rfc-editor.org/rfc/rfc768.txt>. Acesso em 29 nov. 2009.
verificação de erro é opcional. Isso faz com que o tráfego tenha mais velocidade, se isso
for necessário.
A grande característica dos protocolos TCP e UDP é que, assim como no IP, só
poderá ser encontrado nos seus payloads um outro protocolo, como o HTTP por
exemplo. Assim, os protocolos encontrados no payload do TCP e do UDP são os
protocolos de aplicação, também listados pela [IANA, 2009]12. A Figura 6 mostra o
encapsulamento do protocolo HTTP.

Figura 6 - Encapsulamento do protocolo HTTP pelo protocolo TCP.

O protocolo TCP é especificado pela [RFC 793, 1981]13 e suas atualizações. Já o

protocolo UDP é especificado pela [RFC 768, 1980]14 e suas atualizações.

2.4. O protocolo ICMP

O ICMP é o protocolo IP responsável por avisos e mensagens importantes sobre
ocorrências na rede. Segundo [FOROUZAN, 2007, tradução]:

O Internet Control Message Protocol (ICMP) é um mecanismo usado por

hosts e roteadores para enviar, para o remetente, notificações a respeito de
problemas com pacotes (datagramas). O ICMP envia perguntas e também
mensagens com relatórios de erros.

Segundo [STEVENS,1994, tradução]:

O ICMP é também considerado como sendo da mesma camada do IP. Ele

envia mensagens de erro e outras condições que requerem atenção. As mensagens
ICMP, normalmente, são influenciadas por protocolos IP. Algumas mensagens
ICMP referem-se a erros a serem retornados para as aplicações.

12 Disponível em <http://www.iana.org/assignments/port-numbers>. Acesso em 22 nov. 2009.

13 Disponível em <http://www.rfc-editor.org/rfc/rfc793.txt>. Acesso em 22 nov. 2009.
14 Disponível em <http://www.rfc-editor.org/rfc/rfc768.txt>. Acesso em 22 nov. 2009.
 Ainda, [COMER, 1998], diz:

O Internet Control Message Protocol permite que os roteadores enviem

mensagens de erro ou de controle aos outros roteadores ou aos hosts; o ICMP
possibilita a comunicação entre o software do protocolo IP em uma máquina, e o
software do protocolo IP em outra. (...) Quando o datagrama causa um erro, o
ICMP somente pode reportar a condição de erro quando de volta ao transmissor
do datagrama; o transmissor deve relacionar o erro a um programa aplicativo
individual ou executar outras ações para corrigir o problema.

Em outras palavras, o ICMP é o protocolo que auxilia diretamente no controle de

rede. O TCP é um protocolo semi-completo: possui controle de erros, de fluxo etc. No
entanto, a maioria dos protocolos, como o IP e o UDP, não possuem tanto controle
sobre si mesmos. É neste ponto que surge o ICMP. Sem o ICMP, a rede poderá perder o
controle e entrar em colapso. Páginas de Internet, por exemplo, poderiam deixar de ser
exibidas, caso o protocolo ICMP não existisse e não pudesse reportar a necessidade de
fragmentação de um protocolo IP, para que o mesmo tivesse condições de transpor um
determinado roteador de rede. A Figura 7 mostra o cabeçalho de um protocolo ICMP.

Figura 7 - A estrutura de um cabeçalho UDP. Fonte: [HEADER DRAWINGS, ?]15.

Existem vários tipos de mensagens ICMP. O tipo 8, por exemplo, é o echo

request, representado pelo tráfego de ida gerado pelo conhecido comando ping. A volta
do ping, que mostra se uma máquina possui conectividade de rede ou não, é o echo
reply, que é o ICMP tipo 0. O cabeçalho ICMP possui um campo chamado type e outro
chamado code. Isso ocorre porque alguns tipos de ICMP possuem variantes, que são
balizadas por códigos. A [IANA, 2009]16 apresenta uma lista dos tipos e códigos de
ICMP.
É muito importante evidenciar que o protocolo ICMP é essencial para o controle
nas redes TCP/IP. Assim sendo, não se deve bloquear o tráfego ICMP em redes. O
bloqueio do ICMP não agrega segurança, como muitos pensam. Ao contrário, cria
transtornos indesejados. O que se deve fazer é controlar a taxa de ICMP tipo echo
request que poderá ser aceita. Com recursos de filtragens de pacotes é possível dizer,
por exemplo, que somente serão permitidos dez echo requests por segundo.

15 Disponível em <http://www.fatpipe.org/~mjb/Drawings>. Acesso em 29 nov. 2009.

16 Disponível em <http://www.iana.org/assignments/icmp-parameters>. Acesso em 29 nov. 2009.
2.5. O modelo OSI e o encapsulamento de protocolos
Segundo [FOROUZAN, 2007, tradução]:

O modelo OSI é um framework composto por diversas camadas, criado

para que o planejamento de sistemas de rede permita a comunicação entre todos
os tipos de sistemas de computadores. Este modelo é constituído por sete camadas
separadas mas relacionadas, cada uma definindo uma parte do processo de
tráfego de informação através de uma rede. O entendimento dos fundamentos do
modelo OSI proporciona uma base sólida para a exploração do assunto
comunicação de dados.

[SANS, 2001, tradução]17 diz o seguinte:

O modelo de referência Open Systems Interconnection (OSI) tem servido

como o mais básico dos elementos da computação em rede desde a sua criação
em 1984. O modelo OSI está baseado em uma proposta desenvolvida pela
International Standards Organization (ISO). O objetivo original do modelo OSI
foi prover um conjunto de regras para os fabricantes de equipamentos de rede
desenvolverem aparelhos e placas que pudessem se comunicar uns com os outros.
O modelo OSI define uma arquitetura hierárquica de porções lógicas de funções
necessárias para permitir a comunicação de sistema para sistema.

Assim, o modelo OSI é uma forma de se vislumbrar o tráfego de dados em uma

rede de computadores. O seu entendimento é fundamental para a correta implementação
de sistemas de firewall. A Figura 8 mostra o modelo OSI e as suas sete camadas.

Figura 8 - O modelo OSI.

Cada camada do modelo OSI possui uma função específica. Segundo

[FOROUZAN, 2007, tradução]:
• Física: é responsável pelo movimento de bits, individualmente, de um nó
de rede (equipamento) até o próximo.
• Enlace: coordena o movimento de quadros (frames) de um nó de rede até o
próximo.
• Rede: responsável pela entrega de pacotes, individualmente, de um host de
origem a um host de destino.
• Transporte: faz a entrega de uma mensagem de um processo para outro.

17 Disponível em <http://www.sans.org/reading_room/whitepapers/standards/ \
the_osi_model_an_overview_543>. Acesso em 29 nov. 2009.
 • Sessão: responsável pelo controle de diálogo e sincronização entre
aplicações.
• Apresentação: realiza a tradução, (des)compressão e (de)cifragem de
dados de aplicações.
• Aplicação: provê serviços para os usuários.
Na prática, o TCP/IP pode ser disposto no modelo OSI de acordo com o
mostrado Figura 9.

Figura 9 - O relacionamento básico do TCP/IP com o OSI.

O modelo OSI, dentre outras tarefas, realiza o encapsulamento de protocolos. Ou

seja, depois de sofrer controles e verificações nas camadas 5 e 6, os protocolos de
aplicação, listados por [IANA, 2009]18, pertencentes à camada 7, são encapsulados pela
camada 4 (TCP ou UDP). Depois, a camada 4 é encapsulada pela camada 3 (IP). Com
isso, chega-se à situação que foi mostrada anteriormente na Figura 6. Ainda, depois de
ocorrer um encapsulamento na camada 3, haverá outro na camada 2. Neste caso, os
protocolos da camada 2 não fazem mais parte do TCP/IP e servem para transportar o
mesmo ou outras famílias de protocolos. Alguns dos protocolos existentes na camada 2:
Ethernet, PPP, frame relay e ATM.
A Figura 10 mostra a mesma situação da Figura 6, já em uma rede Ethernet, sob
o ponto de vista do modelo OSI.

Figura 10 - O encapsulamento de protocolos.

18 Disponível em <http://www.iana.org/assignments/port-numbers>. Acesso em 29 nov. 09.

2.6. Hosts in-line ou em nível de circuito
Diz-se que um host está in-line (ou em nível de circuito) quando o mesmo possui dois ou
mais adaptadores de rede e está no caminho tráfego, ou seja, os dados passam por
dentro do mesmo. A Figura 11 exemplifica essa situação. As duas máquinas centrais
estão in-line.

Figura 11 - Hosts in-line.

2.7. Roteadores e bridges

Roteadores e bridges são máquinas in-line que interligam grupos de máquinas. A
diferença básica está no fato das bridges atuarem na camada 2, de forma similar aos
switches de rede. Os roteadores atuam na camada 3. As bridges interligam porções da
mesma rede. Os roteadores interligam segmentos de redes diferentes. As bridges também
executam a nobre função de interligar tecnologias diferentes na camada 2. Exemplo: a
interligação de uma rede ATM com uma Ethernet. As bridges são um ótimo recurso para
resolver algumas situações em sistemas de firewall. São rápidas e, por não necessitarem
de endereço IP, não são percebidas por quem analisa a topologia remotamente.

2.8. DMZ
DMZ, que é a abreviatura de demilitarized zone ou zona desmilitarizada, é uma rede
separada utilizada para reunir servidores que terão contato com redes públicas externas.
[GORALSKI, 2009, tradução] afirma:

A DMZ é muito útil quando o nível de proteção do site não é absoluto;

isto ocorre quando não é possível negar todos os acessos direcionados ao site, a
partir do lado de fora da rede, como a Internet (é o caso de servidores web ou
FTP disponíveis para uso geral).

É importante salientar que, em princípio, a DMZ nunca deverá ter contato com as
redes internas por iniciativa própria. Isso porque, em caso de uma intrusão, o invasor
deverá ficar contido na DMZ, sem a possibilidade de saída daquele "bolsão".

3. Sistemas de firewall
Baseando-se nos conhecimentos anteriores, a partir deste ponto serão mostrados os
conceitos relativos a sistemas de firewall.

3.1. Definição de sistema de firewall

Segundo [CHESWICK, 2003, tradução]:

Firewall é uma coleção de componentes colocados entre duas redes que,

atuando em conjunto, possui as seguintes propriedades:
 • Todo o tráfego de dentro para fora e vice-versa deve passar através do
firewall.
• Apenas o tráfego autorizado, como os definidos pela política de
segurança local, terão permissão para passar.
• O firewall deverá ser imune a penetração.
É comum observar, principalmente no mundo Linux, afirmações do tipo "o meu
firewall é um iptables". Essa é uma afirmação totalmente equivocada, uma vez que o
citado recurso, isoladamente, não tem condições de prover segurança a uma rede de
computadores. Como se não bastasse, iptables não é um recurso de firewall e sim um
mero comando que manipula o verdadeiro filtro de pacotes existente no kernel Linux: o
Netfilter. Neste ponto, é necessário entender que o Netfilter é um filtro de pacotes, ou
seja, um elemento que entende as camadas 3 e 4 do modelo OSI. Assim sendo, o
Netfilter é capaz de manipular apenas os recursos oferecidos por protocolos como IP,
ICMP, TCP, UDP etc. Em outras palavras, o Netfilter (vulgo iptables para alguns) só
entende algo como endereço IP de origem ou destino, portas TCP e UDP, flags TCP etc.
Mas ele não é capaz de entender os cabeçalhos e payloads de protocolos existentes na
camada 7. Deve-se considerar que um ataque por URL a um servidor de páginas, por
exemplo, transitará dentro da camada 7.
Pode-se afirmar que firewall é um sistema e não uma máquina. Trata-se de um
sistema capaz de interagir com as camadas 2 a 7 do modelo OSI. Uma definição simples
a abrangente seria: firewall é todo o esforço físico e lógico utilizado para prover
segurança a uma rede de computadores. Assim, qualquer recurso empregado na
segurança de uma rede, inclusive humanos, fará parte do sistema de firewall. Para esta
última afirmação, considere pessoas que se revezam em diversos turnos, 24h por dia,
analisando todo o tráfego de uma rede, buscando por evidências de ataques em tempo
real. Essas pessoas fazem parte de um sistema, um processo de autoria. Este sistema é o
sistema de firewall.
Os sistemas de firewall são constituídos por elementos de firewall. Cada elemento
é um recurso que faz algum tipo de análise, registro e/ou bloqueio. São exemplos disso
os filtros de pacotes, como o Netfilter, e os proxies, como o Squid.

3.2. Desagrupamento de serviços em máquinas

Um importante procedimento no que tange à segurança de redes é o desagrupamento de
serviços. Deve-se sempre considerar que, em princípio, todo serviço de rede possui falha
de segurança. Talvez essa falha nunca seja descoberta mas, certamente, existe. Assim, a
implementação de dois ou mais serviços de rede em uma mesma máquina aumentará
potencialmente a possibilidade de uma terrível intrusão. Um exemplo simples: em uma
máquina que contenha um serviço de e-mail, páginas e DNS, se houver uma falha de
segurança neste último e tal máquina for invadida, automaticamente os serviços de e-mail
e páginas estarão totalmente vulneráveis. A melhor política contra isso é a instalação de
apenas um serviço por máquina. Uma solução para não haver desperdício de hardware é
a virtualização. Um dos princípios de virtualização é o perfeito isolamento entre as
máquinas virtuais.
O desagrupamento de serviços será essencial para implementação da técnica
conhecida como defesa em profundidade.
3.3. Defesa em profundidade
Um dos mais importantes princípios para a implementação de firewalls é o da defesa em
profundidade. Diz [ZWICKY, 2000, tradução]:

Não dependa de somente um mecanismo de segurança, por mais difícil

que isso possa parecer; em vez disso, instale vários mecanismos que se ligam uns
aos outros. Você não quer que uma falha em um único mecanismo de segurança
comprometa totalmente a sua segurança. Você pode ver exemplos deste princípio
em outros aspectos da sua vida. Por exemplo, a sua porta da frente,
provavelmente, tem tanto uma fechadura convencional quanto um ferrolho; o seu
carro, provavelmente, possui uma chave na porta e outra na ignição; e assim por
diante.

Em sistemas de firewall, a defesa em profundidade agrega segurança pois, como

já foi visto, a existência de vários serviços na mesma máquina aumenta a possibilidade de
uma intrusão. Exemplificando, uma máquina contendo um filtro de pacotes e um proxy,
por exemplo, poderá ser ultrapassada caso o referido proxy permita uma intrusão. Com
isso, o filtro de pacotes ficará inerte, não conseguindo atuar. Só se deve utilizar dois
elementos de firewall em uma mesma máquina se não houver alternativa, como é o caso
da implementação do recurso conhecido como proxy transparente, onde deverá existir
um proxy e um filtro de pacotes para fazer um desvio de porta.
Um outro motivo para a adoção da defesa em profundidade é o fato de que
alguns elementos de firewall se instalam em roteadores (camada 3) e outros em bridges
(camada 2). Assim, não é possível misturar esses dois tipos de elementos.

4. Elementos de firewall
Um sistema de firewall deverá ser composto por diversos elementos. Cada elemento terá
uma função específica, atuando em uma ou mais camadas do modelo OSI. As camadas
mais significativas são as 2 (enlace), 3 (rede), 4 (transporte) e 7 (aplicação).
A seguir, serão analisados os principais elementos que poderão compor sistemas
de firewall.

4.1. Filtros de pacotes

Os filtros de pacotes atuam nas camadas 3 e 4 do modelo OSI, podendo entender
elementos da camada 2, como um endereço MAC de origem, por exemplo. Nas camadas
3 e 4, os filtros de pacotes podem trabalhar com quase todas as informações disponíveis,
como endereços IP de origem e destino, protocolos IP, portas TCP e UDP, flags TCP
etc.
Os filtros de pacotes são como guardas de trânsito que permitem a passagem de
pacotes que satisfaçam pré-requisitos, como direção de tráfego, por exemplo. Os filtros
de pacotes não analisam, por exemplo, o payload da camada 4 (que é a camada 7).
Assim, baseando-se apenas nos itens presentes nos cabeçalhos das camadas 3 e 4, caso
não sejam combinados com outros elementos de firewall, os filtros de pacotes permitirão
a passagem de ataques embutidos na camada 7.
Os filtros de pacotes também são capazes de realizar NAT (network address
translation). O NAT ocorre quanto é feita uma alteração de endereço IP ou porta ou os
dois. Os NATs mais comuns são os utilizados para mascaramento e para
redirecionamento. No caso do NAT de mascaramento, os pacotes IP que saem, por
exemplo, para a Internet, têm o seu endereço de origem alterado para que a Internet
possa restituir o pacote. Essa alteração de endereço é feita na saída da máquina
roteadora. A Figura 12 mostra um NAT de mascaramento.

Figura 12 - O mascaramento.

Na Figura 12, a máquina 10.0.0.1 envia um pacote em direção à Internet. O seu

gateway será o IP 10.0.0.20. O pacote entrará na máquina roteadora pela placa eth0 e
sairá pela placa eth1. Ao sair pela eth1, o IP de origem será trocado de 10.0.0.1 para
203.0.113.20. Essa situação ficará registrada, geralmente em memória e, na volta do
pacote, o IP, agora de destino, será trocado de 203.0.113.20 para 10.0.0.1 quando tal
pacote passar pelo roteador. Sem isso, o pacote não trafegaria, pois a Internet não roteia
endereços IP 10.x.x.x.
O NAT de redirecionamento ocorre quando um pacote chega à máquina de
destino e esta o redireciona para outra máquina ou para outra porta (local ou em outra
máquina).

4.2. Filtros de estados

Os filtros de estados, geralmente, representam um recurso incluso nos filtros de pacotes.
Filtros de estados são elementos que analisam estados das conexões e permitem
que o tráfego, além de direção, tenha sentido. Assim, um tráfego poderá ser iniciado do
host A para o host B mas nunca ao contrário, por exemplo.
Segundo [EYCHENNE, 2008, tradução], os estados utilizados pelo Netfilter do
kernel Linux, por exemplo, são:
• NEW: relativo a pacotes que estabelecem uma nova conexão ou
associados a uma conexão que não possui pacotes transitando
previamente em ambas as direções.
• ESTABLISHED: atribuído a pacotes associados com uma conexão que
possui pacotes transitando em todas as direções (exceto o primeiro de
todos, que se enquadra como NEW).
• RELATED: relativo a um pacote que está iniciando uma conexão mas
está associado com uma outra já existente, como é o caso de uma
transferência de dados por FTP (já que a primeira conexão foi a de
autenticação) ou um erro ICMP.
• INVALID: referente a pacotes que não podem ser identificados por
algum motivo, incluindo os que provocarem vazamentos ou violação de
memória e erros ICMP que não correspondam a qualquer conexão
previamente conhecida.

A Figura 13 mostra uma situação de rede com base na qual será utilizada uma
regra de Netfilter para estabelecer o tráfego por estados.
 Figura 13 - Um exemplo de filtragem por estados.

Na Figura 13 há dois servidores de rede, cada um com um banco de dados

Oracle. Numa situação hipotética, o servidor 1 deverá acessar o servidor 2, diariamente,
para sincronizar tabelas. No entanto, em virtude do servidor 1 conter algumas tabelas
extras e sigilosas, o servidor 2 nunca poderá ter acesso ao servidor 1. É neste ponto que
se enquadra o uso de filtragem por estados. A seguir, um exemplo de regra do Netfilter,
aplicada no roteador central, utilizando estados, para resolver o problema:
iptables -A FORWARD -s 172.16.0.1 -d 10.0.0.1 -m state --state
NEW,INVALID -j DROP

Em outras palavras, em virtude da regra anterior, a comunicação no sentido

Oracle 2 - Oracle 1 só será possível se o estado for ESTABLISHED ou RELATED.

4.3. Proxies
A palavra proxy pode ser traduzida como procurador. Proxies servem de intermediários
entre clientes e servidores para que seja dado um determinado nível de segurança a tais
clientes ou aos serviços na rede. Eles atuam diretamente na camada 7 e entendem a
camada 3, para poderem selecionar o tráfego alvo. A [RFC 2616, 1999, tradução] diz:

Proxy é um programa intermediário que atua como um cliente e também

como um servidor, com o propósito de realizar requisições em favor de outros
clientes. Requisições são servidas internamente ou por repasse, com uma possível
tradução de endereços (NAT), para outros servidores. Um proxy deve
implementar os requisitos tanto de cliente como de servidor. Um proxy
transparente é um proxy que não modifica a requisição ou resposta além do
necessário para haver uma autenticação e identificação. Um proxy não
transparente é um proxy que modifica a requisição ou a resposta com o intuito de
prover algum serviço adicional para o usuário, como filtragem anônima.

Em outras palavras, proxy é um elemento posicionado entre clientes e servidores.

Os proxies não servem somente para a navegação em sites da Internet como muitos
pensam. Existem proxies para quase todos os serviços de aplicações (camada 7). Então,
há proxies HTTP, FTP, SMTP, POP3, DNS etc.
É importante ressaltar que proxies não aceleram Internet. Os aceleradores de
Internet, por ocasião da consulta a sites, são os caches. Há proxies HTTP que possuem
cache, como é o caso do Squid.
Um proxy deve saber se comportar como cliente e como servidor porque é assim
que, na verdade, ele funciona. Quando um host procura pelo proxy para solicitar um site,
este recebe a conexão do host como servidor. No entanto, quando o proxy sai em busca
do site, ele o faz na qualidade de cliente.
 Quanto ao objetivo de uso, os proxies podem ser classificados em proxy de
encaminhamento (forward proxy) ou proxy reverso (reverse proxy). As definições
básicas desses dois tipos de proxy não são esclarecedoras, sem um entendimento mais
profundo do seu funcionamento. Diz-se que o proxy de encaminhamento é utilizado
quando há a necessidade de fazer com que um cliente acesse vários servidores diferentes.
Já um proxy reverso é utilizado quando vários clientes precisam acessar um determinado
servidor.
Segundo a [IBM, 2005, tradução]:

Um proxy de encaminhamento (forward) é a forma mais comum de

servidor proxy e, geralmente, é usado para enviar requisições a partir de uma
rede isolada e privada para a Internet. (...) Um proxy de encaminhamento, antes
de tudo, verificará se a requisição é válida. Se a requisição não for válida ou
permitida, o proxy vai rejeitar a conexão, o que irá fazer com que o cliente receba
um erro ou um redirecionamento.

O proxy de encaminhamento é muito utilizado para permitir que usuários de

redes internas acessem sites da Internet. Certamente, essa é a forma mais difundida de
utilização de proxy. Neste caso, normalmente, implementa-se um proxy HTTP de
encaminhamento (forward) com cache. A Figura 14 mostra um proxy de
encaminhamento em ação.

Figura 14 - O forward proxy. Fonte: [IBM, 2005]19.

Quanto ao proxy reverso, explica a [IBM, 2005, tradução]:

Um proxy reverso é uma outra forma comum de servidor proxy e,

geralmente, é utilizado para passar requisições oriundas da Internet, através de
um firewall, para uma rede privada isolada. Ele é utilizado para evitar que
clientes oriundos da Internet tenham contato direto com os servidores ou acesso
não monitorado a dados sensíveis em servidores de conteúdo em redes isoladas
(intranet). Se o cache estiver habilitado, o proxy reverso também poderá reduzir o
tráfego de rede, uma vez que poderá servir informações nele armazenadas, ao
invés de repassar todas as requisições para os servidores de conteúdo.

Em resumo, um proxy reverso é colocado entre um servidor e os seus clientes,

para que tais clientes não tenham contato direto com tais servidores. Assim, caso seja
realizado um ataque, o atacado será o proxy e não o servidor final. É extremamente
recomendável que cada servidor de rede tenha um proxy reverso a sua frente. A Figura
15 mostra a utilização de um proxy reverso.

19 Disponível em <http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzaie/ \
rzaieproxytypes.htm>. Acesso em 01 dez. 09.
 Figura 15 - O proxy reverso. Fonte: [IBM, 2005]20.

Uma outra modalidade de proxy é o transparente. Esse tipo de proxy é

posicionado na topologia e não requer configuração específica no cliente para que este
possa utilizá-lo. Um regra de NAT no filtro de pacotes faz com que todo o tráfego
destinado a um determinado serviço na Internet, por exemplo, seja redirecionado para o
proxy interno (forward) que entenda o protocolo em tráfego. A Figura 16 mostra um
exemplo de utilização do proxy transparente.

Figura 16 - O proxy transparente.

Na Figura 16 é possível ver uma requisição HTTP de um usuário indo em direção

a uma porta 80 na Internet. No trajeto, o pacote encontra um proxy transparente no
circuito de passagem (proxy in-line). Ao verificar que o cliente deseja atingir uma porta
80 na Internet, o filtro de pacotes instalado junto com o proxy redireciona o tráfego para
a porta 3128 local (NAT), que é a porta do referido proxy. Com isso, o pacote é
obrigado a trafegar pelo proxy.
Os proxies, basicamente, trabalham com a análise do protocolo da camada 7. Um
bom proxy verifica se o protocolo está sendo utilizado de forma correta e faz a busca
dos dados solicitados pelo cliente. É muito importante entender a diferença entre o
trabalho realizando por um filtro fazendo NAT de redirecionamento e um proxy reverso.
No caso do NAT, a conexão do cliente é redirecionada e este obtém um contato direto
com o servidor, como pode ser visto na Figura 17.

Figura 17 - Um NAT de redirecionamento.

No caso do proxy reverso, a requisição do cliente chega até ele (o proxy) e este
se encarrega de buscar os dados solicitados e entregar. Com isso, não há o contato
direto entre cliente e servidor. Há uma falsa situação de NAT porque o endereço IP que
20 Disponível em <http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzaie/ \
rzaieproxytypes.htm>. Acesso em 01 dez. 09.
chega ao servidor é o do proxy e não o do cliente. Esta situação pode ser vista na Figura
18.

Figura 18 - Um proxy reverso atuando.

Em sistemas de firewall, os proxies reversos não precisam estar in-line. Eles

podem ser colocados em paralelo, desde que haja uma filtro no servidor a ser "proxiado"
que só permita conexões oriundas do proxy.
Um outro fato relevante que deve ser observado é que determinados programas
servidores de rede também podem atuar como proxy reverso. A seguir, três casos bem
conhecidos:
• Alguns servidores de páginas podem atuar como proxy reverso HTTP,
bastando ativar a configuração específica. É o caso do servidor Apache21.
• Qualquer servidor DNS realizando queries forward para outro DNS atua
como proxy reverso. Isso porque quando um DNS está em forward, ao
receber uma pergunta de um cliente, ele sempre perguntará a outro DNS e
entregará a resposta ao cliente, servindo como intermediário.
• Qualquer servidor SMTP executando relay para outro SMTP também estará
atuando como proxy, uma vez que receberá os e-mails oriundos do cliente e
os encaminhará ao próximo SMTP. Então, será um intermediário.
No entanto, deve-se tomar o cuidado de não usar um determinado programa
servidor para ser proxy reverso de um servidor de rede que esteja servindo dados com o
mesmo programa. Exemplo: não se deve utilizar um proxy Apache com um servidor de
páginas Apache ou um DNS Bind22 fazendo forward para outro DNS Bind. Isso porque
se houver alguma falha de segurança no Bind, por exemplo, este será invadido e, em
consequência, o servidor final, que é igual ao proxy, também estará comprometido.
No momento da montagem de uma rede, o endereço IP que deverá ser
distribuído pelos servidores DNS será o do proxy reverso. O proxy reverso, ao receber
uma requisição de um cliente, buscará os dados solicitados no servidor que contenha a
informação desejada.

4.4. IDS
O Intrusion Detection System é um elemento de firewall que tem a tarefa de analisar o
tráfego de rede, principalmente payload da camada 7, registrando em log os eventos
considerados maliciosos, como ataques ou requisições irregulares. Não há qualquer
bloqueio de tráfego.
Os IDS são elementos extremamente detalhistas, fornecendo toda a informação
possível sobre o ocorrido. Muitos falsos positivos são gerados pelos IDS e isso deve ser

21 Disponível em <http://www.apache.org>. Acesso em 04 dez. 09.

22 Disponível em <http://www.isc.org>. Acesso em 04 dez. 09.
considerado normal, uma vez que um ser humano deverá analisar os logs para deduzir se
houve um ataque real ou não. Assim, não se deve fazer esforço para reduzir a quantidade
de falsos positivos. Em caso de dúvida, por parte do IDS, é melhor que apareça algo nos
logs para que o gerente de segurança da rede possa fazer uma análise.
Para que o IDS atue, o tráfego deverá passar por ele. A melhor forma de se fazer
isso é colocando tal IDS em uma máquina in-line, em modo bridge. O IDS deverá colher
dados em apenas uma das placas de rede para não haver constante duplicidade e para
não esgotar a capacidade de processamento da máquina.
Há ainda os HIDS (Host-based IDS), que são IDS colocados diretamente em
máquinas servidoras. Em princípio, todo IDS pode atuar como HIDS.
Apesar dos IDS atuarem na camada 7, para realizar o seu trabalho, eles devem
entender os dados das camadas 3 e 4.

4.5. IPS
O Intrusion Prevention System é um elemento similar ao IDS com três pequenas
diferenças:
• Bloqueia o tráfego malicioso.
• Não pode gerar falsos positivos.
• Tem que ser mais rápido do que um IDS, gerando logs menos detalhados.
Em virtude do IPS não poder gerar falsos positivos, o que bloquearia tráfego
legítimo, a política deverá ser diferente da utilizada para criar regras no IDS. Em
consequência, depois de todo IPS deverá haver um IDS. O objetivo é identificar nos logs
do IDS todo o tráfego malicioso que não foi bloqueado pelo IPS. Isso será muito útil
para gerar novas regras.
Os IPS que atuam como bridge são conhecidos como scrubbers. Eles atuam
silenciosamente e, por não possuírem endereço IP e não produzirem respostas, são
considerados invisíveis. Um exemplo é o HLBR23, que pode, inclusive, utilizar
expressões regulares nas suas regras.
É importante ressaltar que o conceito de IPS é relativamente recente (em torno
do ano de 2002) e que referências antigas poderão versar sobre IDS reativos e outros
aparatos obsoletos.

4.6. Detectores de port scan

O port scan ou “escaneamento” de portas é uma atividade que visa a obtenção de uma
relação de portas abertas em um servidor de rede. Muitas vezes, esse é o primeiro passo
para um ataque remoto. Os detectores de port scan tentam descobrir e bloquear as
tentativas de “escaneamento”.
Há também outro tipo de "escaneamento", mais simples, cujo objetivo é levantar
o endereço IP de máquinas ativas numa rede.

23 Disponível em <http://hlbr.sf.net>. Acesso em 01 dez. 09.

4.7. Antivírus
Antivírus também podem ser utilizados como elementos de firewall. O tráfego oriundo
de websites, por exemplo, pode ser analisado ao entrar na rede. Isso será útil para evitar
que máquinas Windows de usuários sejam contaminadas.

4.8. Verificadores de integridade de arquivos

Muitas invasões em rede são identificadas pelos administradores de tais redes quando
evidências de grande vulto são deixadas. É o que ocorre no caso dos defacements.
Defacements são alterações feitas por invasores (crackers, erroneamente chamados de
hackers) em websites. A Figura 19 mostra o site de um governo estadual do Brasil, após
um defacement ocorrido no início de dezembro de 2009.

Figura 19 - Exemplo de defacement. Fonte: [ZONE-H.ORG, 2009]24.

Como já foi dito, graças ao defacement, o administrador de rede rapidamente

detectou a invasão. O problema maior teria ocorrido se o invasor não tivesse deixado
rastros. Esse tipo de situação faz com que um servidor seja dominado remotamente até
mesmo por anos, tendo suas informações e sistema operacional comprometidos. Esse é o
pior caso de invasão: a que ocorreu e ninguém ficou sabendo.
Verificadores de integridade de arquivos são elementos que atuam localmente
(em cada host), montando um banco de dados de arquivos e das suas propriedades
(como os seus hashes, por exemplo). Com base nesse banco de dados, os verificadores
de integridade monitoram constantemente os arquivos. A partir disso, qualquer alteração
ocorrida é imediatamente comunicada ao administrador de rede e/ou segurança,

24 Disponível em <http://www.zone-h.org/archive/special=1>. Acesso em 03 dez. 09.

permitindo que este adote providências. Assim sendo, uma invasão dificilmente
permanecerá em sigilo.
É importante reafirmar que o verificador de integridade deverá ser instalado em
cada servidor da rede e também nos hosts do sistema de firewall.

4.9. Resumo da atuação de elementos de firewall

A Tabela 2 mostra um resumo sobre a atuação dos principais elementos de firewall, em
relação ao modelo OSI.
Tabela 2 - Atuação dos elementos de firewall
Elemento Camada 2 Camada 3 Camada 4 Camada 7
• Instala (alguns). • Instala (maioria).
Filtro de pacotes • Atua. x-x-x
• Atua. • Atua.
• Instala (alguns). • Instala (maioria).
Filtro de estados • Atua. x-x-x
• Entende. • Atua.
• Instala.
Proxy x-x-x x-x-x • Atua.
• Entende.
• Instala.
IDS e HIDS • Instala. • Entende. • Atua.
• Entende.
• Instala (alguns).
IPS • Instala (alguns). • Entende. • Atua.
• Entende.
• Instala.
Port scan detector x-x-x • Atua. x-x-x
• Atua.
Antivírus • Instala. x-x-x x-x-x • Atua.
• Instala.
Verificadores de integridade. x-x-x x-x-x x-x-x
• Atua.

Na Tabela 2, a seguinte legenda pode ser utilizada para o entendimento:

• Instala: o elemento de firewall se instala nesta camada para colher dados.
• Entende: o elemento de firewall entende os dados existentes nesta camada
(total ou parcialmente.)
• Atua: o elemento de firewall tem a sua atuação principal nesta camada,
realizando bloqueios de tráfego, por exemplo.

5. Exemplo de topologia de sistemas firewall

A composição dos sistemas de firewall irá depender do nível de proteção desejado, do
que deverá ser protegido e dos tipos de elementos utilizados. No exemplo de topologia
mostrado na Figura 20, é possível ver um sistema de firewall interligando quatro redes: a
Internet, a rede de usuários internos, a DMZ e a rede de servidores internos, composta
atualmente apenas por um servidor FTP.
 Figura 20 - Um exemplo de topologia de firewall.

Todos os IPS e IDS mostrados na Figura 20 estão em bridge. Com isso, esses
IPS e IDS, por estarem instalados na camada 2 do modelo OSI, e em consequência não
possuírem endereço IP, são considerados invisíveis. No entanto, os IPS só serão
realmente invisíveis se descartarem o tráfego malicioso silenciosamente, sem enviar
qualquer aviso sobre esse fato para o atacante. IPS e IDS invisíveis, em princípio, devem
ser colocados antes dos filtros de pacotes, proxies e outros elementos de firewall, a fim
de proteger os mesmos.
Um dos mais importantes princípios de segurança é o de que ninguém é
confiável, nem mesmo os usuários internos. Então, deve haver uma preocupação de
proteção contra ataques internos. Funcionários insatisfeitos, por exemplo, podem realizar
ataques de vulto.
Como já foi dito, na Figura 20, os IPS e IDS, ambos em bridge, protegem os
demais elementos de firewall. Exceção feita ao roteador WAN, que pertence à empresa
de telecomunicações. No entanto, esse roteador está enquadrado no sistema de firewall
da rede por possuir regras de filtragem e tráfego (ACL ou Active Control List). Caso
não houvesse ACLs, o roteador WAN não faria parte do sistema de firewall.
No sentido Internet - usuários, há um filtro de pacotes em um roteador (ambos na
camada 3, rede) que realiza a operação de NAT de redirecionamento para quem chega e
NAT de mascaramento para quem sai da rede. Além disto, esse filtro de pacotes (e
também estados, se for o caso) também possui regras bloqueando alguns tipos de
tráfegos. Ele permite o acesso da Internet e dos usuários à DMZ. Esse mesmo filtro,
agora atuando como filtro de estados, permite o acesso da Internet e da DMZ, de forma
restrita, aos usuários internos (apenas respostas a conexões iniciadas pelos usuários). É
princípio fundamental que a DMZ e a Internet, por iniciativa própria, não tenham acesso
às redes internas. Esse filtro também pode impedir o acesso da Internet ao servidor FTP
quando o tráfego não se tratar de resposta a uma solicitação de tal servidor.
É muito importante ressaltar que o NAT de redirecionamento não deve ser feito
de host para host mas sim de porta para porta. Considerando-se a máquina filtro de
pacotes citada, esta não deve redirecionar tudo que nela chegar para a máquina X, por
exemplo. O correto é redirecionar tudo o que chegar na porta 80 da máquina filtro, por
exemplo, para a porta 80 da máquina X. Isso evitará que qualquer outra porta aberta na
máquina X seja acessada de forma inoportuna por alguém da Internet.
A próxima máquina contém três elementos: um filtro de pacotes, um proxy
HTTP de encaminhamento transparente e um antivírus. Os objetivos são controlar o
acesso de usuários a sites da Internet, gerar um log de acessos, acelerar a navegação por
intermédio do uso de cache, controlar o uso do servidor FTP pelos usuários e detectar
possíveis vírus e worms em sites.
Depois da máquina anterior, com o objetivo de dar proteção a ela, aos servidores
da DMZ e servidor FTP, contra ataques de usuários, há uma dupla IPS-IDS em bridge.
Ainda, antes do servidor FTP e cada servidor da DMZ há um proxy reverso, evitando o
contato direto cliente-servidor.
Finalizando, em cada servidor e elemento de firewall deverá ser instalado um
verificador de integridade de arquivos.

6. A influência da criptografia em sistemas de firewall

Em sistemas de firewall, criptografia em servidores é um problema de vulto. Ao
implementar criptografia em um servidor de páginas, por exemplo, somente o cliente e o
servidor entenderão as informações contidas nos payloads trafegados. Com isso, o canal
criptografado estabelecido cega parte do sistema de firewall, ou seja, os proxies, IDS e
IPS não serão capazes de analisar o conteúdo e identificar ameaças. Em outras palavras,
isso cria um canal seguro de ataque para o inimigo. A Figura 21 ilustra essa situação.
É importante ressaltar dois aspectos:
• O primeiro é que somente o payload é criptografado. Se o cabeçalho dos
pacotes fossem criptografados, estes ficariam perdidos na rede.
• Só se usa criptografia quando há extrema necessidade. Exemplo: em um site
de vendas, no momento da digitação de usuário e senha.
A solução para servidores que necessitam de criptografia é estabelecer tal
criptografia entre o cliente e o proxy reverso. Entre o proxy reverso e o servidor, o canal
estará aberto (sem criptografia) e, nesse ponto, deverão ser colocados um IDS e um IPS.
 Figura 21 - Criptografia x firewall.

O HIDS, citado anteriormente, pode ser colocado diretamente na máquina

servidora, dispensando um IDS.

7. Elementos de firewall em Software Livre

É possível encontrar diversos elementos de firewall com licenciamento livre. Alguns
deles:
• Filtros de pacotes: Netfilter, ebtables e PF.
• Filtro de estados: Netfilter e PF.
• IDS: Snort.
• IPS: HLBR e Snort in-line.
• Proxy HTTP: Squid, Apache e pound.
• Proxy FTP: ftp-proxy e frox.
• Proxy DNS: totd, dnsmasq e Bind.
• Proxy SMTP: ProxSMTP e Sendmail.
• Detector de port scan: psad e PortSentry.
• Detectores de conteúdo: OpenDPI e L7-Filter.
• Antivírus: hapv e Clamav.
• Verificadores de integridade: samhain, bsign, systraq ,tripwire, aide, fcheck e
osiris.
Uma relação mais completa e com mais dados sobre cada elemento de firewall
pode ser encontrada em http://tiny.cc/elementos_firewall.
8. Honeypots e honeynets
Honeypot é uma máquina criada para atrair a atenção de atacantes de redes. Um
conjunto de honeypots forma uma honeynet, ou seja, uma rede composta por honeypots.
Há vários motivos que levam à montagem de uma honeynet e, dentre todos, o
que mais interessa a um gerente de segurança é o estudo de ações de atacantes para
buscar o fortalecimento do seu sistema de firewall. Para atingir esse objetivo, a honeynet
deve ser montada fora da rede real, em paralelo com a mesma, como mostra a Figura 22.

Figura 22 - Um exemplo uso de honeynet.

A honeynet deverá conter o mesmo padrão de configuração da rede real com a

mesma arquitetura de segurança. Por exemplo: para estudar os possíveis ataques ao
servidor de e-mail, um servidor de e-mail idêntico ao real (versão, configuração etc.)
deverá ser colocado na honeynet. Na sua frente deverá existir o mesmo proxy reverso,
IPS etc. A única diferença para a rede real é que este servidor copiado não estará
declarado em nenhum lugar. Então, um atacante só poderá descobri-lo se estiver
"escaneando" a rede. Em outras palavras, quem chega a um servidor que não possui o
seu endereço IP divulgado está mal intencionado.
Sensores deverão ser colocados imediatamente antes do proxy reverso, a fim de
detectar e gravar as atitudes do atacante. A melhor opção é uma máquina contendo um
bom IDS criando logs e o utilitário tcpdump25 gravando todo o tráfego destinado ao
servidor alvo. Isso poderá ser feito com a seguinte linha de comando (ou adaptação da
mesma):
# tcpdump -n -s0 -w /root/trafego.dump

O tráfego gravado poderá ser analisado com o auxílio do programa Wireshark26.

9. Conclusão
A evolução da informática e a dependência da mesma pelo ser humano criou um novo
problema: a insegurança virtual. Atualmente, vive-se em rede. Vai-se ao banco em rede,
pede-se comida em rede, compra-se um MP3 player diretamente do Japão em rede. Com
essa faceta da vida moderna, cresce cada vez mais a necessidade de segurança. Na rede,
isso pode ser obtido por intermédio de um sistema de firewall.
Sistemas de firewall são mecanismos complexos, utilizados para prover
segurança às redes. É preciso haver a inspeção completa de cada pacote, analisando
cabeçalhos e payloads, buscando descobrir todos os riscos que os mesmos possam

25 Disponível em <http://www.tcpdump.org>. Acesso em 04 dez. 09.

26 Disponível em <http://www.wireshark.org>. Acesso em 04 dez. 09.
oferecer. A técnica da defesa em profundidade deve ser utilizada, para evitar que algum
elemento do firewall trabalhe mal ou favoreça uma intrusão. Diante de tal situação, é
importante afirmar que é impossível implementar um firewall com apenas uma máquina.
Um cuidado a ser observado é quanto ao uso de criptografia. Esse artifício cria
um ambiente de segurança para o usuário, mas cega parte do sistema de firewall; assim,
só deverá ser utilizado em caso de extrema necessidade.
A leitura de logs, principalmente em IDS, e a busca constante por informações
atualizadas sobre ataques, em boletins de segurança, por exemplo, deve fazer parte da
vida do gerente de segurança. Com base nisto, novas regras em IPS e proxies poderão
ser criadas quase que diariamente, até que o de bloqueio de ameaças esteja perfeitamente
ajustado. A partir disto, manutenções menos frequentes mas necessárias deverão ser
feitas.
Por fim, toda a rede, incluindo o sistema de firewall, deverá ser constantemente
atualizada. Isso evitará a permanência de bugs nocivos à segurança global de tal rede.

10. Referências bibliográficas

10.1. Referências citadas neste artigo

CHESWICK, William R.; BELLOVIN, Steven M.; RUBIN, Aviel D. Firewalls and
Internet security. Addison-Wesley, 2ª edição, 2003.

CNN.COM. Hackers stole data on Pentagon's newest fighter jet. CNN.com/US,

2009. Disponível em <http://www.cnn.com/2009/US/04/21/pentagon.hacked \
/index.html>. Acesso em 22 nov. 2009.

COMER, Douglas E. Interligação em rede com TCP/IP. Campus, 3ª edição, 1998,

tradução.

EYCHENNE, Herve. Iptables - administration tool for IPv4 packet filtering and
NAT. Linux manpages, 2008.

FOLHAONLINE. Ataques virtuais aumentaram 40% nos computadores do

governo dos EUA. Folha on line, 2009. Disponível em
<http://www1.folha.uol.com.br/folha/informatica/ult124u505493.shtml>. Acesso em
22 nov. 2009.

FOROUZAN, Behrouz A. TCP/IP Protocol Suite. McGRAW-HILL, 3ª edição, 2007.

GORALSKI, Walter. The Illustrated Network. Morgan Kaufmann, 2009.

HEADER DRAWINGS. Header Drawings. Disponível em <http://www.fatpipe.org/ \

~mjb/Drawings>. Acesso em 29 nov. 2009.

IANA. ICMP type numbers. Disponível em <http://www.iana.org/assignments/icmp-

parameters>. Acesso em 29 nov. 2009.

______. Port numbers. Disponível em <http://www.iana.org/assignments/port-

numbers>. Acesso em 29 nov. 2009.
______. Protocol numbers. IANA, 2009. Disponível em <http://www.iana.org/ \
assignments/protocol-numbers>. Acesso em 22 nov. 2009.

IBM. Proxy server types and uses for HTTP Server. Disponível em
<http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzaie/ \
rzaieproxytypes.htm>. Acesso em 02 dez. 09.

JORNAL DA GLOBO.COM. Brasil está em quinto lugar em ataques maliciosos na

Internet. Globo.com, 2009. Disponível em <http://tiny.cc/jornal_globo_brasil_ \
quinto_lugar_ataques>. Acesso em 22 nov. 2009.

NIC.BR. Denúncias de pirataria na internet aumentam sete vezes no Brasil. NIC.br,

2009. Disponível em <http://www.nic.br/imprensa/clipping/2009/midia031.htm>.
Acesso em 22 nov. 2009.

RFC 768. User Datagram Protocol. DARPA, 1980. Disponível em <http://www.rfc-

editor.org/rfc/rfc768.txt>. Acesso em 29 nov. 2009.

RFC 791. Internet Protocol. DARPA, 1981. Disponível em <http://www.rfc-editor.org/

rfc/rfc791.txt>. Acesso em 22 nov. 2009.

RFC 793. Transmission Control Protocol. DARPA, 1981. Disponível em

<http://www.rfc-editor.org/rfc/rfc793.txt>. Acesso em 29 nov. 2009.

SANS. The OSI model: an overview. Disponível em <http://www.sans.org/ \

reading_room/whitepapers/standards/the_osi_model_an_overview_543>. Acesso em
29 nov. 2009.

STEVENS, W. Richard. TCP/IP Illustrated, Volume 1 - The protocols. Addison-

Wesley, 1994.

ZWICKY, Elizabeth D.; COOPER, Simon; CHAPMAN, D. Brent. Building Internet

firewalls. O'Reilly, 2ª edição, 2000.

10.2. Referências adicionais indicadas para pesquisas e autoaprendizado

ARAÚJO, André Bertelli; MOTA FILHO, João Eriberto. HLBR - Hogwash Light BR.
SourceForge.net, 2005. Disponível em <http://hlbr.sf.net>. Acesso em 01 dez. 2009.

______. HLBR - O emprego de uma bridge como IPS para a segurança em redes
de computadores. Eriberto.pro.br, 2006. Disponível em <http://www.eriberto.pro.br/
artigos/hlbr_wsl2006.pdf>. Acesso em 01 dez. 2009.

CARVALHO, Eric Barbosa Jales de. Ferramentas de resposta a incidentes de

segurança. RNP, 2009. Disponível em <http://www.pop-pi.rnp.br/artigos/ \
ferramentas_respostas_incidentes%20-%20eric.pdf>. Acesso em 03 dez. 2009.
HOEPERS, Cristine Hoepers; STEDING-JESSEN, Klaus; CHAVES, Marcelo H. P.
Honeypots e honeynets: definições e aplicações. CERT.br, 2007. Disponível em
<http://www.cert.br/docs/whitepapers/honeypots-honeynets>. Acesso em 04 dez.
2009.

MOTA FILHO, João Eriberto. Análise e controle de tráfego em redes TCP/IP.

Novatec, em edição, previsão 2010.

______. Criação de uma bridge no Debian GNU/Linux. Eriberto.pro.br, 2009.

Disponível em <http://tiny.cc/bridge_debian>. Acesso em 01 dez. 2009.

______. Descobrindo o Linux. Novatec, 2ª edição, 2007.

______. Palestra Análise de tráfego em redes TCP/IP com tcpdump. Eriberto.pro.br,

2009. Disponível em <http://www.eriberto.pro.br/palestras>. Acesso em 01 dez.
2009.

______. Palestra IPS HLBR: aprimorando a segurança da sua rede. Eriberto.pro.br,

2008. Disponível em <http://www.eriberto.pro.br/palestras>. Acesso em 01 dez.
2009.

______. Palestra Sistemas de Firewall. Eriberto.pro.br, 2008. Disponível em

<http://www.eriberto.pro.br/palestras>. Acesso em 01 dez. 2009.

______. Proxy reverso HTTP com Squid (versão 2.6 ou superior). Eriberto.pro.br,
2009. Disponível em <http://tiny.cc/proxy_reverso_squid>. Acesso em 01 dez. 2009.

NAKAMURA, Emilio Tissato; GEUS, Paulo Lício de. Segurança de redes em

ambientes cooperativos. Novatec, 2007.

NIST. Special publications (800 series). NIST.gov, 1995-2009. Disponível em <http://

csrc.nist.gov/publications/PubsSPs.html>. Acesso em 04 dez. 2009.

TCPDUMP. Tcpdump/libpcap. tcpdump.org, 2009. Disponível em

<http://www.tcpdump.org>. Acesso em 01 dez. 2009.

TECH FAQ. Understanding Network Attacks. techFAQ.com, ?. Disponível em

<http://www.tech-faq.com/network-attacks.shtml>. Acesso em 04 dez. 2009.