Un article sur le futur de CBAC (http://bmigette.fr/2008/09/26/configuration-cbac/), le Zone based firewall, qu’est-ce que c’est, à quoi ça sert, comment ça se configure …
Pour l’exemple, nous utiliseront cette topologie:

Topologie dynagen:

hostios = True
sparsemem = True

[localhost]

	[[2621XM]]
		image = ../images/C2600-AD.BIN
		ram = 96
		idlepc = 0x81691494

	[[ROUTER R1]]
		model = 2621XM

	[[ROUTER R2]]
		model = 2621XM
		F0/1 = R1 F0/0
		F0/0 = R3 F0/1

	[[ROUTER R3]]
		model = 2621XM

On prendra R2 comme étant le routeur Firewall.

Introduction

Sur l’ancien modèle de firewall (CBAC – IP INSPECT), il fallait définir des ACLs, et surtout autant d’ACL que l’on avait d’interface utilisées pour le firewall. De plus, on ne pouvait spécifier très précisément l’inspection protocolaire. Avec le nouveau modèle de firewall, le principe est de regrouper les interfaces sous forme de zones, et de spécifier quel type de trafic peut passer d’une zone à une autre. Cela utilise des service-policy et class map (cisco MQF).

Principes:

Ce qui est nouveau:

• Application des politiques de sécurité entre les zones, pas par interfaces (une zone peut être constituée d’une ou plusieurs interfaces)
• Il y a une politiques deny all par défaut (donc pas besoin d’ACL).
• On peut, via l’utilisation de classmap, spécifier des politiques différentes par host et par subnet, ou par protocoles

Note: On peut utiliser conjointement l’IOS firewall classic, et le zone based, sur des interfaces différentes (une interface qui fait partie d’une zone ne pourra faire d’inspection).

Il faut configurer les zones avant d’y ajouter des interfaces. et une interface ne peut faire partie que d’une seule zone à la fois. Les commandes pour créer une zone et y affecter des interfaces sont:

Router(config)#zone security zone_securisee
Router(config-sec-zone)#description zone securise!
Router(config-sec-zone)#exit
Router(config)#interface fastEthernet 0/1
Router(config-if)#zone-member security zone_securisee

Par défaut, le trafic sera supprimé entre:

• Une interface membre d’une zone vers une interface membre d’une autre zone
• Une interface membre d’une zone vers une interface non membre d’aucune zone: Ce traffic ne pourra être autorisé, même avec des ACL ou des service-policy, une interface faisant partie d’une zone ne peux communiquer qu’avec des interfaces dans une zone selon la configuration

Et le trafic sera autorisé entre:

• Deux interface d’une même zone
• Deux interface ne faisant partie d’aucune zone (comportement normal, sauf ACL)
• D’une interface membre d’une zone vers le routeur (= zone « self« , correspond aux paquets destinés aux interfaces du routeur : on peut utilisée cette zone spéciale pour modifier le comportement du routeur)

Note: On peut configurer des interfaces dans différentes VRFs dans une même zone, sous peu que le routage soit correct.

D’une zone à l’autre, trois actions peuvent être prises:

• Pass: Le trafic est autorisé à transiter d’une zone à l’autre
• Inspect: Autoriser le trafic et inspecter le trafic retour (= ip inspect)
• Drop: Supprimer le trafic

Ces actions peuvent bien sur être appliquée différemment selon le type de trafic (à régler par les class-map).

Pour réguler le trafic entre deux zones, il faut créer une zone-pair, que l’on va créer entre deux zone. Une zone pair est unidirectionnelle, il faudra donc créer deux zone-pair pour autoriser le trafic dans les deux sens. Pour autoriser le trafic, on utilisera des service policy, qui utiliseront des class-maps.

Création d’une zone-pair (après création d’une seconde zone):

Router(config)#zone security zone_non_securisee
Router(config-sec-zone)#exit
Router(config)#int f0/0
Router(config-if)#zone-member security zone_non_securisee
Router(config-if)#exit
Router(config)#zone-pair security secure_vers_unsecure source zone_securisee destination zone_non_securisee
Router(config-sec-zone-pair)#service-policy type inspect XXX
Router(config-sec-zone-pair)#exit

On distinguera deux types de class-map, et donc de service-policy, les type protocole (couche 7), et les autres (couche 3 et 4). Les class-map et service policy de couche 7 contiennent des options spécifique au protocole, mais ne peuvent être appliquée directement, il faudra passer par une policy classique. Voici un exemple:

Router(config)#class-map type inspect http l7_http_class
Router(config-cmap)#match ?
  flow      Flow based QoS parameters
  req-resp  HTTP request or response
  request   HTTP request
  response  HTTP response

Router(config-cmap)#match request ?
  arg          HTTP arguments
  body         HTTP body
  header       HTTP Request or Response header
  method       HTTP method
  port-misuse  Violation of HTTP port
  uri          HTTP uri
Router(config-cmap)#match request uri length gt 500
Router(config-cmap)#exit
!Creation de la policy
Router(config)#policy-map type inspect http l7_http_policy
Router(config-pmap)#class l7_http_class
Router(config-pmap-c)#?
Policy-map class configuration commands:
  allow  Allow the packet
  exit   Exit from class action configuration mode
  log    Generate log message
  no     Negate or set default values of a command
  reset  Reset the connection
  <cr>

Router(config-pmap-c)#reset
Router(config-pmap-c)#exit
Router(config-pmap)#exit

le mot clé http correspond au protocole, non au nom de la map.

Création maintenant d’une classe map applicable à une zone-pair

Router(config)#class-map type inspect ALL_HTTP_TRAFFIC
Router(config-cmap)#match protocol http
Router(config-cmap)#exit
Router(config)#policy-map type inspect My_Policy
Router(config-pmap)#class ALL_HTTP_TRAFFIC
Router(config-pmap-c)#service-policy http l7_http_policy
%Please configure inspect action first

Router(config-pmap-c)#inspect
Router(config-pmap-c)#service-policy http l7_http_policy
Router(config-pmap-c)#exit
Router(config-pmap)#exit

Si j’appliques la policy My_Policy sur une zone-pair (ou sur une interface d’ailleurs), cela aura pour effet d’inspecter tout le traffic HTTP et de supprimer les requête HTTP d’on l’URI fait plus de 500 caractères.

Voici l’erreur que j’aurai eu si j’avais tenté d’attacher la policy l7:

Router(config-sec-zone-pair)#service-policy type inspect l7_http_policy
Inspect service-policy attachment failed

Etude de cas:

En reprenant la topologie ci dessus (on considéreras que le routage est déjà fait), je vais créer une politique permettant d’autoriser ICMP a travers le firewall et d’autoriser le trafic HTTP et HTTPS a travers le routeur depuis la zone sécurisée vers la zone non sécurisée.
Note: pour les protocoles de routages, ils sont à destination de la zone self, et sont donc autorisés par défaut.

Création des politiques de sécurité

R2(config)#class-map type inspect match-any HTTP_TRAFFIC
R2(config-cmap)#match protocol http
R2(config-cmap)#match protocol https
R2(config-cmap)#exit
R2(config)#class-map type inspect ICMP_TRAFFIC
R2(config-cmap)#match protocol icmp
R2(config-cmap)#exit
R2(config)#policy-map type inspect http_icmp_policy
R2(config-pmap)#class HTTP_TRAFFIC
R2(config-pmap-c)#inspect
R2(config-pmap-c)#class ICMP_TRAFFIC
R2(config-pmap-c)#pass
R2(config-pmap-c)#exit
R2(config-pmap)#exit
R2(config)#policy-map type inspect icmp_policy
R2(config-pmap)#class ICMP_TRAFFIC
R2(config-pmap-c)#pass
R2(config-pmap-c)#exit
R2(config-pmap)#exit

créations des zones de sécurité et affectation aux interfaces

R2(config)#zone security SECURE
R2(config-sec-zone)#exit
R2(config)#zone security UNSECURE
R2(config-sec-zone)#exit
R2(config)#interface f0/1
R2(config-if)#zone-member security SECURE
R2(config-if)#interface f0/0
R2(config-if)#zone-member security UNSECURE
R2(config-if)#exit
R2(config)#

Et affectation des politiques de sécurité aux zone-pair.

R2(config)#zone-pair security SECURE_TO_UNSECURE source SECURE dest UNSECURE
R2(config-sec-zone-pair)#service-policy type inspect http_icmp_policy
R2(config-sec-zone-pair)#exit
R2(config)#zone-pair security UNSECURE_TO_SECURE source UNSECURE dest SECURE
R2(config-sec-zone-pair)#service-policy type inspect icmp_policy
R2(config-sec-zone-pair)#exit
R2(config)#

Et on teste, sur R1:

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/27/68 ms
R1#telnet 192.168.1.2 80 !test HTTP
Trying 192.168.1.2, 80 ... Open
zz
HTTP/1.1 400 Bad Request
Date: Fri, 01 Mar 2002 02:00:22 GMT
Server: cisco-IOS
Accept-Ranges: none

400 Bad Request

[Connection to 192.168.1.2 closed by foreign host]
R1#telnet 192.168.1.2 443 !test HTTPS
Trying 192.168.1.2, 443 ... Open
s
[Connection to 192.168.1.2 closed by foreign host]

sur R2:

R3#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms
R3#telnet 192.168.0.1 80 !test HTTP
Trying 192.168.0.1, 80 ...
% Connection timed out; remote host not responding

R3#telnet 192.168.0.1 443 !test HTTPS
Trying 192.168.0.1, 443 ...
% Connection timed out; remote host not responding

R3#

Et voila!

Recent Entries

• Reponse tardive aux commentaires
• CCIE #43827
• VRF-Aware GETVPN, DMVPN, et FLEXVPN Spoke To Spoke
• Mes articles sur supportforums
• Définir des « handlers » personnalisés pour associer les liens d’un protocole avec une application perso.
• DMVPN over GETVPN avec KS COOP (redondance) et KS Forwarding
• EAP-TLS avec Autorité de certification autonome (Standalone CA) sous Windows 2003
• Static subnet NAT avec VRF pour monter des ‘PODs’ (LAB)
• Capture WiFi en mode monitor sous windows, et capture par process
• Comment taper un point d’interrogation ‘?’ dans un mot de passe ?

This entry was posted on lundi, février 23rd, 2009 at 21:28 and is filed under CCSP, IINS (ccna security), Sécurité réseau, SNRS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.