orm@doc-tcpip.org

Erstellt: Mai 2003 - Letzte Modifikation: August 2003

[ Main | Local ]


Kurzes HowTo zur AIX Firewall

Falls es noch jemanden interessiert..

Die Firewall prüft für jedes Paket, wo es herkommt, wo es hin will und was es für eine Art von Paket ist (also das Protokoll). Diese Informationen werden gegen ein Regelwerk geprüft, und eine für die Charakteristiken des Paketes passende Regel muß vorhanden sein.

Diese Filter-Regeln werden nicht einzeln aufgebaut, sondern über mehrere logische Zwischenschritte bzw. Ebenen.

Die kleinste Einheit ist die Regel (Rule). Hier ist allgemein, also unabhängig von Adaptern und Adressen, festgelegt, was für eine Maßnahme auf ein bestimmtes Paket angewendet werden soll. Das ist die Ebene der Portnummern und Protokolle, auch der Tunnel.

Ein Satz allgemeiner Regeln, die für einen bestimmten Zweck nötig sind, wird zu einem Service zusammengefaßt. Die Ebene der eigentlichen Dienste (Telnet, FTP etc.).

Einer oder mehrere Services geben zusammen mit Netzwerk-Objekten (Adaptern, Netze) dann die Verbindung (Connection). Hier werden Regeln und Services an bekannte IP Adressen oder Adapter gebunden.

Die eigentlichen Filter, die dann wirklich auf die Pakete angewendet werden, entstehen erst im Moment des Auswertens der obigen Konfigurationen. Diese Filter werden nicht festgeschrieben, sondern im Speicher gehalten.

 
.           ______
.           |     |
.           |     |
.  Secure   | FW  |   Non-Secure
.           |     |
.           |_____|
.              ^
.              |                        /=  Service  <== Rule [Rule, Rule]
.              |                       /
.           Filter  <==   Connection  <===  Service  <== Rule [Rule, Rule]
.                             ^
.                             |
.                       Network-Objects

Die IBM Firewall (SecureWay Firewall heisst sie jetzt) besteht aus einer Ansammlung von einzelnen Befehlen (jeweils als ein Binary) und einiger Kernel Extensions. Die Befehle weisen eine verschieden große Anzahl von Unterbefehlen auf. Diese werden durch ein Schlüsselwort (cmd) eingeleitet. Mit den Befehlen kann man daher alles verändern oder nur ansehen, je nach Unterbefehl.

Natürlich gibt es auch eine recht komfortable GUI. Diese wird nach starten des XWindows (startx) mit dem Kommando fwconfig gestartet.

Die allgemein Syntax ist also so:
fwBefehl cmd=Unterbefehl
Meist werden die möglichen Unterbefehle beim Aufruf des Kommandos ohne Argumente angezeigt. Es gibt eine Reihe weiterer Unterbefehl-Gruppen, der cmd Aufruf ist aber immer nötig.

Alle auf der Firewall definierten Adapter anzeigen:
root@FW:/usr # fwadapter cmd=list

Alle Netzwerk Objekte anzeigen:
root@FW:/usr # fwnwobj cmd=list format=raw
Hier wird das Format der Ausgabe geändert. Das gibt teilweise erhebliche umfassendere Informationen. Oft ist z.B. format=long sehr gut.

Wie oben erklärt bestehen Verbindungen aus Services, die wiederum aus Rules bestehen.

Alle Verbindungen sieht man:
root@FW:/usr # fwconns cmd=list format=raw
Das sieht dann so aus:

            
503|Permit all||1|1|25||0|0|before
513|Deny ALL BROADCASTS|Deny all Broadcasts on/over Interfaces|520|521|509||1|0|before

Die einzelnen Felder erklären sich mit dem Format long: Da häufig gleiche Zahlen als ID für völlig verschiedene Dinge benutzt werden (Connections, Services, Rules...) erfordert es große Aufmerksamkeit, eine Verbindung ohne GUI ableiten zu wollen.

 
root@FW:/usr # fwconns cmd=list format=long|more                                                                                           
               id = 503
             name = Permit all
             desc = 
           source = 1
      destination = 1
      servicelist = 25
        sockslist = 
          include = 0
        frequency = 0
          dynamic = before

               id = 513
             name = Deny ALL BROADCASTS
             desc = Deny all Broadcasts on/over Interfaces
           source = 520
      destination = 521
      servicelist = 509
        sockslist = 
          include = 1
        frequency = 0
          dynamic = before

Mit dem Kommando fwservices werden alle definierten Services angezeigt. Für jeden Service sind die enthaltenen Regeln aufgeführt. Dabei wird die Flussrichtung des Paketes angegeben. Dies erfolgt mit den Buchstaben f und b; Das f deutet die Richtung von Links nach Rechts an, während das b Pakete in der Richtung von Rechts nach Links ausweist. Die etwas eigenwillige Richtungsangabe bezieht sich dabei auf die betrachtete Regel! In der GUI (Ordner Service) sind das die Pfeile, und mit dem Schalter Flow kann man die Richtung ändern.

 
root@FW:/usr # fwservice cmd=list format=raw                             
13|FTP out 1/2|Permit FTP outbound secnet to fw|58/f,20/b,51/b,40/f,79/f,45/b||||||||
14|FTP out 2/2|Permit FTP outbound fw to non-secnet|56/f,16/b,48/b,39/f,77/f,42/b||||||||

Mit der Format-Option long erklärt sich wieder einiges:

 
              id = 13
             name = FTP out 1/2
             desc = Permit FTP outbound secnet to fw
         rulelist = 58/f,20/b,51/b,40/f,79/f,45/b
              log = 
         fragment = 
           tunnel = 
             time = 
            month = 
              day = 
          weekday = 
       timefilter = 

Diese Information ist zusätzlich in Files abgelegt, die wie das Kommando heissen (fwbefehl.cfg) und in /etc/security liegen. Teilweise sieht die Information dann etwas anders aus:

 
13|FTP out 1/2|Permit FTP outbound secnet to fw|n||||58;i 20;o 51;o 40;i 79;i 45 ;o|

Hier wird mit i und o, also inbound/outbound gearbeitet. Inbound/Outbound ist immer bezogen auf die Firewall bzw. den Adapter. Inbound ist also immer in die Firewall hinein, Outbound immer heraus, und zwar über das spezifizierte Interface.

Die im obigen Kommando referenzierten Regeln zeigt das Kommando fwfrule. Wie erwähnt ist eine Regel an keine Netzwerk-Objekte gebunden.

 
root@FW:/usr # fwfrule cmd=list format=long |more
               id = 57
             type = permit
             name = FTP Control 2/2
             desc = TCP out port 21 non-secure
         protocol = tcp
        srcopcode = gt
          srcport = 1023
       destopcode = eq
         destport = 21
        interface = nonsecure
    interfacelist = 
          routing = route
        direction = outbound
              log = no
           tunnel = 
         fragment = yes

               id = 18
             type = permit
             name = FTP Control Ack 1/2
             desc = TCP/ACK in port 21 non-secure
         protocol = tcp/ack
        srcopcode = eq
          srcport = 21
       destopcode = gt
         destport = 1023
        interface = nonsecure
    interfacelist = 
          routing = route
        direction = inbound
              log = no
           tunnel = 
         fragment = yes

Hilfreich und halbwegs übersichtlich ist die Ausgabe im Format raw:

 
18|permit|FTP Control Ack 1/2|TCP/ACK in port 21 non-secure|tcp/ack|eq|21|gt|1023|nonsecure||route|inbound|no||yes
21|permit|FTP Control Ack 2/2|TCP/ACK out port 21 secure|tcp/ack|eq|21|gt|1023|secure||route|outbound|no||yes
37|permit|FTP Data Ack in 20|TCP/ACK in port 20 secure|tcp/ack|gt|1023|eq|20|secure||route|inbound|no||yes
46|permit|FTP Data Ack out 1023+|TCP/ACK out port 1023+ secure|tcp/ack|gt|1023|gt|1023|secure||route|outbound|no||yes

Diese Information ist zusätzlich in der Datei /etc/security/fwrules.cfg hinterlegt. Und sieht dort natürlich ein bischen anders aus.

 
18|FTP Control Ack 1/2|TCP/ACK in port 21 non-secure|permit|tcp/ack|eq|21|gt|1023|non-secure|route|inbound|l=n|f=y||
21|FTP Control Ack 2/2|TCP/ACK out port 21 secure|permit|tcp/ack|eq|21|gt|1023|secure|route|outbound|l=n|f=y||
37|FTP Data Ack in 20|TCP/ACK in port 20 secure|permit|tcp/ack|gt|1023|eq|20|secure|route|inbound|l=n|f=y||

Aus den oben Konfigurierten Verbindungen, Services und Regeln werden während der Aktivierung des Regelwerkes (Kommando fwupdate) die eigentlichen Filter erzeugt. Diese werden nicht abgespeichert und sind nur im Memory vorhanden. Die aktuellen Filter können sich von den eigentlich definierten unterscheiden (durch Überschneidungen). Sichtbar werden sie mit dem Befehl fwfilter.

 
0|10|permit|0.0.0.0|0.0.0.0|172.16.1.1|255.255.255.255|icmp|eq|3|any|0|both|both|outbound|0|n|y|
0|11|permit|0.0.0.0|0.0.0.0|17.6.21.67|255.255.255.255|icmp|eq|3|any|0|both|both|outbound|1|n|y|
0|12|permit|0.0.0.0|0.0.0.0|17.6.21.67|255.255.255.255|icmp|eq|3|any|0|both|both|inbound|0|n|y|
513|2|deny|10.0.0.0|255.0.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0|non-secure|both|both|0|y|y|
513|2|deny|172.16.0.0|255.240.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0|non-secure|both|both|0|y|y|
513|2|deny|172.168.0.0|255.255.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0|non-secure|both|both|0|y|y|
0|1|deny|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0||both|both|0|n|y|

Die Felder können folgende Werte annehmen:
Proto=tcp udp ah esp ipip ospf icmp tcp/ack all
Quell-Port-Qualifier=all equal not equal greater than ....
IF-Setting= both secure non-secure specific
Routing=both local route
Direction=both inbound outbound
Frag-control=headers yes no only
Log-control=yes no

 
#Service|#Regel in Service|Action|Quell-IP|Quell-Netmask|Ziel-IP|Ziel-Netmask|Proto|Quell-Port-Qualifier|Quell-Port|Ziel-Port-Qualifier|If-Setting|Routing|Direction|Tunnel-ID|Log-control|Frag-control|
509|2|deny|0.0.0.0|0.0.0.255|0.0.0.0|0.0.0.255|udp|any|0|any|0|both|both|both|0|n|h|

Jeder Service wird auf die definierten Interface abgebildet:

 
39|2|permit|172.16.1.1|255.255.255.255|94.25.43.65|255.255.255.255|ah|any|0|any|0|non-secure|local|both|0|n|y|
39|3|permit|94.25.43.65|255.255.255.255|172.16.1.1|255.255.255.255|ah|any|0|any|0|non-secure|local|both|0|n|y|
39|4|permit|172.16.1.1|255.255.255.255|94.25.43.65|255.255.255.255|esp|any|0|any|0|non-secure|local|both|0|n|y|
39|5|permit|94.25.43.65|255.255.255.255|172.16.1.1|255.255.255.255|esp|any|0|any|0|non-secure|local|both|0|n|y|

Während alle vorherigen Kommandos alle definierten Verbindungen, Services, Regeln etc. anzeigen, gibt das fwfilter-Kommando die tatsächlich benutzten Filterregeln an. Das geschieht dabei auch genau in der Reihenfolge, wie die Filter ausgewertet werden. Diese Ausgabe ist also das wirkliche und aktive Regelwerk der Firewall.

Praktische Kommandos

Die Firewall sieht die Möglichkeit vor, eine Security Policy fest vorzugeben. Die nötigen Regeln werden dann automatisch erzeugt. Auf der GUI findet man das im Ordner System. Wichtig sind die Policies zum Testen des IP-Routing und zum Schließen des Secure-Interfaces im Notfall.

Die Änderung der Policy kann natürlich auch auf der Kommandozeile eingesetzt werden. Die aktuelle Policy ermittelt man so:

 
# fwconns cmd=list name=lblSecurityPolicy
               id = 501
             name = lblSecurityPolicy
             desc = Security Policy for this Firewall
           source = 1
      destination = 1
      servicelist = 23,34,
        sockslist = 
          include = 1
        frequency = 0
          dynamic = before

Zur Realisierung der gewünschten Policy stehen verschiedene Services zur Verfügung:

Diese Services platzieren neue Regeln. Im Fall von DNS sind das:

 
20|2|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|udp|gt|1023|eq|53|both|local|both|0|n|y|
20|3|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|udp|eq|53|gt|1023|both|local|both|0|n|y|
20|4|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|udp|eq|53|eq|53|both|local|both|0|n|y|
20|5|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|tcp|eq|53|eq|53|both|local|both|0|n|y|
Im Fall der Broadcasts und der SOCKS Connection sind es folgende Regeln:
  
23|2|deny|0.0.0.0|0.0.0.0|0.0.0.255|0.0.0.255|udp|any|0|any|0|non-secure|both|both|0|n|h|
34|2|deny|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|tcp|any|0|eq|1080|non-secure|local|inbound|0|y|y|
Die Panikabschaltung wird durch ein "Deny All" auf dem sicheren Interface erreicht:
 
26|2|deny|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0|secure|both|both|0|y|y|
Und die IP-Routing Tests führen folgende Regel temporär ein:
 
48|2|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0|both|both|both|0|y|y|

Zwei weitere Regeln sind auch immer eingerichtet. Das ist einmal die Anti-Spoofing Regel, die verhindert, daß Pakete, deren Source IP auf IP-Adressen aus dem sicheren Bereich geändert wurden, aber von Aussen kommen (also auf dem Unsicheren Adapter ankommen).

 
24|2|deny|172.16.1.0|255.255.255.0|0.0.0.0|0.0.0.0|all|any|0|any|0|non-secure|both|inbound|0|y|h|
Die letzte Regel ist immer die "Alles ist Verboten" Regel - hier kommt ein unerwünschtes Paket am Ende an. Mit Hilfe dieser Regel kann man im Log nach den Paketen suchen, die eigentlich durchgehen sollen...
 
0|1|deny|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|all|any|0|any|0||both|both|0|y|y|

Von der Kommandozeile aus ändert man die Policy mit folgendem Befehl:
fwconns cmd=change name=lblSecurityPolicy servicelist=23,34
Es müssen natürlich die gewünschten Services gewählt werden... Außerdem ist es unbedingt erforderlich, die Regel dann zu aktivieren. In der GUI geschieht das automatisch, auf der Kommandozeile muß es von Hand erledigt werden.
fwconns cmd=activate name=lblSecurityPolicy
Lustig ist dabei, das die GUI die Kommadozeilen-Änderung noch vor der Aktivierung richtig anzeigt....

Hier noch ein paar Beispiele zum Einrichten und Ändern von Regeln, Services und Connections. Das sind alles praktische Dinge zum Skripten, z.B. als Notfall-Maßnahme für die Wiederherstellung der Firewall.

fwfrule cmd=add name=L1 desc=Orm type=deny protocol=tcp srcopcode=gt srcport=1023 destopcode=eq destport=10000 interface=secure routing=route log=no direction=inbound
fwconns cmd=create dynamic=before name=Last600 desc="3 Stufe last" source=509 destination=1 servicelist=505
fwconns cmd=deactivate id=502
fwconns cmd=change id=502 source=510
fwfrule cmd=change name=Lxxx direction=outbound

Beim Einrichten von Regeln wird über den Schalter dynamic mitgeteilt, wo die Regel in der Hierachie stehen soll. Die höchste Priorität haben Regeln im Upper Layer, gefolgt von denen im Dynamic Layer. Regeln im Lower Layer werden von den übergeordneten Ebenen überspielt - die Regeln werden on dieser Reihenfolge abgearbeitet.

Sind auf der Maschine weitere Filter-Regeln über den "normalen" AIX IPSec Mechanismus eingerichtet, so werden diese zwar angezeigt, es ist aber nicht möglich, sie zu bearbeiten.

Ein sehr wichtiger Punkt ist das richtige Anordnen der erstellen Verbindungen. Das Kommando fwconns stellt dazu Möglichkeiten bereit. Einfacher ist das über die GUI zu machen. Dazu wird die zu bewegende Verbindung markiert, dann wird die STRG Taste während des markierens der Verbindung, hinter der die erste Verbindung eingefügt werden soll, gedrückt. Der Button "Move" leuchtet dann auf, und nach Anklicken wandert die Verbindung tatsächlich.

Es ist auch möglich, Verbindungen mit den SHIFT und STRG Tasten zusammenzufassen.

Die vom Administrator generierten Services und Regeln haben übrignes ein blaues Icon.

Mit dem Kommando fwfilter wird das Regelwerk an- und abgeschaltet. Nach Änderungen an den Regeln wird das Regelwerk mit dem Befehl fwfilter cmd=update neu generiert. Ein normales "Ausschalten" der Firewall geschieht mit dem Befehl fwfilter cmd=shutdown. In diesem Fall wird das Regelwerk ganz abgeschaltet.

Die Firewall verfügt über einen Checker, der sich die Checksummen bzw. Größen aller auf der Firewall installierten Files merkt. Per Standard ist es so eingerichtet, daß in regelmäßigen Abständen ein Abgleich gegen die Datenbank durchgeführt wird und eventuelle Unterschiede gemeldet werden. Das Kommando heißt fwfschk und besitzt Schalter zum Erstellen, Updaten und Anzeigen des Logs.

Einrichten von NAT (Network Adress Translation)

Die Network Adress Translation ermöglicht es, auf der Firewall eine bekannte IP-Adresse zu definieren (die registrierte NAT IP) und diese mit einer oder mehrer Adressen bzw. Ports auf der sicheren Seite zu verknüpfen. Die Firewall ändert also die Pakete entsprechend, für die Hosts auf beiden Seiten der Firewall ist dieser Vorgang transparent. Der einschlägige RFC ist rfc3022.

Man kann auf diese Art einmal vermeiden, den eigenen Hosts offizielle Adressen zu geben; zugleich versteckt man das eigene Netz vor eventuellen Angreifern. Die Existenz einer Einrichtung, die ein NAT ausführt, und die Anzahl der dahinter stehenden Hosts ist nur mit hohem Analyseaufwand festzustellen (Auswertung des TTL Feldes und der IP ID).

Das eigentliche "natten", also das Umschreiben des IP-Paketes, erfolgt dabei immer vor dem Filtern mit dem Regelwerk der Firewall! Im Regelwerk der Firewall tauchen also keine registrierten NAT-Adressen auf.

Verfolgt man den Weg des Paketes, so kommt das Paket mit der internen Adresse auf der sicheren Seite der FW an und wird durch das Regelwerk gefiltert. Danach schreibt NAT das Paket entsprechend der Zuordnung um und das Paket wird gesendet. Hereinkommende Pakete werden zuerst von NAT umgeschrieben, und dann durch das Regelwerk gefiltert. Das Regelwerk wird also immer nur auf der sicheren Seite angewendet.

 
.          Secure _______________        Unsecure
.                |            ___|
.    Inbound     |           | F |       Outbound
.    ----------> | FW -   -> | I | --> NAT --> IPSec --->
.    <---------- | TCP -     | L |
.    Outbound    | Stack     | T |
.                |        <- | E | <-- NAT <-- IPSec <---
.                |           | R |
.                |___________|___|
.                            

Per GUI oder Kommandozeile wird die gewünschte Zuordnung erstellt. Die eingestellten Adressen sind in der Datei /etc/security/fwnat.cfg abgelegt und natürlich per GUI (Ordner NAT) sichtbar. Mit dem Befehl fwnat ist die Ausgabe der vorhandenen NATtings, das Stoppen und Prüfen des Dienstes sowie das Einrichten und Ändern möglich.

 
# NATMIG 1
# This file is generated by Firewall configuration.
# DO NOT EDIT THIS FILE MANUALLY.
#
MAP 172.16.1.33 172.16.22.3

Die Firewall muß nach aussen die registrierte NAT Adresse vertreten, also ARP-Anfragen auf Diese beantworten. Das geschieht durch setzen von permanenten ARP-Einträgen. Dazu wird die MAC Adresse des Unsicheren Adapters ermittelt (netstat -v):

 
-------------------------------------------------------------
ETHERNET STATISTICS (ent0) :
Device Type: IBM ISA Ethernet adapter
Hardware Address: 10:00:5a:14:54:9c
Der ARP-Eintrag wird folgendermaßen gesetzt: arp -s ether 172.16.22.3 10:00:5a:14:54:9c pub Wichtig ist der Schalter pub; damit
bleibt der Eintrag bestehen und wird bekanntgegeben. Die ARP-Table sieht dann so aus:
 
# arp -an
  ? (172.16.22.2) at 8:0:5a:ba:da:a6 [ethernet]
  ? (172.16.22.3) at 10:0:5a:14:54:9c [ethernet] permanent published
  ? (172.16.1.33) at 8:0:5a:93:bc:ea [ethernet]
Damit diese Modifikation einen Reboot übersteht, sind die Aufrufe in die /etc/rc.local oder die /etc/rc.tcpip einzufügen.

Es gibt verschiedene Typen des NAT. Der Typ map ist eine feste, direkte Zuordnung zwischen zwei IP-Adressen (Hosts). Soll eine registrierte NAT Adresse von vielen Hosts zugleich benutzt werden können, so wird der Typ Many-to-One benutzt. Dabei werden die IP und Portnummer des sicheren Hosts dynamisch über eine Portnummer auf die registrierte NAT IP gemappt. Die Anzahl der möglichen Hosts ist also etwa die der verfügbaren Ports (65536 - 1023). Der Bereich der Hosts (IP-Adresse) kann eingeschränkt werden - das ist der Typ Translate Secure Addresses. Der umgekehrte Fall, das von der allgemeinen Umsetzung bestimmte Adressen ausgeschloßen werden, ist der Typ Exclude Secure Addresses.

Einrichten eines Tunnels

Ein Tunnel kann zwischen zwei Firewalls oder einer Firewall und einem IPSEC-fähigen Tunnelende eingerichtet werden (das ist zumindest die Theorie, man sollte es immer zuerst unverbindlich probieren).

Generell wird der Tunnel auf der einen Seite eingerichtet, dann Exportiert, auf die andere Seite übertragen und dort Importiert. Der entsprechende Befehl ist fwtunnl.

fwtunnl cmd=export directory=/tmp tunnel=6
fwtunnl cmd=import directory=/tmp tunnel=6

Führt man den Export durch, so wird im angegebenen Verzeichnis eine Datei ipsec_tun_manu.exp erstellt. Hier sind die Tunnel-Definitionen gespeichert:

 
root@fw:/tmp # cat ipsec_tun_manu.exp
#--------------------------------------
4       # IPv4 Tunnel Adressen
192.168.1.1
172.16.1.1
6       # Nummer des Tunnels
123406  # SPI der tunnel Enden
123406
338204
338204
DES_CBC #Verschlüsselung, Keylänge in Byte (8)
8
0xCD07B6B280E71BD1 # Der Key dazu, je Seite
DES_CBC
8
0x5AA3504F272B7487
HMAC_MD5 # Verschlüsselung für Checksummen 
16       # Keylänge in Byte (16)
0x8FBF9855FF1A88474EEAD4D95C688580
HMAC_MD5
16
0xA574EBCCA1C0A8F1C596A2C49447D2F2
0      # Da habe ich etwas nicht ausgewählt
0
tunnel # Art der Verbindung, Tunnel
tunnel
eaea   # Modus, ESP und AH an beiden Enden
0
1
NONE
0

NONE
0

0
-
-
MailTunnel # Name des Tunnels
0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0

Diese Datei wird auf die andere Firewall übertragen und dort importiert. Dabei wird das File eingelesen, die IP Adressen und die Schlüssel werden entsprechend gedreht.

Auf der anderen Firewall ist nun das entgegengesetzte Ende des Tunnel sichtbar. Exportiert man diesen Tunnel ergibt sich folgende Definition:

 
#--------------------------------------
4
172.16.1.1
192.168.1.1
7
338204
338204
123406
123406
DES_CBC
8
0x5AA3504F272B7487
DES_CBC
8
0xCD07B6B280E71BD1
HMAC_MD5
16
0xA574EBCCA1C0A8F1C596A2C49447D2F2
HMAC_MD5
16
0x8FBF9855FF1A88474EEAD4D95C688580
0
0
tunnel
tunnel
eaea
0
1
NONE
0

NONE
0

0
-
-
MailTunnel
0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0

Es ist leicht zu sehen, das alle Parameter (IP Adressen, Keys, SPI) umgedreht sind. Die Tunnel ID ist eine andere, wahrscheinlich war die 6 nicht mehr frei. Die Tunnel ID ist für die Zuordnung der Services zu einem Tunnel wichtig.

Dieser Tunnel stellt sich in der Ausgabe des Kommandos fwfilter wie folgt dar:

 
root@FW2:/ # fwfilter cmd=list |grep 5555
527|2|permit|192.168.1.1|255.255.255.255|10.10.30.0|255.255.255.0|all|eq|5555|any|0|secure|both|outbound|0|n|y|
527|3|permit|10.10.30.0|255.255.255.0|192.168.1.1|255.255.255.255|all|any|0|eq|5555|secure|both|inbound|0|n|y|
528|2|permit|192.168.1.1|255.255.255.255|10.10.30.0|255.255.255.0|all|eq|5555|any|0|non-secure|both|inbound|7|n|y|
528|3|permit|10.10.30.0|255.255.255.0|192.168.1.1|255.255.255.255|all|any|0|eq|5555|non-secure|both|outbound|7|n|y|

Den Tunnel beschreiben vier Regeln. Die ersten beiden Regeln erlauben den Verkehr der Pakete über das sichere Interface der Firewall in beide Richtungen. Die letzten beiden Regeln erlauben den Verkehr über das nicht-sichere Interface, wieder in beide Richtungen. Diese Regeln sind dem Tunnel 7 fest zugeordnet, aller Verkehr wird also verschlüsselt und über den Tunnel geleitet.

 
root@FW1:/ # fwfilter cmd=list |grep 5555
529|2|permit|172.16.1.1|255.255.255.255|10.10.30.0|255.255.255.0|all|eq|5555|any|0|secure|both|outbound|0|n|y|
529|3|permit|10.10.30.0|255.255.255.0|172.16.1.1|255.255.255.255|all|any|0|eq|5555|secure|both|inbound|0|n|y|
530|2|permit|172.16.1.1|255.255.255.255|10.10.30.0|255.255.255.0|all|eq|5555|any|0|non-secure|both|inbound|6|n|y|
530|3|permit|10.10.30.0|255.255.255.0|172.16.1.1|255.255.255.255|all|any|0|eq|5555|non-secure|both|outbound|6|n|y|

Start der Firewall

Gestartet wird die Firewall aus /etc/rc.tcpip. Es wird das volle Angebot gestartet, und man kann je nach Umgebung das eine oder andere kommentieren (z.B. SOCKS, named oder das Secure Mail Gateway). Folgende Dienste werden per Default gestartet:

   
rc.tcpip:/usr/sbin/fwcfgnat -ui
rc.tcpip:/usr/sbin/fwtimernat -b
rc.tcpip:/usr/bin/fwaudio cmd=activate &
rc.tcpip:/usr/sbin/fwSocks5 -w &
rc.tcpip:start /usr/sbin/named "$src_running" "-b /etc/fwnamed.boot"
rc.tcpip:/usr/sbin/smtpsb &
rc.tcpip:/usr/sbin/fwl -s 
rc.tcpip:/usr/sbin/fwhscnt -s  
rc.tcpip:/usr/sbin/fwlogmond  

Wichtig ist dabei das fwl-Kommando. Damit wird die Kernel Extension initialisiert. Zusammen mit dem fwhscnt-Kommando werden dabei verschiedene Parameter bezüglich der Zahl der Sessions und der Lizenz festgelegt. Das scheint heute jedoch eher unerheblich zu sein - trotzdem ist das Kommando wichtig.

Man kann es auch so aufrufen und bekommt folgende Information:

 
root@FW:/ # fwl -s
Concurrent Session Tracking Setting:
csstat=n
tcp=-1      # Limit der möglichen TCP Sessions (-1 == unendlich)
udp=-1      # Limit der möglichen UDP Sessions
tcptimo=-1  # Timeout der Session für TCP (unendlich)
udptimo=5   # Timeout der Session für UDP (5 sec)
gp=y        # Es ist ein Grace Wert eingeschaltet
l=n         # Bei Überschreitungen wird nicht geloggt

root@FW:/ # fwl -g                                                  
Concurrent Session Information: 
csstat=n
tcp=0
udp=0
tcpcount=0  # Anzahl der aktuellen Sessions, wenn Limit gesetzt.
udpcount=0
tcpto=0
udpto=0
gp=n
l=n

Beide Kommando legen die Information auch in einem File ab:

 
root@FW:/etc/security # cat fwl.cfg
tcp=-1 udp=-1 gp=y l=n tcpto=-1 udpto=5 csstat=n 

root@FW:/etc/security # cat fwhscnt.cfg
fwtkH7ve7tcjc

In der /etc/rc.net wird die eigentliche Kernel-Extension gestartet. Das geschieht direkt nach den beiden Aufrufen zur Konfiguration der Interfaces (/usr/lib/methods/defif und /usr/lib/methods/cfgif). Dabei wird folgender Aufruf abgesetzt:

 
# Start - IBM FW Additions ---------------------------------------- #FW#
{                                                                   #FW#
/usr/lpp/FW/fwext/fwkernel.config                                   #FW#
} >> $LOGFILE 2>&1                                                  #FW#
# End - IBM FW Additions ------------------------------------------ #FW#

In diesem File sind die Loader für die Firewall-NAT Kernel-Extension und der NAT-Devicetreiber definiert:

 
File fwkernel.config:
/usr/lpp/FW/fwext/loadfwkx /usr/lpp/FW/fwext/fwnatkx
/usr/lpp/FW/fwext/loadfwdd /usr/lpp/FW/fwext/fwnatdd ipsp_poif

Mit dem Kommando genkex (dazu muß bos.perf* installiert sein) kann man die Firewall Kernel-Extensions dann sehen:

 
Virtual Address              Size File
.....
         121ff90              560 /usr/lpp/FW/fwext/fwnatdd
         11f66e0            298a4 /usr/lpp/FW/fwext/fwnatkx
.....
         11d2b00            1f414 /usr/lib/drivers/filter4
         11c9520             95d0 /usr/lib/drivers/tunnel_if4
         11c0980             8b80 /usr/lib/drivers/ipsec_cap4
         11b9620             7350 /usr/lib/drivers/tunnel_cache4
         11b3200             6418 /usr/lib/drivers/crypto/des_mod
         11ac800             69f8 /usr/lib/drivers/crypto/cdmf_mod
         11ac378              478 /usr/lib/drivers/crypto/null_mod
         11aa540             1e30 /usr/lib/drivers/crypto/keyed_md5_mod
         11a8a00             1b38 /usr/lib/drivers/crypto/hmac_sha_mod
         11a6980             2070 /usr/lib/drivers/crypto/hmac_md5_mod
         11a14c0             54a0 /usr/lib/drivers/ipsec_utils

Nur die beiden fw* Extensions sind eigentlich Firewall Extensions. Der Rest gehört zu Ipsec. In rc.net werden dann noch Netzwerk-Parameter gesetzt, um das Routing anzuschalten und um das Listen Backlog zu begrenzen.

 
# Start - IBM FW Additions ------------------- #FW#
/usr/sbin/no -o ipforwarding=1 >>$LOGFILE 2>&1 #FW#
/usr/sbin/no -o somaxconn=1024 >>$LOGFILE 2>&1 #FW#
# End - IBM FW Additions --------------------- #FW#

Der Startup der Firewall wird natürlich auch in die Datei /tmp/rc.net.out geloggt. Das sieht dann so aus:

 
tcp_getattr_isno: criteria = uniquetype = 'if/EN/en/1500/10Mb' AND attribute = 'rfc1323'
......
tcp_getattr_isno: criteria = uniquetype = 'if/LO/lo/16896/10Mb' AND attribute = 'tcp_recvspace'
MAIN [loadfwkx.c:54]: input /usr/lpp/FW/fwext/fwnatkx 
18938736
device: /dev/ipsp_poif
MAIN [loadfwdd.c:64] input /usr/lpp/FW/fwext/fwnatdd ipsp_poif 
MAIN [loadfwdd.c:117] genmajor returned 41 
MAIN [loadfwdd.c:129] mknod worked, about to load device driver 
19006584
MAIN [loadfwdd.c:147] load device driver worked, about to config device driver 
inet0
tcp_getattr_isno: criteria = uniquetype = 'if/EN/en/1500/10Mb' AND attribute = 'rfc1323'
.......
tcp_getattr_isno: criteria = uniquetype = 'if/LO/lo/16896/10Mb' AND attribute = 'tcp_recvspace'
elguardia
0513-095 The request for subsystem refresh was completed successfully.
Command completed successfully.

Command completed successfully.

NAT configuration updated at 11:58:28 on Aug-21-2003.
Command completed successfully.

0513-059 The named Subsystem has been started. Subsystem PID is 4150.
Concurrent Session Tracking Setting:
csstat=n
tcp=-1
udp=-1
tcptimo=-1
udptimo=5
gp=y
l=n
IP Counter Setting:
ip=-1

Ein weiteres File findet sich in /etc/security, das beim Starten der Firewall ausgewertet wird und allgemeine Definitionen enthält: fwtdefn.conf. Hier wird definiert, wer Alerts per Mail bekommt, welche Thresholds gelten etc.

 
MAILTO root
AUTH_USER 10 5 N #(Created by setup wizard)
AUTH_HOST 10 5 N #(Created by setup wizard)
AUTH_TOTAL 20 5 N #(Created by setup wizard)
MSGTAG ICA1034i 1 1 N #(Created by setup wizard)
MSGTAG ICA9001w 1 1 N #(Created by setup wizard)
STARTONBOOT
MSGTAG ICA1036 5000 1 N #(Created by setup wizard)
MSGTAG ICA9070i 1 1 N #(Created by setup wizard)
MSGTAG ICA9071i 1 1 N #(Created by setup wizard)
MSGTAG ICA0005e 1 1 N #(Created by setup wizard)
MSGTAG ICA0009e 1 1 N #(Created by setup wizard)
MSGTAG ICA0012e 1 1 N #(Created by setup wizard)
MSGTAG ICA0013w 1 1 N #(Created by setup wizard)
......
MSGTAG ICA2157e 1 1 N #(Created by setup wizard)
MSGTAG ICA9003e 1 1 N #(Created by setup wizard)

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )