AULA 4

Prévia do material em texto

REDES IV – SISTEMA DE 
PROTEÇÃO E SEGURANÇA DE 
REDES 
AULA 4 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Luis José Rohling 
 
 
2 
 
CONVERSA INICIAL 
Com relação ao Firewall de rede, podemos implementar essa 
funcionalidade em um roteador Cisco ou utilizar um servidor com uma aplicação 
de Firewall, tal como o iptables, que é uma ferramenta já incorporada ao sistema 
operacional Linux, conforme vimos anteriormente. E nesses dois modelos, uma 
configuração inicial básica foi a criação de regras de permissão ou de negação 
de tráfego, que era chamado de Firewall de Filtro de Pacotes. Porém, esse 
modelo de configuração é muito trabalhoso e também muito limitado, em função 
do aumento da complexidade das aplicações e da evolução das ameaças à 
segurança da rede e dessas aplicações. 
Assim, as soluções de Firewall sofreram uma evolução ao longo do tempo, 
iniciando como um filtro de pacotes, com a criação de regras de permissão, 
evoluindo para o Stateful Firewall, que realizava o acompanhamento do 
estabelecimento das sessões, chegando ao Firewall de aplicação. E essa 
evolução, além de implementar uma operação mais automatizada do processo 
de inspeção e permissão do tráfego, com uma configuração menos complexa e 
menos trabalhosa, também aumentou o nível de segurança dos Firewalls, 
acompanhando a complexidade da evolução das ameaças. 
Figura 1 – Operação do Stateful Firewall 
 
Para entendermos esse processo de acompanhamento das sessões, é 
necessário então conhecer a dinâmica dos processos de comunicação dos 
INTERNET 
Rastreio das 
sessões 
Permite o 
retorno 
 
 
3 
diversos protocolos e aplicações, que é a base para a operação do Stateful 
Firewall. Assim, nesta aula, estudaremos a dinâmica de comunicação dos 
principais protocolos do modelo TCP/IP. 
Para garantir a confiabilidade no processo de comunicação, a maioria das 
aplicações utiliza o protocolo TCP na camada de transporte. Dessa forma, para 
entendermos como o Firewall realiza o acompanhamento das sessões, 
estudaremos o processo de estabelecimento, acompanhamento e encerramento 
de sessões realizado pelo protocolo TCP, e também a diferença entre o protocolo 
TCP e UDP em relação a esse processo de acompanhamento realizado pelo 
Firewall. 
Além dos protocolos de transporte, temos também outros dois protocolos 
essenciais para a comunicação na rede, que são o DNS, para a resolução de 
nomes, e o protocolo ICMP, que permite o acompanhamento do 
encaminhamento do tráfego através da rede e suas eventuais falhas. Assim, 
também estudaremos a dinâmica de troca de mensagens desses protocolos, de 
modo que possamos realizar a configuração correta em um firewall do tipo filtro 
de pacotes, permitindo as mensagens necessárias para o correto funcionamento 
desses protocolos. 
E sendo o Firewall clássico a evolução do modelo de Firewall que pode 
ser configurado em um roteador Cisco, nesta aula também estudaremos a 
operação e configuração desse recurso, bem como o conceito da rede DMZ – 
Demilitarized Zone, sua operação e configuração. 
Para a implementação da segurança na rede interna, temos também o 
modelo de implementação do chamado Firewall interno, que realiza a filtragem 
do tráfego entre as redes internas, quando temos esse tipo de segmentação. E 
a implementação desse Firewall interno pode ser realizada por um dispositivo 
que é utilizado também para a segurança do tráfego externo ou em um modelo 
distribuído, com a aplicação de Firewall instalada nos servidores e máquinas 
virtuais, de acordo com a política de segurança da empresa. Assim, nesta aula, 
também estudaremos o modelo de implementação do chamado Firewall definido 
por serviço, que é aplicado nos ambientes virtualizados. 
E para a segurança da rede interna, temos também a implementação em 
equipamentos Cisco, com a utilização do modelo chamado ZBF – Zone Based 
Firewall, que faz a segmentação da rede interna de acordo com a política de 
 
 
4 
segurança, aplicando as regras de tráfego entre essas zonas, cujos conceitos 
básicos estudaremos também nesta aula. 
TEMA 1 – OPERAÇÃO DO FIREWALL CLÁSSICO 
A implementação do recurso de segurança chamado de Firewall Clássico 
em um roteador Cisco provê quatro funcionalidades distintas, que são: 
• Inspeção de tráfego. 
• Filtragem de tráfego. 
• Detecção de intrusão. 
• Geração de alertas e mensagens para auditoria. 
Assim, o Firewall Clássico representa uma grande evolução em relação à 
utilização das ACLs reflexivas, pois também realiza uma monitoração efetiva do 
tráfego, de acordo com o processo de comunicação estabelecido por cada tipo 
de protocolo, conforme veremos a seguir. 
Uma das ações básicas de todos os Firewalls do tipo Stateful Firewall é a 
monitoração das seções TCP, que implicará na identificação da abertura de uma 
nova seção, o acompanhamento do envio e recebimento dos segmentos, através 
dos números de sequência e de confirmação, e o encerramento das seções. 
O processo de comunicação do protocolo TCP está baseado no envio de 
números de sequência e de confirmação, o que permite o controle dos quadros 
recebidos e a solicitação de retransmissão, no caso de perda desses quadros, 
além do mecanismo de controle de janela de transmissão, que define a 
quantidade de segmentos enviados até o aguardo da confirmação do 
recebimento dos segmentos já enviados. 
1.1 Estabelecimento de sessão TCP 
O estabelecimento de uma sessão TCP ocorre em três etapas, 
chamadas de Handshake triplo, que consiste em: 
• Etapa 1: o cliente que está iniciando a sessão envia uma requisição para 
o servidor, enviando uma mensagem inicial contendo o seu número de 
sequência e com o bit de Flag SYN setado, indicando que está iniciando 
uma nova sessão. 
 
 
5 
• Etapa 2: o servidor confirma a abertura da sessão, enviando uma 
mensagem para o cliente contendo o seu número de sequência, o número 
de confirmação e com os bits de Flag SYN e ACK setados, indicando a 
confirmação do processo de sincronismo inicial. 
• Etapa 3: O cliente confirma a abertura da seção, enviando uma 
mensagem com o Flag de ACK setado, indicando a confirmação do 
processo de sincronismo inicial pelo cliente. 
E nesse processo de estabelecimento de sessão, termos ainda as demais 
informações dos cabeçalhos de camada de transporte, que são as portas de 
origem e de destino, e as informações do cabeçalho da camada de rede, que 
são os endereços IP de origem e de destino. Dessa forma, o Firewall, ao detectar 
uma solicitação de estabelecimento de sessão vindo da rede interna em direção 
à rede externa, irá registrar essas informações, permitindo então o retorno da 
resposta esperada, conforme mostrado a seguir. 
Figura 2 – Exemplo de estabelecimento de sessão TCP 
 
IP Origem 192.168.10.1 
IP Destino 172.16.1.100 
Porta Origem 3.456 
Porta Destino 443 
Número de sequência 100 
Número de confirmação - 
Flags TCP SYN 
 
No exemplo acima, o Firewall irá registrar os parâmetros listados e 
permitirá o retorno de um pacote da Internet que corresponda à resposta 
INTERNET 
192.168.10.1
0 172.16.1.100 
 
 
6 
esperada, ou seja, quando os endereços e portas de Origem e Destino 
correspondem ao inverso do pacote de saída, o número de confirmação é o 
número de sequência incrementado e os Flags do TCP o SYN e o ACK, pois 
essa é a resposta esperada para o processo de abertura de uma nova sessão. 
Assim, o pacote recebido, e que será permitido pelo Firewall, deverá conter os 
parâmetros mostrados na figura abaixo. 
Figura 3 – Resposta esperada, permitida pelo Firewall 
 
IP Origem 172.16.1.100 
IP Destino 192.168.10.1 
Porta Origem 443 
Porta Destino 3.456 
Número de sequência 200 
Número de confirmação 101 
Flags TCP SYN, ACK 
 
Caso algum dos parâmetros mostrados acima não correspondam aos 
valores esperados, o Firewall fará o bloqueio do pacote IP recebido. No 
estabelecimento de uma sessão, o único parâmetro desconhecidoinicialmente 
será o número de sequência do Servidor, porém, o número de confirmação 
deverá corresponder ao valor do pacote enviado pelo cliente, acrescido de uma 
unidade, pois esse número de confirmação no protocolo TCP corresponde 
sempre ao próximo segmento esperado. 
 
INTERNET 
192.168.10.1
0 172.16.1.100 
 
 
7 
1.2 Acompanhamento das conexões TCP e UDP 
Estabelecida a sessão TCP, o acompanhamento do envio e recebimento 
dos segmentos TCP será realizado baseado nos números de sequência e de 
confirmação, cujo processo também dependerá de outro campo do cabeçalho 
TCP, que é o tamanho de janela. Assim, o cliente TCP fará as requisições ao 
servidor, incrementando o tamanho de janela a cada confirmação. Dessa forma, 
o servidor enviará a quantidade de segmento informada no campo tamanho de 
janela, para então aguardar a confirmação do cliente. Portanto, o Firewall deverá 
registrar o tamanho de janela informado pelo cliente para então permitir o retorno 
da quantidade de pacotes informada por ele, que corresponderão aos números 
de sequência contados a partir do número de confirmação enviado pelo cliente. 
Por exemplo, se o cliente enviar um segmento TCP com o número de 
confirmação igual a 200 e um tamanho de janela igual a 20, o Firewall deverá 
permitir o retorno dos próximos 20 segmentos, que deverão estar numerados de 
200 a 219, e com endereço IP de origem igual ao endereço de destino do pacote 
enviado pelo cliente. 
Figura 4 – Acompanhamento de sessão TCP 
 
Após enviar o último segmento do processo de comunicação, de acordo 
com a aplicação, o protocolo TCP irá encerrar a sessão, enviando um segmento 
com o flag de FIN setado. E esse processo de encerramento de sessão também 
será realizado com a troca de mensagens de confirmação, sendo enviado um 
FIN e ACK pelo cliente, e um ACK final pelo servidor. Dessa forma o Firewall 
INTERNET 
192.168.10.1
0 172.16.1.100 
Número de confirmação: 200 
Janela: 20 
Permitidos pacotes de 172.16.1.100 
Números de sequência: 200 a 219 
 
 
8 
acompanhará também essas trocas de mensagem, de encerramento de sessão, 
passando a bloquear todos os demais pacotes, ou seja, fechando essa porta de 
entrada para a rede interna. 
Para o acompanhamento das conexões através do protocolo UDP, como 
esse protocolo não opera com o estabelecimento de sessão e temos menos 
campos no cabeçalho UDP, o processo de controle é muito mais simples, pois o 
cabeçalho inclui apenas os campos de porta de origem e de destino para esse 
acompanhamento do Firewall. Assim, normalmente, o controle de tráfego UDP 
também incluirá o processo de temporização, de acordo com a aplicação. Dessa 
forma, ao detectar uma solicitação UDP de um cliente em direção à rede externa, 
o Firewall irá registrar os endereços e porta de origem e destino, permitindo o 
retorno da resposta dentro de um período de tempo pré-definido. Assim, se a 
resposta for recebida após esse tempo máximo, essa resposta será bloqueada. 
Dessa forma, tanto para as sessões TCP quanto para as requisições UDP, 
o Firewall abrirá uma porta de retorno para a rede interna, o que representa uma 
vulnerabilidade da rede, pois o atacante poderá utilizar essas “portas” abertas no 
Firewall para o acesso indevido aos hosts da rede interna. Assim, caso o hacker 
capture um pacote de saída da rede, conhecendo o comportamento padrão do 
Firewall, poderá falsificar os parâmetros esperados pelo Firewall, enviando 
pacotes para o host interno. Assim, as sessões inativas também deverão ser 
encerradas, baseadas em regras de temporização, evitando a exposição da rede 
interna indevidamente. 
TEMA 2 – OPERAÇÃO DO FIREWALL PARA DNS E ICMP 
Outros dois protocolos amplamente utilizados nas redes, e que fazem 
parte da pilha de protocolos TCP/IP, são os protocolos DNS (Domain Name 
System) e ICMP (Internet Control Message Protocol). Portanto, os Firewalls 
deverão ter a capacidade de rastrear esses protocolos, de acordo com sua 
dinâmica de troca de mensagens, de modo que implemente a segurança 
necessária, permitindo apenas o tráfego que não represente nenhum tipo de 
ameaça para a rede interna. 
 
 
 
9 
2.1 Protocolo DNS 
O protocolo DNS é essencial para o processo de navegação na Internet e 
assim é muito visado pelos ataques maliciosos, sendo que um desses ataques 
é o ataque chamado de envenenamento por cache DNS, em que o atacante 
envia várias respostas a cada consulta, tentando prever ou forçar o ID da 
transação e a porta de origem UDP, para corromper o cache DNS. Assim, a 
segurança associada ao protocolo DNS inspeciona e encerra uma conexão 
DNS, gerada por uma consulta DNS originada na rede interna para a rede 
externa, assim que a primeira mensagem de resposta DNS seja recebida pelo 
firewall e encaminhada ao solicitante. O firewall também deverá monitorar a troca 
de mensagens, garantindo que os parâmetros da resposta DNS corresponda aos 
parâmetros da consulta inicial. E, além do recebimento da resposta da consulta 
DNS, a conexão também será encerrada caso não seja recebida a resposta DNS 
no tempo pré-determinado. 
A versão mais atual da publicação do IETF sobre o protocolo DNS é a 
RFC 6895, de abril de 2013, com o título Domain Name System (DNS) IANA 
Considerations. Esse documento apresenta as considerações da IANA (Internet 
Assigned Numbers Authority) em relação à alocação dos tipos de registro de 
recursos do DNS, as classes, os códigos de operação, os códigos de erro, os 
bits de cabeçalho de mensagem de protocolo DNS e os subtipos de registro de 
recursos AFSDB. 
Para entendermos o processo de troca de mensagens no protocolo DNS, 
é necessário conhecermos os campos do cabeçalho do protocolo, cujos valores 
serão utilizados pelo Firewall para a permissão ou bloqueio das mensagens 
desse protocolo. Assim, os principais campos contidos no cabeçalho do 
protocolo DNS são o ID, QR, OpCode e RCODE. E na estrutura do corpo das 
mensagens é que teremos os campos relativos aos dados do nome de domínio 
consultado. 
O Campo ID, contido no cabeçalho, identifica o número da consulta e da 
resposta enviada pelo servidor. Assim, o Firewall deverá registrar esse ID da 
consulta, permitindo o retorno de apenas uma resposta, de modo a bloquear uma 
tentativa de envenenamento do DNS. E o outro campo que será utilizado pelo 
Firewall para rastrear as mensagens de DNS é o campo QR, que irá identificar 
se a mensagem é de consulta (Query) ou de Resposta (Response). 
 
 
10 
Figura 5 – Acompanhamento de consulta DNS 
 
Portanto, ao receber a consulta do DNS, o Firewall irá bloquear qualquer 
outra resposta recebida que tenha como ID o valor 12, com o campo QR 
indicando uma resposta e com o IP de origem igual a 8.8.8.8. Com isso, caso 
um atacante esteja tentando realizar um envenenamento de DNS, enviando 
pacotes de resposta DNS com o endereço falso de origem, que seria o 8.8.8.8, 
pois esse é um endereço amplamente utilizado na Internet para o serviço de 
DNS, quando o pacote gerado pelo atacante contiver o ID da consulta válida, 
que seria o valor 12, essa requisição já teria sido respondida pelo servidor de 
DNS autêntico, e essa mensagem falsa seria bloqueada pelo Firewall, conforme 
mostrado na figura abaixo. 
Figura 6 – Bloqueio de falsificação de DNS 
 
INTERNET 
192.168.10.1
0 8.8.8.8 
ID: 12 / QR = Q 
IP destino: 8.8.8.8.8 Servidor 
DNS 
ID: 12 / QR = R 
IP origem: 8.8.8.8.8 
ID: 12 / QR = R 
IP origem: 8.8.8.8.8 
INTERNET 
192.168.10.1
0 8.8.8.8 
Servidor 
DNS 
 
 
11 
Dessa forma, para bloquear os ataques baseados no protocolo DNS, o 
Firewall deverá permitir o retorno apenas da primeira resposta a cada uma das 
consultas registradas, ou seja, apenas uma resposta para cada ID. E caso o 
Firewall receba muitas respostas não solicitadas, teremos então a atuação de 
outro mecanismo de segurança, que é chamado de detecção de invasão, que 
será visto adiante. 
Na RFC6895, temos ainda uma observação de que a alocação dos 
parâmetros do protocolo DNS, da forma como é apresentada naquela RFC, é 
considerada não segura, indicando a adoção das recomendações contidas nas 
RFCs 4033, 4034 e 4035 para a implementação de segurança das mensagens. 
2.2 Protocolo ICMP 
Outro protocolo amplamente utilizado nas redes é o ICMP, que permite o 
teste e análise da rede, avaliando a alcançabilidade dos servidores e dispositivos 
de rede. Assim, o Firewall deverá identificar as mensagens ICMP e permitir o 
retorno das respostas ICMP vindos da rede externa, desde que correspondam 
às respostas esperadas. Porém, as mensagens de teste, vindas da rede externa, 
deverão ser bloqueadas, pois esse tipo de teste pode ser empregado pelos 
atacantes para identificar os potenciais alvos na rede interna. Assim, o Firewall 
deverá apenas permitir as mensagens que efetivamente correspondam às 
possíveis respostas de requisições feitas por dispositivos que estão na rede 
interna, ou referentes a um processo de encaminhamento de uma requisição 
para um serviço na rede externa. 
O protocolo IP possibilita a comunicação entre os hosts na rede Internet, 
sendo que essa comunicação ocorre através do encaminhamento dos pacotes 
IP pelos dispositivos de conexão de rede, que são chamados de gateways. E 
para que esses gateways possam estabelecer uma comunicação entre eles, 
para estabelecer os mecanismos de controle do encaminhamento de pacotes, 
deve ser empregado um protocolo do tipo GGP – Gateway to Gateway Protocol. 
Dessa forma, nesse processo de comunicação, um desses gateways, ou o 
próprio gateway de destino, eventualmente necessitará se comunicar com o host 
de origem para relatar um erro no processo de encaminhamento do pacote IP, 
por exemplo. E para permitir esse processo de comunicação, foi publicado o 
Protocolo de Mensagens de Controle da Internet, que é chamado de ICMP – 
Internet Control Message Protocol. O ICMP opera utilizando como suporte o 
 
 
12 
protocolo IP, na camada de rede, como se fosse um protocolo de camada 
superior. Porém, o ICMP, na realidade, faz parte do protocolo IP, sendo 
implementado por todos os dispositivos e gateways que estão utilizando o 
protocolo IP. 
As mensagens do protocolo ICMP podem ser enviadas em diversas 
situações. Por exemplo, para informar que um pacote IP não pode ser entregue 
ao seu destinatário, ou quando o gateway não tem espaço suficiente no buffer 
que seria utilizado para o encaminhamento do pacote, ou ainda, quando o 
gateway pode indicar para o host de origem que esse poderá enviar o tráfego 
por meio de uma rota mais curta. 
Como o protocolo IP não foi projetado para ser totalmente confiável, as 
mensagens de controle do ICMP permitem fornecer um feedback sobre os 
problemas no processo de comunicação, porém isso ainda não torna o protocolo 
IP confiável. Dessa forma, mesmo com o ICMP, ainda não temos garantia de 
que os pacotes IP serão entregues ao destinatário ou de que uma mensagem de 
controle efetivamente será enviada para o host de origem, caso a entrega não 
ocorra, os seja, alguns pacotes IP podem ser não entregues e não ser recebida 
nenhuma mensagem sobre a sua perda. Portanto, mesmo com o ICMP, os 
protocolos das camadas superiores, que utilizam o protocolo IP, devem 
implementar seus próprios mecanismos para garantir a confiabilidade do 
processo de comunicação, tal como o estabelecimento da sessão com o 
protocolo TCP. 
As mensagens do protocolo ICMP normalmente são geradas para relatar 
falhas no encaminhamento dos pacotes IP, sendo que, para evitar o envio 
contínuo de mensagens, em um processo infinito, o protocolo ICMP não envia 
mensagens sobre falhas na entrega das mensagens ICMP. E no processo de 
comunicação que envolva a fragmentação, quando um datagrama de camada 
superior necessita ser dividido em vários pacotes IP, as mensagens ICMP são 
enviadas apenas sobre falhas no encaminhamento do primeiro fragmento, que 
é o fragmento zero, não enviando as mensagens sobre os fragmentos 
posteriores. 
E as principais mensagens do protocolo ICMP, de acordo com a RFC 792 
do IETF, são: 
• Destination Unreachable Message: mensagem do tipo 3, indicando que a 
mensagem não foi entregue e que apresentará ainda um código indicando 
 
 
13 
a causa da não entrega, que pode ser rede inalcançável, host 
inalcançável, protocolo inalcançável, porta inalcançável, necessidade de 
fragmentação e falha de roteamento. 
• Time Exceeded Message: mensagem do tipo 11, gerada pelo roteador 
que ao fazer o decremento do campo TTL do pacote IP chegou ao valor 
igual a zero, e assim o pacote não foi mais encaminhado adiante. 
• Parameter Problem Message: mensagem do tipo 12, gerada caso o 
gateway ou o host, ao processar o datagrama, encontre um problema com 
os parâmetros do cabeçalho e não possa completar o processamento do 
datagrama, realizando o seu descarte. 
• Source Quench Message: mensagem do tipo 4, indicando que o pacote 
foi descartado por falta de espaço em buffer para o seu armazenamento 
ou que o destinatário não conseguiu processar o pacote. Essa mensagem 
indica ao remetente que esse deverá reduzir a taxa de envio de pacotes 
para o destino, para que não ocorram mais descartes. 
• Redirect Message: mensagem do tipo 5, envida por um gateway 
solicitando que o pacote seja encaminhado diretamente ao destinatário, 
pois pertence à mesma rede de origem do pacote. 
• Echo ou Echo Reply Message: mensagem do tipo 8, para mensagem de 
Echo, e do tipo 5, para mensagem de Echo Reply. O destinatário de uma 
mensagem do tipo Echo responderá com uma mensagem do tipo Echo 
Reply. 
• Timessamp ou Timessamp Reply Message: mensagem do tipo 13 para a 
mensagem de Timessamp e do tipo 14 para a mensagem Timessamp 
Reply. 
2.3 Operação do FW com o protocolo ICMP 
Portanto, poderemos ter o retorno de uma mensagem ICMP para diversos 
tipos de solicitações enviadas para a Internet e que deverão ser permitidas pelo 
Firewall. Por exemplo, quando um host da rede interna realizar uma solicitação 
de uma página web para um servidor na internet, teremos uma mensagem de 
saída conforme mostrado na figura abaixo. 
 
 
 
14 
Figura 7 – Requisição WEB 
 
Dessa forma, o Firewall deverá permitir o retorno dos pacotes IP que 
tiverem como endereço de origem o endereço 200.10.10.101, com origem na 
porta 80, com destino ao endereço 192.168.10.1 e porta 52135. E como essa 
comunicação acontecerá baseada no protocolo TCP, teremos o 
acompanhamento da sessão TCP com os números de sequência e de 
confirmação esperados. E ao finalizar essa sessão, teremos o handshake de 
encerramento da sessão, sendo bloqueados quaisquer outros pacotes vindos da 
Internet. Porém, caso a requisição inicial de abertura da sessão TCP, anterior ao 
envio da solicitação HTTP, não seja entregue ao servidor em função de alguma 
falha na rede, o Firewall receberá uma mensagem do protocolo ICMP, que terá 
como origem o endereço IP do gateway onde ocorreu a falha. Portanto, o Firewall 
deverá permitir que essa resposta seja encaminhada ao host de origem, pois se 
trata de uma mensagem de controle do processo de comunicação. E para validar 
essa mensagem, o Firewall deverá identificar que se trata de uma resposta 
ICMP, que terá no seu cabeçalho a identificação do tipo 3, que é o Destination 
Unreachable Message, incluindo a causa da falha, e cujo destino é o endereço 
IP do host que fez uma solicitação externa, nesse exemplo, o endereço 
192.168.10.1, porém o endereço de origem será indefinido, pois a mensagem 
poderá ser gerada por qualquer gateway da rede. 
 
INTERNET 
192.168.10.1
0 200.10.10.101 
IP Origem: 192.168.10.1 / Porta: 52.135 
IP destino: 200.10.10.101 / Porta: 80 Servidor 
WEB 
 
 
15 
Figura 8 – Retorno de mensagem ICMP 
 
No exemplo anterior, mesmo que o endereço IP de origem da mensagem 
ICMP seja diferente do endereço de destinoda requisição anterior, o Firewall 
deverá permitir o encaminhamento dessa mensagem até o host de destino. 
Além desse exemplo, teremos também as mensagens recebidas como 
resposta do próprio protocolo ICMP. Assim, quando um host da rede interna 
enviar uma mensagem do tipo 8, solicitando uma resposta ICMP de um host, 
deverá receber uma mensagem ICMP do tipo 0, que indica uma resposta a essa 
solicitação, conforme mostrado abaixo. 
Figura 9 – Acompanhamento das mensagens ICMP 
 
INTERNET 
192.168.10.1
0 200.10.10.101 
Mensagem ICMP Tipo: 3 (Destination Unreachable) 
IP Origem: 105.10.15.21 / IP destino: 192.168.10.1 
Servidor 
WEB 
INTERNET 
192.168.10.1
0 115.12.10.21 
ICMP Tipo: 8 (Echo) 
IP origem: 192.168.10.1 
IP destino: 115.12.10.21 
Servidor 
ICMP Tipo: 0 (Echo Replay) 
IP origem: 115.12.10.21 
IP destino: 192.168.10.1 
 
 
16 
Portanto, o Firewall deverá identificar também todos os tipos de 
mensagens ICMP, analisando os endereços de origem e de destino, bem como 
os tipos de mensagens, conforme identificado no cabeçalho das mensagens 
ICMP, para permitir ou bloquear esse tráfego, de acordo com esses parâmetros. 
TEMA 3 – CONFIGURAÇÃO DE FIREWALL CLÁSSICO 
Conforme vimos anteriormente, a implementação de um Firewall em um 
roteador Cisco sofreu uma evolução, iniciando com a configuração de listas de 
controle de acesso, que são as chamadas ACLs, que realizavam a filtragem do 
tráfego baseada em regras que especificavam os valores contidos nos pacotes, 
que era o modelo chamado de Filtro de pacotes. A evolução desse modelo foi a 
aplicação das ACLs que faziam a inspeção dos parâmetros do cabeçalho TCP, 
identificando se o pacote pertencia a uma sessão já estabelecida. Porém, como 
esse modelo estava baseado em uma informação que poderia ser facilmente 
alterada por um atacante, esse modelo, apesar de ser mais eficiente, ainda era 
muito inseguro. 
Para solucionar essa vulnerabilidade, a próxima geração de configuração 
de Firewall em roteadores Cisco foi a utilização das ACLs chamadas de 
reflexivas, que faziam a inspeção do tráfego de saída, a partir da aplicação de 
uma ACL que realizava a monitoração desse tráfego, e que gerava uma regra 
de permissão, que era aplicada à outra ACL, que realizava a filtragem do tráfego 
de entrada. Porém, esse modelo, que já representava um aumento significativo 
na eficiência do processo de filtragem de tráfego, e consequentemente na 
segurança da rede, apresentava uma maior complexidade na configuração e 
algumas limitações para a inspeção de algumas aplicações. E a solução mais 
atual, que temos hoje, é o chamado Firewall Clássico, que consiste na criação 
de regras de inspeção de tráfego, que farão a permissão automática do retorno 
do tráfego que foi permitido, sendo que essa solução também tem suporte aos 
protocolos TCP, UDP, ICMPS, DNS e outros, sendo muito mais eficiente e fácil 
de configurar. 
Esse modelo de Firewall Clássico, também chamado de CBAC – Context-
Based Access Control, implementa quatro funcionalidades distintas, que são a 
filtragem do tráfego, a inspeção do tráfego, a detecção de intrusão e a geração 
de informações, que podem utilizadas na geração de alertas e em processos de 
 
 
17 
auditoria e análise. E esse modelo apresenta muitos recursos adicionais aos 
modelos de implantação anteriores, que eram as ACLs reflexivas, e que são: 
• Monitoração do estabelecimento de sessões TCP; 
• Rastreio dos números de sequência do TCP; 
• Monitoração das informações de sessões UDP; 
• Inspeção das requisições e respostas de DNS; 
• Inspeção dos tipos de mensagens ICMP; 
• Suporte às aplicações baseadas em múltiplas conexões; 
• Inspeção das informações na camada de aplicação. 
3.1 Configuração do roteador 
Para a configuração do Firewall Clássico, é necessária a criação das 
regras de inspeção do protocolo, especificando o protocolo que será 
inspecionado, e a sua aplicação na direção do tráfego de saída da rede. E, 
conforme visto anteriormente, a sintaxe do comando para a configuração do 
processo de inspeção é a seguinte: 
(config)#ip inspect name <nome> <protocolo> 
Assim, no exemplo abaixo, para a inspeção do tráfego dos protocolos 
TCP, UDP e ICMP, com a criação de uma regra chamada FW, termos a seguinte 
configuração: 
(config)#ip inspect name FW tcp 
(config)#ip inspect name FW udp 
(config)#ip inspect name FW icmp 
Figura 10 – Inspeção do tráfego pelo rotador como FW 
 
Além da criação das regras de inspeção, é necessária a aplicação dessas 
regras na direção do tráfego de saída, o que pode ser feito em uma das duas 
interfaces do roteador, além da criação de uma ACL que realize o bloqueio de 
INTERNET 
192.168.10.1
0 Inspect “FW” 
Fa 0/0 S 0/0 
 
 
18 
todo o tráfego vindo da Internet, que é o princípio de operação do Firewall. Assim, 
aplicaremos a regra de inspeção no tráfego de saída na interface com a WAN, 
que é a interface Serial 0/0, bem como a regra de filtragem de tráfego, que será 
a ACL 101, conforme mostrado abaixo: 
(config)#interface serial 0/0 
(config-if)#ip inspect FW out 
(config-if)#ip access-group 101 in 
Figura 11 – Aplicação do bloqueio 
 
Feita essa configuração, o retorno do tráfego será automaticamente 
permitido na ACL de entrada, que é a ACL 101, que será criada automaticamente 
quando fizermos a sua aplicação à interface de entrada da WAN. E como essa 
ACL 101 não possui nenhuma regra de permissão, teremos a instrução implícita 
de negação de todo o tráfego, fazendo o bloqueio de todo o tráfego vindo da 
Internet. E à medida que as sessões dos protocolos TCP, UDP e ICMP sejam 
abertas em direção à Internet, o roteador, operando como Firewall, acompanhará 
essas requisições, permitindo então o retorno do tráfego esperado. 
3.2 Configuração da DMZ 
Outra configuração básica na segurança da rede é a criação de uma DMZ 
– Demilitarized Zone, que é a área dentro da rede que estará acessível para o 
acesso a partir de todos os hosts da internet, enquanto o Firewall implementará 
a segurança da rede interna. E a DMZ poderá ser implementada por um espaço 
de endereçamento de uma subrede ou com apenas um host. Assim, podemos 
ter dois tipos de DMZ, sendo que o modelo mais simples é o de apenas um host, 
que é utilizado em uma rede residencial, para permitir o acesso interno a 
aplicações, tais como jogos na Internet, videoconferência, web ou servidores de 
e-mail através do DMZ. O outro modelo, com a alocação de uma subrede, é 
INTERNET 
192.168.10.1
0 
ACL 101 
Fa 0/0 S 0/0 
 
 
19 
implementado nas redes corporativas, nas quais poderemos ter diversos 
serviços, que poderão ser executados por diversos servidores, tais como 
servidor WEB, e-mail, telefonia IP, e outros. 
Figura 12 – A DMZ no roteador como Firewall 
 
Portanto, teremos agora dois níveis de segurança na configuração do 
Firewall, com o bloqueio total do tráfego vindo da Internet em direção à rede 
interna, que é a LAN segura, e a permissão do tráfego vindo da Internet em 
direção à DMZ, a partir de qualquer endereço de origem, porém limitando-se o 
acesso aos endereços específicos dos servidores e aos serviços que 
efetivamente estão sendo executados nesses servidores. 
Assim, para configurarmos o controle de tráfego da DMZ em roteadores 
Cisco, utilizaremos as ACLs do tipo estendida, especificando o protocolo e o 
endereço de cada um dos servidores da DMZ, conforme veremos adiante. 
Outro aspecto que deve ser definido na implementação de uma DMZ é a 
utilização de um endereçamento IP privado ou de endereçamento público para 
os servidores instalados na DMZ. No caso do endereçamento público, será 
necessário obter esses endereços com o provedor de serviços de Internet (ISP), 
para que seja feito o roteamento correto para o roteador da empresa. Para o 
modelo baseado em um endereçamento privado, será necessária a configuração 
do processo de tradução de endereços, que é chamado deNAT, fazendo-se o 
mapeamento das portas externas para o endereço e porta de cada servidor 
INTERNET 
DMZ 
LAN Segura 
 
 
20 
instalado na rede DMZ. Assim, teremos dois tipos de configurações diferentes, 
de acordo com o modelo adotado. 
Para exemplificarmos a configuração de uma DMZ, utilizaremos o modelo 
de configuração ilustrado anteriormente, em que acrescentaremos uma DMZ, 
com o endereçamento mostrado na figura abaixo, com a instalação de um 
servidor WEB. Para isso, bastaria então acrescentarmos uma regra de 
permissão na ACL de entrada, que já havia sido criada para bloquear o tráfego 
externo, com a seguinte sintaxe: 
(config)#access-list 101 permit tcp any 200.10.15.123 
eq 80 
Nessa regra, teremos então a permissão do tráfego baseado no protocolo 
TCP cuja origem seja qualquer endereço na Internet, especificado pelo 
parâmetro any, e cujo destino seja o endereço do servidor e da porta 80, que é 
a porta para o protocolo HTTP. 
Figura 13 – A DMZ com aplicação de ACL 
 
Dessa forma, temos então a operação do roteador como um Firewall 
Clássico, com a inspeção do tráfego de saída, originado pelos hosts da rede 
LAN, que é a rede segura, conforme a configuração vista anteriormente, 
permitindo o retorno desse tráfego. E para o acesso externo ao servidor WEB, 
com a configuração de apenas uma regra de ACL, teremos a implementação de 
uma DMZ, obtendo-se assim a operação completa esperada de um Firewall, com 
a utilização de um roteador Cisco. 
 
INTERNET 
Servidor WEB 
200.10.15.123 
ACL 101 
 
 
21 
TEMA 4 – FIREWALL INTERNO 
Com a evolução das técnicas de ataques, as arquiteturas de segurança 
tradicionais já não são suficientes para impedir os ataques bem-sucedidos, 
sendo necessária também uma evolução na estratégia e tecnologias de defesa. 
Assim, as equipes de segurança precisam assumir que suas defesas de 
perímetro, incluindo o firewall de borda, eventualmente serão violadas, e que 
também deverão impedir que ocorra o chamado movimento lateral, que consiste 
em uma ação de ataque a partir de um host interno já comprometido. 
Com a instalação do Firewall de rede na borda da rede, entre a rede LAN 
a rede WAN, já temos a implementação da segurança do perímetro da rede, 
porém essa medida de segurança está altamente permeável, em função dos 
usuários finais móveis e remotos, e da utilização dos dispositivos pessoais nas 
redes internas, bem como os aplicativos que são executados na nuvem pública. 
E mesmo o ambiente de data center, que antes hospedava apenas 
equipamentos e aplicativos especializados, agora também hospeda os hosts de 
usuários finais, que utilizam a tecnologia de virtualização da infraestrutura de 
desktop. Dessa forma, os aplicativos de missão crítica das empresas estão a 
apenas um pequeno salto dos dispositivos de usuários finais, que são alvos 
fáceis para os atacantes. Assim, caso o atacante consiga violar a defesa do 
perímetro, ele poderá então se mover lateralmente, dentro da rede da empresa, 
para então alcançar e acessar os registros de dados sensíveis. E ataques, 
envolvendo os hosts internos, que estão dentro do perímetro de segurança, têm 
representado um porcentual crescente de incidentes de segurança, sendo que 
muitas vezes os usuários internos não têm conhecimento dessa violação, porém 
suas credenciais, ou dispositivos de usuário final, podem ter sido comprometidos 
por um invasor externo. 
Portanto, em vez de depender exclusivamente da segurança do 
perímetro, as empresas devem também adotar mecanismos de segurança para 
detectar e bloquear o tráfego de rede malicioso na rede interna, que é chamado 
de tráfego leste-oeste, sendo que esses mecanismos de segurança deverão 
fazer parte de sua estratégia de segurança de tecnologia da informação. Para 
isso, é necessária uma abordagem com a operação de um firewall interno, 
especificamente projetado para proteger grandes volumes de tráfego de data 
 
 
22 
center, no sentido leste-oeste, sem afetar a funcionalidade de segurança, o 
desempenho da rede ou a capacidade de gerenciamento. 
4.1 Implementação do Firewall interno 
Atualmente, a maioria dos firewalls internos são derivados dos firewalls 
de borda, que formam projetados para garantir quantidades limitadas de tráfego, 
que é o tráfego de entrada e saída da rede, chamado de tráfego norte-sul. 
Porém, em muitos data centers internos, o volume de tráfego leste-oeste é muito 
maior do que o tráfego norte-sul, sendo necessário também especificar uma 
política de segurança com maior granularidade em relação às aplicações 
hospedadas no data center, o que não é uma tarefa fácil de ser realizada com a 
utilização dos firewalls tradicionais. E como no contexto atual, em que as 
aplicações distribuídas são implementadas a partir da alocação dinâmica de 
recursos, garantir a segurança de todo o tráfego leste-oeste é uma tarefa 
complicada, cara e demorada para o ambiente dos data centers, principalmente 
com a utilização de firewalls tradicionais para operarem como firewalls internos. 
Portanto, a arquitetura dos firewalls de borda tradicionais não é adequada para 
a utilização desses equipamentos como firewalls internos, pois o volume de 
tráfego é muito maior, assim como a granularidade da política de segurança 
necessária, para que esse dispositivo seja capaz de evitar o movimento lateral 
no data center. 
Outra técnica empregada na implementação da segurança das redes 
corporativas é a chamada microssegmentação, que é um método de 
segmentação da rede com um nível de granularidade menor do que a 
segmentação que pode ser realizada com a utilização de firewalls de borda 
corporativos. A microssegmentação surgiu em 2013, para atender aos requisitos 
de escala de tráfego e com a granularidade necessária para garantir a segurança 
das aplicações mais atuais. No entanto, as soluções de microssegmentação 
apresentam alguns problemas característicos, pois a maioria das soluções de 
microssegmentação não implementam o conjunto completo de funcionalidades 
de segurança fornecidas por firewalls de borda. Essas soluções de 
microssegmentação normalmente fazem a orquestração do firewall interno das 
estações de trabalho, que estão incluídos nos sistemas operacionais. Assim, os 
orquestradores de microssegmentação estarão limitados à capacidade dos 
firewalls do sistema operacional instalado. E também os orquestradores não 
 
 
23 
podem entender ou aplicar políticas de segurança baseadas em usuários ou 
aplicativos, e não incluem nenhum mecanismo de controle de ameaças, tais 
como sistemas de detecção e de prevenção de intrusões (IDS/IPS), ou ainda, de 
análise de tráfego de rede, detecção e resposta de rede (NTA/NDR). 
Nesse modelo de implementação, os Firewalls internos distribuídos 
compartilham seus recursos com a solução de microssegmentação para atender 
aos requisitos de escala de tráfego leste-oeste, bem como para atender ao nível 
de granularidade necessária. Assim, eles mantêm a capacidade do firewall de 
borda corporativa, de criar e aplicar políticas de segurança com base em 
usuários e aplicativos, e incluem também os mecanismos de controle de 
ameaças, tais como o IDS/IPS, o NTA/NDR e o sandboxing. Ou seja, firewalls 
internos distribuídos combinam os recursos desejáveis dos firewalls tradicionais, 
de borda da rede corporativa, com as soluções de microssegmentação, criando 
uma arquitetura inovadora de firewall. 
O modelo de segurança baseado em Firewalls internos distribuídos não 
funciona apenas com data centers virtualizados, em que as máquinas virtuais 
estão hospedadas em um software de virtualização, instalado em um servidor 
físico. Eles também podem operar com servidores físicos, contêineres e a nuvem 
pública, de forma semelhante aos servidores virtualizados. Assim, os firewalls 
internos distribuídos podem impor um conjunto uniforme de políticas em 
máquinas virtuais, independentemente da infraestrutura,seja local ou em nuvem 
pública, ou do tipo de host, que pode ser uma máquina virtual, um servidor físico 
ou um contêiner. 
Uma das estratégias utilizadas pelas empresas é iniciar com uma 
implantação no modelo de macrossegmentação, em que o firewall interno 
distribuído replica as políticas de segmentação de rede já existente na empresa. 
Tal abordagem permite desenvolver a confiança da equipe de segurança nessa 
nova abordagem, e também permite uma flexibilidade para criar rapidamente e 
facilmente os novos segmentos de rede que sejam necessários, em direção a 
um modelo de microssegmentação. 
E para a implementação desse modelo de microssegmentação, temos a 
solução da VMware, que é chamada de NSX Service-defined Firewall, que 
implementa um firewall interno distribuído, como mostrado na figura a seguir. 
 
 
 
24 
Figura 14 – O Firewall definido com serviço da VMware 
 
O Firewall definido pelo Serviço é implantado por milhares de 
organizações, sendo que, por meio dessas implantações, a VMware observou 
que começar com firewalls internos distribuídos é um processo muito simples, e 
que, com o tempo, a equipe de segurança estende a implantação para 
aplicativos de missão crítica do negócio e, em última instância, para todos os 
aplicativos do data center. Eles também adicionam as funcionalidades de 
IDS/IPS para atender aos requisitos de conformidade, criando uma segunda 
camada de defesa para os aplicativos mais sensíveis. 
4.2 Operação do Firewall interno 
Inicialmente, a implementação de segurança das redes foi feita com a 
instalação de um firewall de borda, não existindo ainda o conceito de firewalls 
internos. E, à medida que a demanda por recursos de tecnologia da informação 
aumentou, ocorreu a expansão das redes e a maioria dos servidores físicos, que 
executavam os aplicativos mais pesados, foram segregados de dispositivos de 
usuário final, como desktops, laptops e impressoras, e movidos para os data 
centers. 
E como esse ambiente de data center passou a acomodar as aplicações 
de missão crítica, a maioria das empresas manteve um controle mais rigoroso 
sobre o data center do que sobre dispositivos de usuário final. Porém, como os 
dispositivos de usuário final e os próprios usuários finais eram vistos como alvos 
mais fáceis do que os servidores, os atacantes geralmente visavam os 
Controle de acesso 
distribuído 
Controle de ameaças 
distribuído 
Gerenciamento centralizado e analíticos 
distribuídos 
Service-defined Firewall 
 
 
25 
dispositivos de usuário final, para uma infiltração inicial e, em seguida, utilizavam 
o acesso obtido ao dispositivo do usuário final para acessar os servidores no 
data center, realizando o chamado movimento lateral. Assim, surgiu a 
necessidade de uma segmentação entre as redes de usuário final e as redes de 
servidores, e os únicos firewalls disponíveis para realizar tal segmentação foram 
os dispositivos de firewall de borda de alto desempenho. Dessa forma, esses 
firewalls foram reaproveitados para funcionar como firewalls internos, que é o 
cenário encontrado na maioria das empresas atualmente. 
As arquiteturas dos aplicativos também evoluíram a partir da época em 
que as redes de data center eram segmentadas das redes dos usuários finais. 
Os aplicativos possuíam inicialmente uma estrutura monolítica, sendo então 
divididos em níveis, sendo que em cada nível poderiam operar como uma ou 
mais demandas de carga. Posteriormente, os aplicativos foram ainda mais 
modularizados, sendo que atualmente são compostos por vários tipos de carga 
de trabalho e de microsserviços, seja no data center da organização ou na 
nuvem pública. 
Por exemplo, em um aplicativo de três níveis, um firewall interno permitirá 
o tráfego entre o nível web e o nível de lógica de negócios do aplicativo e entre 
o nível do aplicativo e o nível de banco de dados do mesmo aplicativo. No 
entanto, deverá bloquear o tráfego do nível web para o nível de banco de dados, 
porque esse tráfego não deve existir no curso ordinário das operações. Ou seja, 
a granularidade de aplicação necessária na operação de um firewall interno é 
muito maior do que a de um firewall de borda. No exemplo anterior, um firewall 
de borda típico não teria a capacidade de identificar que os três níveis pertencem 
ao mesmo aplicativo, ou que, dentro desse aplicativo, algum tráfego é permitido 
enquanto outro tráfego não é. Assim, devemos esperar que um firewall de borda 
corporativo bloqueie o tráfego com base em portas, protocolos e endereços de 
rede, ou identifique e bloqueie o tráfego de um aplicativo específico, tal como o 
Skype. No entanto, um firewall interno deve operar em um nível muito mais 
granular, identificando as cargas de trabalho individuais dentro de um aplicativo. 
Para a utilização de um firewall de borda corporativo para a filtragem do 
tráfego leste-oeste, inspecionando todo ou a maior parte desse tipo de tráfego, 
talvez seja necessária a implantação de muitos firewalls para garantir o 
desempenho da rede, o que pode representar um alto custo e uma grande 
complexidade da infraestrutura de segurança de rede. E à medida que o tráfego 
 
 
26 
leste-oeste aumenta, teremos também um aumento em relação à capacidade do 
firewall de borda, cuja atualização pode representar um custo elevado. A 
inspeção centralizada do tráfego norte-sul, realizada pelo firewall de borda 
corporativa, normalmente não cria gargalos de desempenho, porque o volume 
não é tão grande quanto o do tráfego leste-oeste, pois, normalmente, o tráfego 
leste-oeste é muito maior do que o tráfego norte-sul. Assim, na prática, a 
utilização do firewall de borda na monitoração do tráfego leste-oeste não 
inspeciona todo o tráfego, pois o custo e as restrições de fazê-lo são muito altos, 
e teremos uma parte do tráfego leste-oeste não sendo inspecionado. 
Assim, uma das soluções de firewall interno é o NSX Service-defined 
Firewall da VMware, que é uma implementação fiel de um firewall interno 
distribuído, com a instalação dos mecanismos de processamento de inspeção 
de tráfego de maneira distribuída e com um plano de gerenciamento 
centralizado, cujos componentes são detalhados a seguir. 
• Mecanismo de processamento distribuído: todos os mecanismos de 
processamento do Firewall, que são o controle de acesso, o controle de 
ameaças e a análise do tráfego, são distribuídos. Esses mecanismos de 
processamento são implementados para extrair o maior desempenho dos 
servidores físicos, porém o seu desempenho real dependerá também da 
capacidade do servidor físico. 
• Gerenciamento centralizado: o Firewall inclui um sistema de 
gerenciamento centralizado, com um modelo de política de segurança 
intuitivo. Além disso, o elemento de gerenciamento central apenas 
comunica as mudanças de políticas relevantes para os mecanismos de 
processamento distribuído, que é o plano de controle local. E essa solução 
de firewall com o sistema de gerenciamento pode ser federado em várias 
implantações lógicas ou físicas, para suportar redes mais amplas. 
• Um modelo de política intuitiva: o gerenciamento central implementa um 
modelo de política de segurança abstrata, porém de maneira intuitiva. 
Assim, as políticas podem ser descritas em termos de atributos de carga 
de trabalho, tais como tipo de sistema operacional, nomes de máquinas 
virtuais, identidades/grupos de usuários e identidades de aplicativos. Além 
disso, as políticas estão associadas às cargas de trabalho, e não à rede, 
pois as cargas de trabalho são as entidades que estão sendo protegidas. 
Também podem ser utilizadas as "Tags de segurança", que são abstratas 
 
 
27 
e podem ser associadas às cargas de trabalho, permitindo definir políticas 
complexas de uma forma muito mais simples. Além disso, as políticas são 
dinâmicas, podendo ser ajustadas em tempo real e permitindo mudanças 
incrementais nas medidas de segurança da organização.• Acesso à camada de rede: o Firewall tem acesso à camada de rede, 
permitindo que ele separe a defesa de rede da defesa do dispositivo final 
de usuário. 
• Portabilidade das informações de tráfego: o firewall associa as 
informações de tráfego com os hosts virtuais, e assim, quando um host é 
movido, as informações de tráfego se movem com ele e os fluxos de 
tráfego permanecem protegidos, sendo que nenhuma conexão ou tráfego 
é descartado durante essa mudança. Dessa forma, não são necessárias 
atualizações manuais para as políticas de segurança para proteger um 
host virtual em movimento. 
TEMA 5 – FIREWALL BASEADO EM ZONAS 
Entre as diversas tecnologias e soluções para a implementação de 
Firewall em uma rede corporativa, temos também o recurso chamado de Cisco 
IOS Zone Based Firewall, que é um dos recursos mais avançados dos sistemas 
operacionais dos equipamentos da Cisco, chamado de IOS. Esse recurso 
permite a implementação de um firewall do tipo stateful, sendo um modelo de 
firewall baseado em zonas, e conhecido pela sigla ZBFW – Zone Based FireWall. 
Esse modelo de firewall é o sucessor do firewall Clássico, visto anteriormente, 
que também era chamado de CBAC – Context-Based Access Control. 
A primeira implementação em roteadores Cisco do modelo de firewall 
chamado de stateful firewall, que faz o acompanhamento do estado das 
conexões, foi o modelo chamado de CBAC, e depois de Firewall Clássico, com 
a utilização do comando ip inspect para inspecionar o tráfego na camada 4 e na 
camada 7, conforme vimos anteriormente. Porém, esse modelo de configuração 
estava focado na filtragem do tráfego norte-sul, pois a funcionalidade de Firewall 
era implementada no roteador de borda da rede, sendo configurado assim o 
Firewall de borda. Para a filtragem do tráfego interno, que é o tráfego chamado 
de leste-oeste, é necessária uma maior granularidade nas regras de filtragem, o 
que é possível com a utilização do modelo chamado de Zone Based Firewall. 
 
 
 
28 
Figura 15 – O Firewall baseado em zonas 
 
5.1 Operação do ZBFW 
Para a operação de filtragem do tráfego com o ZBFW, deverão ser 
definidas as zonas de tráfego e a política de segurança a ser aplicada para o 
tráfego entre as diversas zonas. Portanto, deverão ser definidas as interfaces 
que pertencem a cada uma das zonas e, em seguida, a política de inspeção 
deverá ser aplicada ao tráfego entre essas zonas. E assim como a operação do 
firewall clássico, para o ZBFW a política padrão também é o de bloqueio de todo 
o tráfego, sendo então definida a permissão do tráfego seguro. 
O modelo ZBFW suporta também os recursos dos modelos de 
implementação de firewall anteriores, incluindo a inspeção dos pacotes das 
sessões, chamado de SPI – Stateful Packet Inspection, a inspeção de 
aplicativos, a filtragem de URL e a mitigação de ataques de negação de serviço, 
conhecido como ataque de DoS – Denial of Service. 
A operação do ZBF não depende da configuração de ACL, porém a sua 
configuração é realizada com o modelo chamado de C3PL – Cisco Common 
Classification Policy Language, com a criação de mapeamento de classes, 
INTERNET 
DMZ 
Zona 1 
Zona 2 
 
 
29 
chamado de class map, e da criação de mapeamento de políticas, chamado de 
policy map. E esses mapeamentos serão utilizados para realizar a classificação 
do tráfego e a aplicação das políticas para cada tipo de tráfego. Dessa forma, 
uma política pode ser aplicada a diversos fluxos de tráfego, não sendo 
necessária a criação e aplicação de múltiplas ACLs e de diversas ações de 
inspeção. E as ações realizadas pelo firewall ZBF poderão ser do tipo inspeção, 
permissão ou descarte, conforme veremos a seguir. 
A ação de inspeção, chamada de Inspect, habilita o Cisco IOS SPI, que é 
equivalente ao comando ip inspect, permitindo automaticamente o tráfego de 
retorno e das possíveis mensagens ICMP. Para os protocolos que exigem uma 
sinalização paralela e múltiplas sessões de dados, como, por exemplo, os 
protocolos FTP ou H.323, a ação de inspeção também irá identificar a 
necessidade de estabelecimento de sessões adicionais. 
A ação de permissão, chamada de Pass, é semelhante a uma declaração 
de permissão de uma ACL, não realizando o rastreio do estado de conexões ou 
de sessões dentro do tráfego, permitindo o tráfego em apenas uma direção. Uma 
política equivalente deverá ser aplicada ao tráfego no sentido contrário, caso ele 
também deva ser permitido, na direção oposta. 
E para a ação de descarte, que é chamada de Drop, temos um resultado 
semelhante a uma declaração de negação em uma ACL, sendo possível também 
a geração de mensagens de log para os pacotes que sejam bloqueados. Esse 
recurso permite o registro das ações de descarte, que pode ser utilizado para 
uma posterior auditoria, ou até para a monitoração em tempo real das tentativas 
de acesso indevido, bloqueadas pelo Firewall. 
5.2 As zonas de segurança 
Uma zona de segurança é um grupo de interfaces para as quais uma 
política de segurança poderá ser aplicada, sendo que o processo de 
agrupamento de interfaces em zonas envolve dois procedimentos, que são a 
criação das zonas e a configuração das interfaces, para que sejam associadas 
a uma determinada zona. E, por padrão, o tráfego entre as interfaces que são 
membros da mesma zona será sempre permitido. 
Quando uma interface é membro de uma zona de segurança, todo o 
tráfego entre essa interface e uma interface dentro de uma zona diferente é 
descartado por padrão, exceto o tráfego de retorno em direção ao dispositivo. 
 
 
30 
Para permitir o tráfego entre as interfaces que pertencem a zonas distintas, é 
necessário definir um par de zonas, que estão associadas a essas interfaces, e 
aplicar uma política a esse par de zonas. Se a política de segurança aplicada 
permitir o tráfego, através de uma ação do tipo inspect ou pass, o tráfego poderá 
ser encaminhado através das interfaces. 
E na operação do ZBF, as ações que serão realizadas dependerão da 
configuração das zonas e dos pares de zonas, conforme veremos a seguir. 
Assim, na configuração inicial, devemos sempre levar em consideração esse 
comportamento descrito abaixo. 
O tráfego de uma interface que pertence a uma zona, em direção a uma 
interface que não está associada a nenhuma zona, ou que tenha origem em uma 
interface que não está associada a nenhuma zona, será sempre descartado, a 
não ser que as zonas padrão sejam habilitadas, quando uma zona default é uma 
interface que não pertence a nenhuma zona. Ou seja, a partir do momento que 
uma interface esteja associada a uma zona, será necessária a configuração de 
uma relação com as demais zonas para que ocorra a comunicação. Caso 
contrário, o tráfego através dessa interface será sempre bloqueado, atribuindo-
se assim o nível máximo de segurança a essa interface/zona. 
Quando tivermos o tráfego entre duas zonas, esse tráfego é inspecionado, 
sendo verificado se existe uma relação configurada entre as duas zonas e se 
uma política de segurança está configurada para esse zone pair. E então será 
aplicada a regra, que poderá ser de inspeção, permissão ou descarte, conforme 
vimos anteriormente. 
Quando as duas interfaces envolvidas no fluxo de tráfego pertencerem à 
mesma zona, esse tráfego será permitido por padrão. Ou seja, todo o tráfego 
dentro de uma mesma zona será sempre permitido. 
Um zone pair pode ser configurado com uma zona sendo a origem ou o 
destino do tráfego, e uma política de inspeção poderá ser configurada para esse 
zone pair visando inspecionar, permitir ou bloquear o tráfego entre as duas 
zonas, sendo que uma interface pode pertencer à apenas uma zona. 
Quando uma interface é membro de uma zona de segurança, todo o 
tráfego de e para essa interface é bloqueado, a menos que você configure uma 
política de interzone explícita, incluindo o par de zonas envolvendo esse tráfego. 
Para que o tráfego flua entre todas as interfacesde um dispositivo, essas 
interfaces devem ser membros de algumas das zonas de segurança 
 
 
31 
configuradas no Firewall. Porém, não é necessário que todas as interfaces do 
dispositivo sejam membros de zonas de segurança. 
Para a aplicação desses conceitos de operação do ZBF e da criação das 
zonas e das regras de filtragem, veremos, em nossa próxima aula, a 
configuração desse modelo de Firewall em equipamentos Cisco. 
FINALIZANDO 
Para a implementação de um sistema de Firewall nas redes corporativas 
atuais, temos uma grande diversidade de opções, sendo uma das escolhas 
inicias o tipo de hardware que será empregado para essa finalidade. 
Conforme vimos, podemos implementar as funcionalidades de Firewall 
em um roteador, o que acontece em praticamente todas as instalações 
residenciais, onde o equipamento que faz a conexão com a rede do provedor, 
além do roteamento e da modulação dos sinais, também permite habilitar a 
funcionalidade de Firewall. E, nesse caso, espera-se que essa solução de 
Firewall opere no modo Stateful Firewall, fazendo a inspeção de todos os tipos 
de protocolos e permitindo o retorno do tráfego apenas para as sessões 
inicializadas pelos computadores da rede LAN. 
Para redes de médio porte, podemos utilizar um roteador Cisco como 
Firewall da rede. E para a sua operação, poderemos utilizar o modelo de Firewall 
Clássico, cuja configuração será bastante simples. Conforme vimos nesta aula, 
para a configuração do Firewall Clássico, basta aplicarmos uma ACL para o 
tráfego de entrada da rede e criarmos as regras de inspeção do tráfego de saída, 
para os protocolos que serão utilizados na comunicação com a rede externa. 
Assim, o retorno do tráfego, cujas sessões sejam iniciadas pelos terminais da 
rede interna, será automaticamente permitido na ACL aplicada ao tráfego de 
entrada, vindo da rede WAN. 
E terceira opção seria a instalação de um Hardware dedicado, de modo 
que o roteador execute apenas as suas funções de roteamento, e o Firewall, 
instalado após o roteador, fará a filtragem do tráfego, conforme mostrado na 
figura a seguir. 
 
 
 
32 
Figura 16 – O Firewall com Hardware dedicado 
 
E para esse modelo de implementação, podemos utilizar um equipamento 
desenvolvido exclusivamente para essa finalidade, ou uma solução de software 
sendo executada em um hardware do tipo Servidor. E as soluções baseadas em 
software mais utilizadas no mercado são as plataformas de código aberto, com 
a utilização de uma solução do tipo Open Source, sendo uma das mais 
conhecidas o iptables. Mas também temos as soluções dos fornecedores de 
soluções baseadas em um Hardware desenvolvido especialmente para executar 
as funções de segurança, onde temos uma maior garantia de desempenho, pois 
o hardware e o software estão integrados em uma plataforma dedicada e 
desenvolvida para essa finalidade. 
Portanto, na implementação de uma solução de segurança em uma rede 
de grande porte, normalmente são utilizados os equipamentos dedicados, sendo 
dimensionados para suportar todo o tráfego da rede, executando todos os 
processos de segurança e apresentando o menor impacto possível no tempo de 
processamento, gerando o menor atraso possível na rede. Assim, temos 
diversas soluções dos fabricantes, de acordo com os requisitos das redes, com 
uma grande gama de equipamentos diferentes, de acordo com a capacidade de 
processamento que será exigida em cada projeto. 
E para os equipamentos dedicados, também teremos uma diversidade de 
opções de conectividade, com diversas quantidades e tipos de interfaces. E 
quando temos a implementação do modelo de FW em zonas, essa quantidade 
INTERNET 
DMZ 
LAN 
 
 
33 
de portas também será um parâmetro crítico, pois poderemos ter a necessidade 
de uma grande segmentação da rede, o que levará à criação de diversas zonas 
de segurança, e que estarão associadas à diversas interfaces. 
Portanto, o processo de escolha do Firewall mais adequado para cada 
rede dependerá dos requisitos da rede, da política de segurança da empresa e 
do desempenho esperado do sistema, o que impactará no dimensionamento dos 
requisitos mínimos, permitindo identificar as diversas opções de mercado e 
realizarmos uma análise custo x benefício dessas soluções. 
 
 
 
 
 
34 
REFERÊNCIAS 
KEERIYATTIL, S. Zero Trust Networks with VMware NSX: Getting Started. In: 
Zero Trust Networks with VMware NSX. Berkeley, CA: Apress, 2019. 
STALINGS, W. Criptografia e segurança de redes. São Paulo: Pearson 
Prentice Hall, 2015. 
TERADA, R. Segurança de Dado: criptografia em redes de computadores. São 
Paulo: Blucher, 2008. 
TANEMBAUM, A. S. Redes de computadores. 2. ed. São Paulo: Pearson 
Education do Brasil, 2011. 
WENDELL, O. CCNA ICND guia oficial de certificação. 2. ed. Rio de Janeiro: 
Alta Books, 2008.