Implementando Firewalls baseadas em zona (ZFW) com zona desmilitarizada (DMZ)

Desde que a Cisco os introduziu em 2006, firewalls baseadas em zona (ZFW) são a ‘bola de vez’. São stateful firewalls poderosas que também permitem application inspection. Ja vimos no post anterior que antigas implementações representavam um esforço grande em termos de escalabilidade e gestão. Com a introdução do conceito de zonas as interfaces dum encaminhador ou dum comutador de camada 3 pertencem a uma determinada zona ou a nenhuma zona.

Depois disso, são estabelecidas relações (policy) entre esta e outras zonas. Se nenhuma policy for atribuída a interfaces pertencentes a zonas o tráfego estará sujeito a condição de deny all ou seja será negado tráfego da interface e para a interface. Para determinar a que tráfego será aplicada uma determinada policy são criadas class-maps. Class-maps permitem identificar tráfego vindo a determinada interface.

Entre uma zona e outra podem existir um determinado numero de relações, a saber:

  • A zone must be configured before interfaces can be assigned to the zone.
  • An interface can be assigned to only one security zone.
  • All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
  • Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
  • In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.
  • The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.
  • Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.
  • Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.
  • If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.
  • From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).
  • The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

A seguinte figura ilustra uma rede com 3 zonas definidas: private, DMZ e Internet.

Implementar firewalls baseadas em zona é algo executado nos seguintes passos:

1 – Definir e configurar zonas.
2 – Definir e configurar zone-pairs (por exemplo, Internet-DMZ ou Private-Internet).
3 – Configurar class-maps para definir que tráfego irá ser permitido entre as zone-pairs.
4 – Configurar policy-maps e aplicar acções sobre uma class-map (por exemplo para a class-map class-negar-ftp, aplicar a action drop)
5 – Associar uma interface a uma zona.

O diagrama abaixo é bastante elucidativo. Trata-se duma rede com 3 zonas, a saber: FINANCE, DMZ e INTERNET.

Diagrama de Firewall com 3 zonas: FINANCE, DMZ e INTERNET

Ficaram definidas as seguintes restrições (policy) para o tráfego:
1 – TRAFFIC FROM INTERNET  TO DMZ           -> ALLOW
2 – TRAFFIC FROM INTERNET TO FINANCE -> DENY
3 – TRAFFIC FROM FINANCE TO DMZ              -> ALLOW
4 – TRAFFIC FROM FINANCE TO INTERNET -> ALLOW
5 – TRAFFIC FROM DMZ TO INTERNET           -> DENY
6 – TRAFFIC FROM DMZ TO FINANCE             -> DENY

Estas restrições tipificam o comportamento normal duma Firewall: Permitir tráfego (http e dns) da rede privada (FINANCE) para a INTERNET, mas barrar todo tráfego vindo da INTERNET. No entanto liberar tráfego (icmp, dns, ftp, tftp, http) da rede privada (FINANCE) para a DMZ (que é rede publica). Da INTERNET para a DMZ permitir também algum tráfego.

No caso da INTERNET para a DMZ foi necessário combinar a aplicação de ACL’s com class-maps ja que a DMZ comporta 3 servidores (FTP, DNS e HTTP) com endereços IP públicos. Esta ACL permitirá acesso a hosts na INTERNET a estes 3 servidores.

Vamos então a configuração:

Encaminhador SNNANGOLA FIREWALL

Hostname

hostname SNNANGOLA

Lista de acesso para tráfego que venha da INTERNET aos 3 servidores da DMZ

access-list 100 permit ip any host 195.30.30.35
access-list 100 permit ip any host 195.30.30.34
access-list 100 permit ip any host 195.30.30.35

Class-maps para definir tráfego que as interfaces das 3 zonas receberão

class-map type inspect match-any FINANCE-TO-INTERNET
match protocol tcp
match protocol udp
match protocol icmp
match protocol http
match protocol dns

class-map type inspect match-any FINANCE-TO-DMZ
match protocol tcp
match protocol udp
match protocol icmp
match protocol dns
match protocol ftp
match protocol tftp
match protocol http

class-map type inspect match-any INTERNET-TO-DMZ
match access-group 100
match protocol http
match protocol dns
match protocol ftp
match protocol icmp

Na class-map INTERNET-TO-DMZ note a existência duma correspondência com a ACL 100.

3 Policy-Maps para aplicar acção de inspect a tráfego definido pelas class-maps

policy-map type inspect FINANCE-TO-INTERNET-POLICY
class type inspect FINANCE-TO-INTERNET
inspect

policy-map type inspect FINANCE-TO-DMZ-POLICY
class type inspect FINANCE-TO-DMZ
inspect

policy-map type inspect INTERNET-TO-DMZ-POLICY
class type inspect INTERNET-TO-DMZ
inspect

Existem 3 tipos de acções que podem ser aplicadas a uma policy-map. inspect, drop e pass:

  • Drop—This is the default action for all traffic, as applied by the “class class-default” that terminates every inspect-type policy-map. Other class-maps within a policy-map can also be configured to drop unwanted traffic. Traffic that is handled by the drop action is “silently” dropped (i.e., no notification of the drop is sent to the relevant end-host) by the ZFW, as opposed to an ACL’s behavior of sending an ICMP “host unreachable” message to the host that sent the denied traffic. Currently, there is not an option to change the “silent drop” behavior. The log option can be added with drop for syslog notification that traffic was dropped by the firewall.
  • Pass—This action allows the router to forward traffic from one zone to another. The pass action does not track the state of connections or sessions within the traffic. Pass only allows the traffic in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction. The pass action is useful for protocols such as IPSec ESP, IPSec AH, ISAKMP, and other inherently secure protocols with predictable behavior. However, most application traffic is better handled in the ZFW with the inspect action.
  • Inspect—The inspect action offers state-based traffic control. For example, if traffic from the private zone to the Internet zone in the earlier example network is inspected, the router maintains connection or session information for TCP and User Datagram Protocol (UDP) traffic. Therefore, the router permits return traffic sent from Internet-zone hosts in reply to private zone connection requests. Also, inspect can provide application inspection and control for certain service protocols that might carry vulnerable or sensitive application traffic. Audit-trail can be applied with a parameter-map to record connection/session start, stop, duration, the data volume transferred, and source and destination addresses.

Definir e configurar zonas

zone security FINANCE
zone security INTERNET
zone security DMZ

Configurar ‘zone-pairs’

zone-pair security FINANCE-DMZ source FINANCE destination DMZ
service-policy type inspect FINANCE-TO-DMZ-POLICY

zone-pair security FINANCE-INTERNET source FINANCE destination INTERNET
service-policy type inspect FINANCE-TO-INTERNET-POLICY

zone-pair security INTERNET-DMZ source INTERNET destination DMZ
service-policy type inspect INTERNET-TO-DMZ-POLICY

As zone-pair’s sao configuradas definindo-se uma origem e um destino de trafego. Em seguida associar o mesmo a uma policy.

Atribuir uma zona a uma interface:

interface FastEthernet0/0
ip address 192.168.20.1 255.255.255.0
zone-member security FINANCE
duplex auto
speed auto

interface FastEthernet0/1
ip address 195.30.30.62 255.255.255.224
zone-member security DMZ
duplex auto
speed auto

interface Serial0/0/0
ip address 195.30.30.30 255.255.255.224
zone-member security INTERNET
clock rate 64000

Só para que conste e fique anotado se você ainda não se apercebeu:

Fa0/0 – Interface facing FINANCE subnetwork.
Fa0/1 – Interface facing DMZ subnetwork.
Serial0/0/0 – Interface facing INTERNET subnetwork.

Em seguida configurações de encaminhamento RIP version 2 e estático:

router rip
version 2
network 192.168.10.0
network 192.168.20.0
network 195.30.30.0
default-information originate
no auto-summary

ip route 0.0.0.0 0.0.0.0 195.30.30.1

Encaminhador INTERNET

hostname INTERNET

interface FastEthernet0/0
ip address 195.30.30.65 255.255.255.224
duplex auto
speed auto

interface Serial0/0/0
ip address 195.30.30.1 255.255.255.224

router rip
version 2
network 195.30.30.0
no auto-summary

Os resultados são animadores e como você pode ver não é difícil configurar firewalls baseadas em zona, alem destas possuírem uma soberba flexibilidade. E isto é apenas o começo. O poder deste tipo de firewalls é absolutamente impressionante senão único em se tratando de aplication inspection.

Fontes:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml
http://blog.ipexpert.com/2010/01/18/cisco-ios-zone-based-firewalls/

Entendendo de vez o uso do parametro established em ACLs

Bom, continuamos aqui a falar sobre acls. Desta vez para explicar o uso do parametro established em acls. A razão disto é que as vezes não é muito bem explicado porque se usa este parametro. Este parametro é utilizado para garantir que um tráfego de retorno X é permitido a entrar numa rede Y se ele teve origem na rede Y. Por exemplo na figura abaixo:

Suponha que queiramos permitir que os usuarios de R1 (Rede Interna 4.4.4.0, protegida por acl) possam usar a Web por meio do provedor de Internet R3 (Rede externa 3.3.3.0). Todo tráfego deve ser negado. A seguinte ACL poderia ser utilizada (não testei):

R1>access-list 100 permit tcp 4.4.4.0 0.0.0.255 3.3.3.0 0.0.0.255 eq 80 established
R1>access-list 100 deny ip any any

Se o parametro established nao estivesse ali os usuarios de R1 poderia enviar pacotes HTTP a R2, mas estes quando retornassem a R1 seria barrados. Com o parametro established é garantido que toda conexão com a flag ACK ou RST setada é permitida. Toda nova tentativa de criar uma nova sessão é negada.

ACLs: Entendendo de vez os parametros IN e OUT

Sinceramente, chega de conversa. Aprender ACL sem ter dificuldade em entender como funcionam os parametros in e out do comando ‘ip access-group’ do modo de interface é privilegio de poucos. Tive as minhas dificuldades.

Afinal o que significam os parametros in e out? Naturalmente significam entrada e saida. Então porque a dificuldade em usa-lo? O problema reside na direcção a aplicar. Repare a seguinte figura:

O problema nos diz que devemos evitar que o tráfego proveniente da rede 192.168.1.0 alcance a rede 192.168.4.0. Todas as outras redes podem ser alcançadas.

A teoria das acls nos diz que acls padrão devem ser colocadas mais ‘proximas do destino do tráfego’. A nossa acl é a seguinte (ver fig. acima):

access-list 9 deny 192.168.1.0 0.0.0.255
access-list 9 permit any

Naturalmente esta acl por ser padrão irá ser colocada no router da rede 192.168.4.0.

A pergunta que se coloca é a seguinte: Em que direcção? in ou out? Poderiamos cair na tentacção de considerar como in na interface serial, já que o tráfego entrante indesejavel vem de 192.168.1.0 por aquele caminho. Mas não é assim, porque devemos levar em conta que acls padrão devem ser posicionadas mais proximas do destino e como o destino mais proximo a rede 192.168.4.0 é a interface fa0/0 então ela deve ali ser colocada. Mas em que direcção? Note que deve ser colocada na direcção out porque a posição de fa0/0 nos indica que o tráfego ali passante ‘atravessou’ o roteador de um extremo de entrada (interface serial) até o outro de saida (fa0/0).

E se fosse uma acl estendida? Aonde ela seria aplicada?
A seguinte acl seria produzida:

access-list 109 deny ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255
access-list 109 permit ip any any

Novamente recorremos a definição que nos diz que acls estendidas devem ser posicionadas mais proximas a ‘origem do tráfego’. E aonde está mais proxima a origem dos dados? Na interface fa0/0 do roteador da rede 192.168.1.0. E em que direcção deva ser colocada? Logico que na direcção in do roteador porque a mesma nao necessita de ‘atravessar’ o roteador para ser tratada.

É apenas uma questão de se ‘jogar’ com a definição de lista padrão e estendida e entender que uma direcção out na maior parte das vezes indica tráfego ‘atravessante’ no roteador e in indica tráfego a entrar ao roteador.

Criando listas de controlo de acesso (ACL). Parte II

No nosso primeiro artigo introduzimos conceitos basicos sobre acls bem como a sintaxe básica de acls padrão e estendidas. A melhor forma de perceber o funcionamento duma ACL é com um diagrama:

No primeiro exemplo pede-se para escrever uma lista de acesso padrão que negue acesso a rede 10.1.1.0 que está no roteador B mas permita todos outros acessos.

Existe uma regra básica quando se vai fazer uma acl padrão: Ela deve ser aplicada mais proximo do destino dos pacotes.

No nosso caso estamos interessados em que se barre o acesso a essa rede (10.1.1.0) a partir do roteador A, mas que se permita todos outros acessos, por exemplo a rede 10.2.1.0 ou a rede da Microsoft:

Router(config)#access-list 14 deny 10.1.1.0 0.0.0.15
Router(config)#access-list 14 permit any

A instrução permity any é importante e deve ser aplicada sob pena de se barrar todo acesso a qualquer outra rede, já que no fim de cada acl existe uma instrução implicita deny any.

É necessario agora aplica-la a uma interface que no nossa caso será a serial do roteador A (origem). A direcção será a de entrada dos pacotes no roteador (inbound). Desta forma os pacotes que entram no roteador e sao roteaveis e que forem dirigidos a rede 10.1.1.0 serão descartados pela verificação da acl. Se não, serão encaminhados:

Router(config)#interface serial 0/3/0
Router(config-if)#ip access-group 14 in

Para desassociar uma determinada acl a uma interface basta negar o comando anterior:

Router(config)#interface serial 0/3/0
Router(config-if)#no ip access-group 14 in

Um outro exemplo: crie uma lista de acesso estendida que negue telnet para a rede da interface loopback 0 a partir de qualquer origem, mas o telnet e qualquer outro tráfego a partir de qualquer outro endereço ip ou rede ou para qualquer outra rede deverá funcionar.

Esta lista deverá ser aplicada na interface serial do roteador A. Sabemos que as listas de acesso estendidas devem estar mais proximas da origem dos pacotes.

Router(config)#access-list 103 deny tcp any 192.168.1.0 0.0.0.63 eq 23
Router(config)#access-list 103 permit ip any any

A instrução any é semelhante a instrução

0.0.0.0 255.255.255.255. Sabemos que 0.0.0.0 é encarada pelo roteador como uma rota default. Com uma mascara de sub-rede 0.0.0.0 e mascara curinga será 255.255.255.255. Entao a lista acima poderia ser escrita como:

Router(config)#access-list 103 deny tcp 0.0.0.0 255.255.255.255 192.168.1.0 0.0.0.63 eq 23
Router(config)#access-list 103 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

Basta agora aplica-la na interface na direcção inbound.

Router(config)#interface serial 0/3/0
Router(config-if)#ip access-group 103 in

Mas repare numa situação: Se quisessemos barrar TFTP? A lista acima seria da seguinte forma:

Router(config)#access-list 103 deny udp any 192.168.1.0 0.0.0.63 eq 69
Router(config)#access-list 103 permit ip any any

Imagine que quisessemos barrar pings a partir de qualquer origem? Como sabemos ele utiliza o protocolo icmp:

Router(config)#access-list 104 deny icmp any 192.168.1.0 0.0.0.63
Router(config)#access-list 104 permit ip any any
Router(config)#interface serial 0/3/0
Router(config-if)#ip access-group 104 in

Um pequeno teste:

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Se notou acima viu que uma das desvantagens das ACL padrão é que ela barra todos os protocolos da stack TCP/IP e nao permite barrar também determinados portos, daí então que as ACL estendidas sao a melhor opção quando se pretende maior flexibilidade nas operações.

Criando listas de controlo de acesso (ACL). Parte I

Listas de controlo de acesso, existem em diversas plataformas e sistemas. No nosso caso vamos falar de ACLs em roteadores Cisco.

Uma ACL pode ser definida como um classificador de pacotes. Essa classificação pode ser depois aplicada nao apenas na filtragem de pacotes, mas na encriptação, na qualidade de serviço (QoS), NAT, PAT, DDR etc.

Existem 2 tipos de ACL no cisco IOS: Padrão e estendidas sao as mais usadas. Outros tipos sao as reflexivas, as time-based e as dinamiscas (lock and key).

As ACL padrão sao aquelas que identificam o endereço de origem do pacote e tomam uma decisao de permissao ou negação.
As ACL estendidas sao aquelas que identificam o endereço de origem e de destino bem como protocolos, portas e outros parametros.

As ACL padrão e estendidas podem ser identificadas de 2 formas distintas: Por um intervalo de numeros ou por nome. Sendo assim por numeros, as ACL padrão sao identificadas por 1 a 99 e 1300 a 1999. As ACL estendidas sao identificadas pelos numeros de 100 a 199 e 2000 a 2699.

Por outro lado uma ACL pode também ser identificada por um conjunto de caracteres alfanumericos (string). Isto por vezes facilita bastante na edição ou identificação ou atribuição nas interfaces.

As ACL devem ser implementadas em interfaces e uma interface pode ter varias ACL, mas Somente uma ACL por protocolo, por direcção e claro por interface.

O protocolo pode ser qualquer um pertencente a camada de rede. TCP, UDP ou mesmo ICMP sao válidos. A direcção pode ser inbound (entrada de pacote no roteador) ou outbound (saída de um pacote no roteador).

As vezes é dificil entender a operação de ACLs porque nao se presta atenção a um aspecto muito importante: A sinaxe do comando e o entendimento dos seus parametros.

As listas de acesso padrão possuem o seguinte formato:

access-list access-list-number {deny | permit} source source-wildcard

access-list-number – Numero que pode ser e 1 a 99 ou de 1300 a 1999.
deny                              – Rejeita.
permit                          – Permite.
source                          – Rede, subrede ou host onde o pacote tem origem.
source-wildcard      – A mascara curinga, que identifica que endereços de origem (intervalo) serão classificados.

As listas de acesso estendidas possuem o seguinte formato:

access-list access-list-number {permit | deny} protocol source source-wildcard [operator port] destination destination-wildcard [operator port] [established] [log]

access-list-number – Numero que pode ser e 100 a 199 ou de 2000 a 2699.
deny                              – Rejeita.
permit                          – Permite.
source                          – Rede, subrede ou host onde o pacote tem origem.
source-wildcard       – A mascara curinga, que identifica que endereços de origem (intervalo) serão classificados.
operator                      – serve para identificar as portas e pode ser um dos seguintes: eq (equal), neq (not equal), range (intervalo), lt (lower than), gt (greater than).
port                               – O porto de saída ou entrada (canal) do pacote da rede de origem ou da rede de destino. Muitas destas portas pertencem ou ao sub-protocolo TCP ou ao UDP. Alguns destes protocolos sao o telnet  (23), ftp (20 e 21), smtp (25), http (80).
destination                 – Rede de destino dos pacotes.
destination-wildcard – A mascara curinga que identifica que endereços de destino (intervalo) serão classificados.

Os parametros established e log serão tratados na segunda parte deste artigo que trará, já exemplos práticos.