| orm@doc-tcpip.org | Erstellt: Mai 2003 - Letzte Modifikation: August 2003 |
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.
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:
20 Permit DNS
21 Permit DNS Zone Transfer
23 Deny Broadcast Messages to Nonsecure Interface
34 Deny socks to nonsecure Interface
26 Shutdown Service Interface (Notfall)
25 IP Routing testen (Alles erlaubt an erster Stelle)
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.
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:9cDer 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
# 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.
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|
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)
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL