Basiskonfiguration einer Cisco Firewall – ASA5505

Um Netzwerkbereiche abzuschotten oder vor unzulässigen Zugriffen aus dem World Wide Web zu schützen, kommt man um eine Firewall, egal ob physisch oder softwaretechnisch gelöst, nicht mehr herum. Gang und Gebe war dies in Unternehmen schon lange, wenn nicht schon immer, aber auch für Privatpersonen ist dies nicht unbedingt uninteressant oder weniger wichtig. Auch hier finden sich genug Beispiele oder Szenarien, in denen der Gebrauch und die Funktionalität einer Firewall im Heimnetzwerk doch relativ notwendig oder zumindest einen Gedanken wert sein könnte. Natürlich schützt auch die beste Firewall nicht zu hundertprozent von Content, den man nicht unbedingt sehen will oder vor Angriffen in Form eines Exploits oder sonstigem. Wie hoch der Schutz und die Filterung von Verbindungen im Endeffekt sein sollte, muss selbst definiert und dann schlussendlich auch konfiguriert werden.

Man unterscheidet die Firewall in zwei verschiedene Typen. Transparent oder Routed Firewall. Der Unterschied dieser Firewall Varianten liegt im Grunde auf der Sichtbarkeit für andere Endgeräte oder Netzwerken. Eine transparente Firewall hat den Vorteil nicht erkannt zu werden bei Anfragen oder Verbindungen. Es gibt keinen Hop der mitgezählt wird oder auch bei Traces ist diese nicht zu erkennen, dass die Verbindung über eine Firewall geroutet wurde. Allerdings kann für die Administration dieser Vorteil schnell zu einer Stolperfalle werden. Im Umkehrschluss heißt dies auch, dass bei Troubleshooting diese nicht auf Anschlag erkenntlich ist. Spätestens bei Verbindungen oder Paketen die eigentlich nicht gefiltert werden sollten, bekommt dieses Problem der Administrator deutlich zu spüren.

 

 

Daher ist die Verwendung von Routed Firewalls gerade in großen Netzwerken beliebter und findet eher Fuß als die transparente Variante. Dem Admin ist es nun möglich die Firewall zu sehen und dem Problem dann von Layer zu Layer oder Hop zu Hop nachzugehen um eine Lösung herbei zu zaubern. Tolle Wesen diese Admins, manche munkeln Zauberkräfte zu haben um Probleme zu nicht Problemen zu verwandeln… lassen wir Gerüchte Gerüchte sein und konzentrieren uns eher auf unsere Netzwerkstruktur für das folgende Szenario.

 

 

Der Router in unserem Heimnetzwerk ist das Tor zum Internet, auch Gateway genannt. Direkt am Router angeschlossen befindet sich die Firewall, welche nun anhand ihrer Konfiguration entscheidet, welche Verbindungen in das abgesicherte Netzwerk aufgebaut werden darf. Standardmäßig sollten die Endgeräte hinter der „Wall of Fire“, lustiges Synonym, alles nach draußen erreichen dürfen, aber nicht alles darf das abgesicherte Netzwerk erreichen. Das ist der Sinn und Zweck des Netzwerkgerätes und warum es überhaupt eingesetzt wird.

Hast du ja bis dato toll erläutert du IT-Frickel, aber wie konfigurier ich das Ding nun!? – Gar nicht mal so schwer, pass auf.

 

Um die Basiskonfiguration auf die ASA zu bekommen, muss man sich mit dieser verbinden. Da diese auch eine Switching Funktionalität besitzt kann man sich direkt per Kupfer auf einen der sieben Ports 0/1 bis 0/7 stecken oder man baut eine Konsolenverbindung auf. Der Vorteil bei der 5505 ist klar die bereits von Werk aus konfigurierte DHCP und HTTP Server auf den Ports im VLAN1.

Der angeschlossene Rechner muss nur die IPv4 Konfiguration auf das Subnetz 192.168.1.1 255.255.255.0 umstellen und kann auch schon direkt loslegen. Selbst mit der Standardkonfiguration kann über 0/0 die Anbindung an das Internet beziehungsweise an den Router erfolgen. Duch die zugewiesen IP-Adresse durch den DHCP des Routers, setzt die ASA ihre Defaultroute und damit würde dem Surfen nichts mehr im Wege stehen.

 

Als Erstes wird der Hostname gesetzt, in meinem Fall fw1-asa.

(config)#   hostname fw1-asa

 

Man muss einen Domain Namen zwingendermaßen hinterlegen, um beispielsweise einen SSH-Key generieren zu lassen. Die Angabe definiert auch die Domain Name für die Firewall selbst.

(config)#   domain-name test.lab

 

Damit der Zugriff auf die EXEC Ebene des Switches erfolgen kann, muss hier ein starkes Passwort gesetzt werden, bei dem man die Verschlüsselungsstärke selbst definieren kann, am Ende des Befehls durch den Privilege Level.

(config)#   enable password supertopsecret59

 

Desweiteren sollte man auch eine allgemeine password encryption erstellen. Damit werden alle Passwort Attribute mit AES verschlüsselt und nicht mehr im Klartext so einfach lesbar, falls neugierige Blicke über die Schulter stöbern.

(config)#   password encryption aes

 

Von Werk aus befindet sich die ASA als Routed Firewall konfiguriert, man kann aber auch auf den transparenten Modus umschalten.

(config)#   firewall transparent

 

Wichtig ist außerdem noch sicher zu stellen, dass man eine lokale Aufthentifizierung konfiguriert, um im Notfall auch lokal auf das Gerät zu kommen. Das erfolgt über AAA und dem daraufhin definierten username mit password. Wenn man auch einen TACACS mit angeben möchte, kann man vor dem LOCAL noch die Option TACACS(+) hinzufügen.

(config)#   aaa authentication ssh console LOCAL
(config)#   aaa authentication enable console LOCAL
(config)#   aaa authentication http console LOCAL
(config)#   aaa authentication telnet console LOCAL
(config)#   aaa authentication serial console LOCAL

(config)#   username admin password localaccess765 encrypted privilege 15

 

Als Nächstes definieren wir die beiden Interface für das interne Netzwerk hinter der Firewall (inside) und dem ausgehenden und eingehenden Verkehr aus und zum Internet (outside).

(config)#   interface vlan 1
(config-if)#   nameif inside
(config-if)#   security-level 100
(config-if)#   ip address 192.168.100.1 255.255.255.0
(config-if)#   no sh
(config-if)#   exit

(config)#  interface vlan 2
(config-if)#   nameif outside
(config-if)#   security-level 0
(config-if)#   ip address dhcp setroute
(config-if)#   no sh
(config-if)#   exit

 

Natürlich kann man über die Interface noch die IP-Konfiguration anpassen. Beispielsweise kann dem vlan1 ein anderes Subnetz 192.168.100.1 255.255.255.0 zur Verfügung gestellt werden oder dem vlan2 sagen wir ausdrücklich mit ip address dhcp setroute, dass er seine IPv4 Konfiguration über DHCP erhält.

(config)#  interface eth0/0
(config-if)#  switchport access vlan 2
(config-if)#   no sh
(config-if)#   exit

 

Da die Anbindung der Firewall über den Port 0/0 erfolgt, sollte dort das vlan2 für das outside und auf den Ports 0/1 bis 0/7 dann logischweise das vlan 1 für das inside konfiguriert werden. Es wäre allerdings etwas paradox, die nicht zu verwendeten Ports aktiviert zu lassen, wenn man eine Firewall für mehr Sicherheit einbaut. Also immer schön ausschalten und nur die notwendigsten Anschlüsse aktivieren.

 

Im Zuge dessen sollte man vorab die einzelnen Subnetze noch als Network Objects definieren. Der Grund dafür ist relativ plausibel, durch die Angabe der Objects können beispielsweise die ACL’s oder DHCP Konfiguration später überschaubarer definiert werden.

(config)#   object network object_inside
(config-network-object)#   subnet 192.168.100.0 255.255.255.0

(config)#   object network object_outside
(config-network-object)#   subnet 192.168.0.0 255.255.255.0

(config)#   object network object_any
(config-network-object)#   subnet 0.0.0.0 0.0.0.0

 

Damit man nicht jeden einzelnen Rechner mit manueller IP-Konfiguration versorgen muss und man sich das lästige Herausfinden von freien IP-Adressen sparen kann, sollte ein DHCP konfiguriert werden. Dafür definiert man einen DHCP-Pool beziehungsweise eine IP-Range, welche dem DHCP zur Verfügung gestellt wird. Der DHCP soll gut neunzig Adressen umfassen und auf dem inside Interface aktiv sein.

(config)#  dhcpd address 192.168.100.10-192.168.100.100 inside
(config)#   dhcpd enable inside

 

Damit die Zuordnung des Interfaces später mit der Access-List (ACL) passt, legt man mit nameif quasi die Bezeichnung oder den ID-Tag fest. Dadurch ist eine genaue Zuordnung und Verknüpfungen später möglich. Der Wert des security-level entscheidet, wie vertrauenswürdig die Schnittstelle und deren Traffic ist. Standardmäßig bekommt das outside Interface automatisch das security-level 0 für nicht sehr vertrauenswürdig und das inside Interface automatisch das security-level 100 für sehr vertrauenswürdig. Daher kann von einem Netzwerkbereich mit einem höheren security-level Wert immer in ein Netzwerk mit einem niedrigeren security-level zugegriffen werden.

Durch das Hinzufügen zweier Befehle wird der Verkehr untereinander stattgegeben.

(config)#  same-security-traffic permit inter-interface
(config)#  same-security-traffic permit intra-interface

 

Danach können die ACL’s angelegt werden und mit den individuellen Regeln befüllt werden. Ich habe beispielsweise mal ein ip any any auf beide konfiguriert. Dies bedeutet, dass sämtlicher IP-Verkehr in beiden Richtungen erlaubt ist.

(config)#   access-list inside extended permit ip any any
(config)#   access-list outside extended permit ip any any

 

Erlaube (permit) jeglichen IP-Verkehr (ip) von jedem einzelnen Client im inside Netzbereich (any) IN/ZU jedem einzelnen Client im Zielnetzwerk (any).
Erlaube (permit) jeglichen IP-Verkehr (ip) von jedem einzelnen Client im outside Netzbereich (any) IN/ZU jedem einzelnen Client im Zielnetzwerk (any).

Ob die Regeln sinnvoll sind müsst ihr wissen, ich wollte euch nur den Aufbau der ACL-Regeln kurz beschreiben.

 

Damit die ACL für den inside Netzbereich auch funktioniert, wird anhand einer access-group die Verknüpfung mit dem inside Interface erstellt. Das geschieht dank der Angabe des nameif auf den jeweiligen Schnittstellen. Das gleiche Prinzip dann natürlich auch für das outside. Danach können die ACL’s angelegt werden und mit den individuellen Regeln befüllt werden. Ich habe beispielsweise mal ein ip any any auf beide konfiguriert. Dies bedeutet, dass sämtlicher IP-Verkehr in beiden Richtungen erlaubt ist.

(config)#   access-group inside in interface inside
(config)#   access-group outside in interface outside

 

Danach wäre es noch hilfreich, die Firewall von remote zu erreichen. Am besten per SSH, dafür muss allerdings auch ein SSH-Key generiert werden. Der Schlüssel sollte eine Stärke von 2048 Bit haben und nicht weniger.

(config)#   crypto key generate rsa modulus 2048

 

Sobald dies geschehen, muss natürlich auch angegeben werden, welcher Host überhaupt eine SSH-Session auf die Firewall aufbauen darf und wie diese auszusehen hat. Ob man einen Hostkeycheck haben will, ist jedem selbst überlassen, aber ich möchte gerne gefragt werden, bevor dieser ausgetauscht wird.

(config)#   ssh stricthostkeycheck

 

Desweiteren sollten SSH-Verbindungen beispielsweise aus dem Heimnetzwerk erreichbar sein, kann aber auch aus dem Subnetz des Firmennetzes sein. Natürlich soll der Aufbau aus dem outside als auch aus dem inside erlaubt sein.

(config)#   ssh 192.168.0.0 255.255.255.0 outside
(config)#   ssh 192.168.100.0 255.255.255.0 inside

 

Und zu guter Schluss, wird ein Timeout für SSH-Sessions gesetzt.

(config)#   ssh timeout 60

 

 

Das sollte als Basiskonfiguration erst einmal ausreichen um die Firewall mit den wichtigsten Funktionalitäten betriebsfähig zu machen.

Natürlich kann man bei weitem noch mehr konfigurieren, zum Beispiel das Festlegen von DNS, DHCP, NAT, SNMP, TACACS, RADIUS, VPN und vieles vieles mehr. Darauf möchte ich allerdings nicht explizit eingehen, da dies den Rahmen bei weitem sprengen würde. Eventuell werde ich auf die einzelnen Punkte anhand von Artikeln zum Thema Firewall zurückgreifen und detailierter berichten.

 

over & out,

jonsch

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.