Virtuelle Firewalls für Institutsnetze

Informationen für potentielle und tatsächliche Betreiber von virtuellen Firewalls.

Überblick

Das LRZ bietet für Institute und Organisationen im Münchner Wissenschaftsnetz (MWN) die Möglichkeit, eine virtuelle Firewall auf LRZ-Hardware zu betreiben. Dabei handelt es sich um Spezial-Hardware in den Backbone-Routern des MWNs. Diese Spezial-Hardware erlaubt es, darauf mehrere Firewall-Instanzen zu betreiben und unabhängig voneinander zu verwalten. Die zu schützenden Subnetze werden über Virtuelle LANs (VLAN), einer logischen Netzschicht, zur jeweils zuständigen Firewall-Instanz geführt und dort gefiltert.

Ob eine virtuelle Firewall eingerichtet werden kann, hängt im Einzelfall von der jeweiligen Netztopologie ab und muß vorab geklärt werden. Derzeit stehen auf 5 Routern jeweils 20 virtuelle Firewalls zur Verfügung.

Das LRZ stellt eine einfache Grundkonfiguration bereit, die der Verwalter des Instituts/der Organisation individuell anpassen muß.

Der Aufbau und Betrieb einer Firewall im Allgemeinen erfordert zumindest Grundkenntnisse in Datennetzen. Darüberhinaus ist eine regelmäßige Kontrolle der anfallenden Log-Daten wichtig, um die Funktion der Firewall sicherzustellen. Beides trifft natürlich auch auf eine virtuelle Firewall zu. Aus diesem Grund ist es von Vorteil, wenn eine virtuelle Firewall von einer größeren Organisationseinheit für ihre Mitglieder betrieben wird, z.B. von einer Fakultät für die einzelnen Lehrstühle. Knowhow und Personalresourcen für den Betrieb müssen dann nur an einer Stelle zentral vorhanden sein und belasten damit nicht jeden Lehrstuhl.


Einrichten einer virtuellen Firewall (Workflow)

Klärung der Netztopologie

  • Ansprechpartner vor Ort: Netzverantwortlicher

Der Netzverantwortliche klärt die Netztopologie. Folgende Voraussetzungen müssen erfüllt sein:

  • Strukturierte Verkabelung
    (Switches, kein Koaxkabel)
  • Prinzip: 1 Subnetz pro VLAN
    (Um diese Voraussetzung zu erfüllen, können weitere VLANs durch das LRZ eingerichtet werden)
  • Subnetz gehört vollständig dem(r) Institut/Organisation oder Teilhaber sind sich einig

Beantragen der virtuellen Firewall

Das Aktivieren der virtuellen Firewall veranlasst der Netzverantwortliche über das Servicedesk-Portal (Neuen Incident mit Service 'Firewalls' anlegen).

Die E-Mail muß folgende Informationen enthalten:

  • Name des(r) Institutes/Organisation
  • Lokaler Ansprechpartner (Telefon, E-Mail)
  • Interne(s) Subnetz(e)/VLAN(s) (später hinter der virtuellen Firewall)

Das Firewall-Team nimmt dann Kontakt mit dem lokalen Ansprechpartner auf und aktiviert die virtuelle Firewall.


Online Dokumentation

Graphische Verwalterschnittstelle: Cisco Adaptive Security Device Manager (ASDM)

Betriebssystem


FAQ

Allgemeines

  1. Was ist der ASDM?
    ASDM ist das Akronym für Adaptive Security Device Manager. Damit bezeichnet Cisco die graphische Benutzerschnittstelle für verschiedene Komponenten im Bereich Netzsicherheit. Damit werden auch die virtuellen Firewalls verwaltet.
  2. Was ist das CLI?
    CLI ist das Akronym für Command Line Interface. Eine virtuelle Firewall kann nicht nur über den ASDM verwaltet werden, sondern auch über das CLI. Das CLI ist per SSH erreichbar, wobei IP-Adresse, Kennung und Passwort analog zum ASDM verwendet werden.
  3. Was bedeutet ACL und ACE?
    ACL ist das Akronym für Access Control List. Eine ACL ist eine geordnete Menge von Filterregeln, sogenannten Access Control Entries (ACE), mit der innerhalb einer Firewall der Zugriff auf einen Netzbereich beschränkt wird. Jedes Paket, das in diesen Netzbereich geschickt wird, durchläuft sequentiell die ACL und wird anhand von IP-Adressen und Ports daraufhin überprüft, ob ein ACE zutrifft. Der ACE, der zuerst zutrifft, bestimmt über das weitere Schicksal des Paketes. Handelt es sich um einen Permit-ACE, kann das Paket seinen Weg in den Netzbereich fortsetzen. Im Fall eines Deny-ACE ist die Reise des Paketes zu Ende und es wird verworfen. Trifft keiner der konfigurierten ACEs zu, schlägt die implizite Deny-ACE zu.
  4. Was muß ich tun, damit eine Verbindung zwischen einem externen und einem internen Rechner über meine virtuelle Firewall zustande kommt?
    Ein Paket, das der externe Rechner schickt, passiert zuerst das Outside-Interface und dann ein Inside-Interface der Firewall bis es schließlich den internen Rechner erreicht. Für jedes Interface können zwei ACLs definiert werden: eine Incoming-ACL und eine Outgoing-ACL. Auf das Paket wirken auf seinem Weg durch die Firewall zwei ACLs, nämlich die Incoming-ACL des Interfaces, das der Eingang zur Firewall ist, und die Outgoing-ACL des Interfaces, das der Ausgang aus der Firewall ist. In unserem Fall sind das die Incoming-ACL des Outside-Interfaces und die Outgoing-ACL des Inside-Interfaces. Die Incoming-ACLs aller Interfaces sind standardmäßig definiert und enthalten eine implizite Deny-ACE. Die Outgoing-ACLs werden erst bei Bedarf durch den Verwalter definiert und stellen ursprünglich kein Hindernis dar. Deshalb reicht es aus, wenn der Verwalter einen Permit-ACE in der Incoming-ACL des Outside-Interfaces für das Paket des externen Rechners einpflegt, damit eine Verbindung zum internen Rechner zustande kommt. Um die umgekehrte Richtung muß sich der Verwalter nicht kümmern, das erledigt die Firewall automatisch (Stateful Firewall).
  5. Gibt es bei der Outgoing-ACL eines Interfaces eine implizite Deny-Regel?
    Ja. Allerdings wirkt diese erst, wenn die Outgoing-ACL eines Interfaces definiert wird. Das passiert, wenn ein ACE in die ACL eingepflegt wird, selbst wenn dieser nicht "enabled" ist. Wenn die Outgoing-ACL eines Interfaces keinen ACE enthält, ist sie nicht definiert und die implizite Deny-Regel wirkt nicht.
  6. Wie lösche ich eine komplette ACL (inklusive Kommentaren)?
    FWSM/hostname(config)# clear configure access-list NAME_OF_ACL
  7. Wie erlaube ich VPN-Nutzern den Zugriff auf das Institutsnetz?
    Im ASDM unter Configuration|Global Objects|Hosts/Networks|iew Unkown Hosts/Networks Groups... finden sich Netzobjekte mit sprechenden Namen. Z.B. enthalten die Objekte VPN-private-LMU und VPN-public-LMU die vom VPN-Gateway an LMU-Angehörige vergebenen privaten und öffentlichen IP-Adressen. Diese Netzobjekte müssen zuerst dem Outside-Interface zugeordnet werden. Danach können sie als Quelladresse (Configuration|Security Policy|Access Rules|Add|Source Host/Network|Group) in entsprechenden Permit-ACEs verwendet werden.
  8. Kann IPv6-Verkehr gefiltert werden?
    Derzeit kann IPv6-Verkehr nur durch eine virtuelle Firewall im Routed-Modus gefiltert werden.
    Eine virtuelle Firewall im Transparent-Modus kann derzeit keinen IPv6-Verkehr filtern. Allerdings kann eine virtuelle Firewall im Transparent-Modus so konfiguriert werden, dass IPv6-Verkehr die Firewall UNGEFILTERT passieren kann.
  9. Kann nach MAC-Adressen gefiltert werden?
    Nein.
  10. Funktioniert ein Microsoft NLB-Cluster im Multicast-Modus hinter einer virtuellen Firewall?
    Ja.
  11. Welche Resourcen sind limitiert?
    Warum und wie die Resourcen einer virtuellen Firewall (VFW) begrenzt werden, und welche Resourcen es gibt, siehe Configuring Resource Management.
    Jede VFW auf einem LRZ-FWSM befindet sich in einer Resourcen-Klasse. Die Resourcen-Klasse bestimmt, welchen Anteil der insgesamt zur Verfügung stehenden Recource eine VFW verbrauchen kann. In welcher Resourcen-Klasse sich eine VFW befindet, findet sich in der Ausgabe des folgenden Kommandos in der Spalte Class:
    show context
    Die folgende Tabelle zeigt die derzeit definierten Resourcen-Klassen und deren absolute Maximalwerte für die wichtigsten Resourcen:
    Resourcen-Klasse % aller verfügbaren Resourcen Conns absolut

    (999.900 verfügbar)

    Xlates/Hosts absolut

    (266.144 verfügbar)

    AA 5 50.000 13.107
    A 4 40.000 10.484
    BB 3 30.000 7863
    B 2 20.000 5.242
    CC 1 10.000 2.621
    Die Absolutwerte in Bezug auf die insgesamt verfügbaren Resourcen entsprechen nicht exakt dem prozentualen Anteil - das liegt offensichtlich an den von Cisco verwendeten Algorithmen.
    Wieviel Conns bzw. Xlates man gegenwärtig verbraucht, zeigen folgende Kommandos:
    show conn count
    show xlate count
    Ist das Resourcen-Limit bei Conns bzw. Xlates erreicht, können keine neuen Verbindungen mehr aufgebaut werden. Diesen Zustand erkennt man sofort in den ASDM Syslog Messages.
  12. Wie konfiguriere ich meine VFW skriptbasiert?
    Die folgenden drei Möglichkeiten sind sicher nicht die einzigen, aber sie werden entweder von Kunden oder vom LRZ genutzt:
    Firewall Builder (http://www.fwbuilder.org/) Ciscocmd (http://sourceforge.net/projects/cosi-nms/files/ciscocmd/) Expect-Skript, z.B.#!/usr/bin/expectset timeout 20# User configurationset password PASSWORD# Loginspawn ssh admin-fw@1.2.3.4expect "password:"send "$password\n"expect "*>"send "enable\n"expect "Password:"send "$password\n"expect "*#"# Commands# Uncomment following line if you want an interactive session# interact# Shows the ssh configurationsend "show running-config ssh\n"expect "*#"exitEin erweitertes Expect-Skript kann auch das Passwort abfragen oder eine Datei mit Kommandos einlesen und ausführen. Dazu finden sich viele Beispiele im Internet.  
  13. Warum funktioniert das TSM-Backup nicht?
    Bei der Kommunikation zwischen TSM-Client und TSM-Backup wird manchmal der Server-Port 1720 verwendet. Dieser Port spielt auch bei der Kommunikation über das Protokol H.323 (IP-Telefonie) eine wichtige Rolle. Wenn in der VFW "Application Layer Protocol Inspection" für H.323 aktiviert ist, wird der Port 1720 überwacht und jede Kommunikation, die nichts mit H.323 zu tun hat, geblockt. Um das zu verhindern, kann entweder der TSM-Server-Port bzw. der TSM-Server geändert oder "Application Layer Protocol Inspection" für H.323 dektiviert werden (siehe Configuration/Firewall/Service Policy Rules/Global Policy/<class name>/Rule Actions/Protocol Inspection).

ASDM

Version 6.2(2)F

  1. Welche Browser- und Java-Plugin-Versionen werden unterstützt?
    Siehe "ASDM Client Operating System and Browser Requirements".
  2. Kann ich OpenJDK/IcedTea verwenden?
    Nein.
  3. Ich habe Probleme die ASDM-Verwaltungsoberfläche zu erreichen
    Die ASDM-Verwaltungsobefläche benötigt ein 32-Bit Java. Leider haben wir die Erfahrung gemacht, dass die Standaloneanwendung beim Updates von Java neu installiert werden muss. Wir empfehlen daher den Zugriff über die Webschnittstelle mittels des Buttons [Run ASDM].
    Bei neueren Java-Versionen ab 1.7.0-51 ist es notwendig für die Firewall eine Site-Exception (deutsch: Liste der ausgenommenen Webseiten) für die Firewall-IP einzutragen. Gehen Sie bitte dazu unter Windows in die Systemsteuerung und wählen dort den Punkt Java an. Unter dem Reiter Sicherheit tragen Sie die IP Ihrer Firewall (https:// <Ihre Firewall-Verwaltungs-IP>) ein. Dies dann bitte mit [ok] und [Anwenden] bestätigen. Sicherheitshalber den Browser neustarten und den Zugriff erneut versuchen.

Links