Cisco PIX Konfigurationsbeispiele

Die Cisco PIX ist eine veraltete Firewall-Lösung von Cisco. Je nach dem kann sie ungeachtet dessen durchaus noch sinnvolle Einsatzzwecke haben, z. B. als TCP-Normalizer.

Seit PIX OS Version 7 unterstützt die PIX ausschliesslich ACL-basierte Regeln, welche an Interfaces gebunden werden (access-group). Ab dieser Version „fühlt“ sich die PIX deutlich mehr wie eine ASA an.

Version 6(3)5 ist die letzte Version der 6er Reihe, welche

• noch die alte Konfigurationsvariante mittels Conduit und Outbound/Apply unterstützt,
• auf der kleinen PIX 501 läuft,
• ausschliesslich IPv4 unterstützt.

Weil die Dokumentationsquellen zu bestimmten Anwendungszwecken der Version 6 immer seltener werden, folgen hier ein paar „Kochrezepte“.

Firewall: Einfaches Drin-Draussen-Szenario

Dazu werden die Interfaces benannt und mit den zugehörigen Security Leveln versehen:

nameif ethernet0 outside security0
nameif ethernet1 inside security100

Den Interfaces werden die Adressen zugewiesen und eine Defaultroute nach extern konfiguriert:

ip address outside 198.51.100.10 255.255.255.0
ip address inside 192.168.178.1 255.255.255.0
route outside 0.0.0.0 0.0.0.0 217.28.96.177 1

Das Interface outside wird dem NAT-Pool 1 zugewiesen und eine NAT-Regel für das lokale LAN via NAT-Pool 1 erstellt.

global (outside) 1 interface
nat (inside) 1 192.168.178.0 255.255.255.0 0 0

Mit dieser Grundkonfiguration dürfen alle Pakete vom höheren Security Level zum kleineren passieren; ein Konzept was sich bis heute auch bei der ASA gehalten hat und für eine deutliche Vereinfachung der Konfiguration sorgen kann.

Conduit

Damit können Verbindungen von extern (outside, niedriger security level) nach intern (inside, höherer security level) durchgelassen werden.

conduit permit tcp host 198.51.100.10 eq 8333 any

Damit werden TCP-Verbindungen auf die Adresse 198.51.100.10, Port 8333 von überall (any) zugelassen. In diesem Fall ist 198.51.100.10 die Adresse des Outside-Interfaces. Es gibt keinen Parameter wie bei der ASA, eine Schnittstelle als Ziel anzugeben.

In aller Regel sind die Inside-Hosts Teil eines Netzwerkes nach RFC1918. Diese sind per Definition also nicht von extern erreichbar und müssen daher nach drin geNATtet werden.

Es wird also TCP-Port 8333 des Interfaces (outside) nach Port 8333 des Hosts 192.168.178.10 am Interface inside weitergereicht:

static (inside,outside) tcp interface 8333 192.168.178.10 8333 netmask 255.255.255.255 0 0 

Verwirrenderweise sind die Angaben in der Klammer verglichen mit dem Verlauf der Konfigurationszeile genau verkehrt herum.

Outbound/Apply

Damit können anhand des Security-Level-Gefälles eigentlich erlaubte Verbindungen unterbunden werden. Folgende Details sind wichtig:

• Im Gegensatz zur ASA-Konfiguration sitzt am Ende der Outbound-Liste kein implizites deny,
• im Gegensatz zur ASA fällt ein Paket durch alle Regeln durch und das Endergebnis zählt,
• die Ähnlichkeit mit den numerischen Standard-ACLs von Cisco IOS sind frappierend,
• mit dem apply-Kommando wird festgelegt, ob sich die Adressen auf die Quelle oder das Ziel beziehen,
  • wobei die Ports unabhängig von outgoing_src oder outgoing_dest immer Zielports darstellen.
• Es können mehrere Outbound-Regelsätze existieren, die per apply an das gleiche Interface geknotet werden,
• es gibt nicht nur die Regelbefehle deny und permit, sondern auch except (näheres siehe Doku bei Cisco in den Weblinks).

Einfaches Beispiel folgt. Zwecks einfacherer Regelpflege werden zuerst alle Verbindungen unterbunden und danach selektiv erlaubt:

outbound   1 deny 0.0.0.0 0.0.0.0 0 ip
outbound   1 permit 192.168.178.0 255.255.255.0 0 icmp
outbound   1 permit 192.168.178.0 255.255.255.0 3 icmp
outbound   1 permit 192.168.178.0 255.255.255.0 11-13 icmp
outbound   1 permit 192.168.178.0 255.255.255.0 53 udp
outbound   1 permit 192.168.178.0 255.255.255.0 53 tcp
outbound   1 permit 192.168.178.0 255.255.255.0 80 tcp
outbound   1 permit 192.168.178.0 255.255.255.0 123 udp
outbound   1 permit 192.168.178.0 255.255.255.0 443 tcp
outbound   1 permit 192.168.178.0 255.255.255.0 8333 tcp

Final wird nun diese Liste an das inside-Interface geknotet:

apply (inside) 1 outgoing_src

Damit z.&thinsp.B. nicht alle Pakete über ein evtl. konfiguriertes VPN zu Zieladressen gemäß RFC1918 laufen dürfen, werden in einer zweiten Outbound/Apply-Gruppe Einschränkungen nach Zieladresse vorgenommen:

outbound   2 deny 192.168.0.0 255.255.0.0 0 ip
outbound   2 deny 172.16.0.0 255.240.0.0 0 ip
outbound   2 deny 10.0.0.0 255.0.0.0 0 ip
outbound   2 permit 192.168.0.0 255.255.0.0 0 icmp
outbound   2 permit 192.168.0.0 255.255.0.0 3 icmp
outbound   2 permit 192.168.0.0 255.255.0.0 11-13 icmp
outbound   2 permit 192.168.0.0 255.255.0.0 53 udp
outbound   2 permit 192.168.0.0 255.255.0.0 53 tcp
outbound   2 permit 192.168.0.0 255.255.0.0 80 tcp
outbound   2 permit 192.168.0.0 255.255.0.0 123 udp
outbound   2 permit 192.168.0.0 255.255.0.0 443 tcp
outbound   2 permit 172.16.0.0 255.240.0.0 0 icmp
outbound   2 permit 172.16.0.0 255.240.0.0 3 icmp
outbound   2 permit 172.16.0.0 255.240.0.0 11-13 icmp
outbound   2 permit 172.16.0.0 255.240.0.0 53 udp
outbound   2 permit 172.16.0.0 255.240.0.0 53 tcp
outbound   2 permit 172.16.0.0 255.240.0.0 80 tcp
outbound   2 permit 172.16.0.0 255.240.0.0 123 udp
outbound   2 permit 172.16.0.0 255.240.0.0 443 tcp
outbound   2 permit 10.0.0.0 255.0.0.0 0 icmp
outbound   2 permit 10.0.0.0 255.0.0.0 3 icmp
outbound   2 permit 10.0.0.0 255.0.0.0 11-13 icmp
outbound   2 permit 10.0.0.0 255.0.0.0 53 udp
outbound   2 permit 10.0.0.0 255.0.0.0 53 tcp
outbound   2 permit 10.0.0.0 255.0.0.0 80 tcp
outbound   2 permit 10.0.0.0 255.0.0.0 123 udp
outbound   2 permit 10.0.0.0 255.0.0.0 443 tcp
outbound   2 permit 0.0.0.0 0.0.0.0 0 ip
apply (inside) 2 outgoing_dest

Im Endergebnis werden beide ACL-Gruppen UND-Verknüpft. Dadurch lassen sich Einschränkungen nach Quelle UND Ziel definieren.

Weblinks

• Cisco PIX in der englischsprachigen Wikipedia
• PIX 5 Command Reference bei Cisco.com