orm@doc-tcpip.org

Erstellt: August 2003 - Letzte Modifikation: August 2003

[ Main | Local ]

NAT über eine Firewall mitgetraced

 IBM Secureway Firewall

Die Umgebung sieht so aus:

Das Regelwerk der Firewall wird um 4 Regeln erweitert, die eine Telnet-Verbindung vom Secure-Host zum Unsecure-Host (in dieser Richtung) erlauben: 

 
# fwfilter cmd=list
......
501|2|permit|172.16.1.33|255.255.255.255|172.16.22.2|255.255.255.255|tcp|gt|1023|eq|23|secure|route|inbound|0|y|y|
501|3|permit|172.16.1.33|255.255.255.255|172.16.22.2|255.255.255.255|tcp|gt|1023|eq|23|non-secure|route|outbound|0|y|y|
501|4|permit|172.16.22.2|255.255.255.255|172.16.1.33|255.255.255.255|tcp|eq|23|gt|1023|non-secure|route|inbound|0|y|y|
501|5|permit|172.16.22.2|255.255.255.255|172.16.1.33|255.255.255.255|tcp|eq|23|gt|1023|secure|route|outbound|0|y|y|
......
Wie man sieht, erscheint die externe Adresse, die registrierte NAT Adresse, nicht im Regelwerk. Kommt das Paket von aussen, so wird es zuerst genattet und dann gefiltert. Kommt das Paket von innen, so wird zuerst gefiltert, und dann genattet. Das Filtern erfolgt also immer auf der sicheren Seite, das NAT immer auf der unsicheren Seite.

Damit wäre die Umgebung richtig aufgesetzt. Für den Test wird vom Secure-Host ein Telnet auf den Unsecure-Host abgesetzt. Sobald die Login-Zeile erscheint, wird der Trace abgebrochen.

Das Starten des Traces sowie die Datensammlung werden mit folgenden Scripten durchgeführt:

Das Starten des Traces: 

 
#! /bin/ksh
tcpdump -Iien0 -w /tmp/en0.trc &
echo $! > /tmp/tcpdump_en0.pid
sleep 2
tcpdump -Iien1 -w /tmp/en1.trc &
echo $! > /tmp/tcpdump_en1.pid
sleep 2
trace -a -j 2df
sleep 2
echo "Alles gestartet..."

Die tcpdump-Instanzen und der Trace werden mit folgendem Skript gestoppt und gleich formatiert in ein anzugebendes File geschrieben. Nur das Firewall-Log muß von Hand gesichert werden. 

 
#! /bin/ksh
trcstop
sleep 2
kill $(cat /tmp/tcpdump_en0.pid)
kill $(cat /tmp/tcpdump_en1.pid)
sleep 2
echo "Unsecure IF en0" >> $1
tcpdump -envr en0.trc >> $1
echo "Secure IF en1" >> $1
tcpdump -envr en1.trc >> $1
trcrpt >> $1
echo "Alles gestoppt..."

Ausgewertet werden nur die ersten 6 Pakete des TCP-Handshakes. Die Verbindung ist dann im State ESTABLISHED und aus der Sicht der Firewall wiederholt sich dann alles nur noch.

Hier die 3 Pakete, die das sichere Interface en1 der Firewall passieren: 

 
12:19:56.760630656 8:0:5a:93:bc:ea 10:0:5a:ba:91:4c 0800 60: 172.16.1.33.42923 > 172.16.22.2.23: S 675900550:675900550(0) win 16384  (DF) [tos 0x10] (ttl 60, id 37078)
12:19:56.765837696 10:0:5a:ba:91:4c 8:0:5a:93:bc:ea 0800 60: 172.16.22.2.23 > 172.16.1.33.42923: S 1274513824:1274513824(0) ack 675900551 win 17520  (ttl 59, id 20986)
12:19:56.766609024 8:0:5a:93:bc:ea 10:0:5a:ba:91:4c 0800 60: 172.16.1.33.42923 > 172.16.22.2.23: . ack 1 win 17520 (DF) [tos 0x10] (ttl 60, id 37079)

Und die 3 Pakete, die das unsichere Interface der Firewall weitergibt: 

 
12:19:56.762438144 10:0:5a:14:54:9c 8:0:5a:ba:da:a6 0800 60: 172.16.22.3.42923 > 172.16.22.2.23: S 675900550:675900550(0) win 16384  (DF) [tos 0x10] (ttl 59, id 37078)
12:19:56.763904896 8:0:5a:ba:da:a6 10:0:5a:14:54:9c 0800 60: 172.16.22.2.23 > 172.16.22.3.42923: S 1274513824:1274513824(0) ack 675900551 win 17520  (ttl 60, id 20986)
12:19:56.768418176 10:0:5a:14:54:9c 8:0:5a:ba:da:a6 0800 60: 172.16.22.3.42923 > 172.16.22.2.23: . ack 1 win 17520 (DF) [tos 0x10] (ttl 59, id 37079)

Die Pakete werden jetzt der Reihe nach aufgeführt und zusammen mit dem entsprechenden Eintrag im Trace sowie im Firewall-Log korreliert. Das erste Paket ist ausführlich kommentiert. Weiter unter ist der Vollständigkeit halber der Vorlauf des Traces noch aufgeführt.

 
Secure Host ==== SYN ====> SecureIF FW UnsecureIF ==== SYN ====> Unsecure Host
Secure Host <== SYN/ACK == SecureIF FW UnsecureIF <== SYN/ACK == Unsecure Host
Secure Host ==== ACK ====> SecureIF FW UnsecureIF ==== ACK ====> Unsecure Host


 
12:19:56.760630656 8:0:5a:93:bc:ea 10:0:5a:ba:91:4c 0800 60: 172.16.1.33.42923 > 172.16.22.2.23: S 675900550:675900550(0) win 16384  (DF) [tos 0x10] (ttl 60, id 37078)
Das erste Paket (SYN) kommt am sicheren Adapter der Firewall an. Auf der IP-Ebene ist das Paket 60 Byte groß. Es werden die internen MAC-Adressen und die interne IP-Adresse benutzt. 

 
2DF   22.488205056    7818.884992                   IPSEC_FILTER_INFO fwnati_before: src=AC100121.42923 dst=AC101602.23 len=44 sum=16034
2DF   22.488368384       0.163328                   IPSEC_FILTER_INFO fwnati_after:  src=AC100121.42923 dst=AC101602.23 len=44 sum=16034 PERMIT
2DF   22.488461440       0.093056                   IPSEC_FILTER_INFO fltri4: Matched filter rule 1: Action is PERMIT

So sehen die Routinen der Firewall das erste Paket. Zuerst steht die Hook-ID (2DF), darauf folgt die absolut verflossene Zeit seit Tracestart in Sekunden, darauf die Differenz zum letzten Event in Millisekunden. Darauf der Name des Hooks (IPSEC_FILTER_INFO). Die protokollierende Routine ist fwnati_before, also das Paket ist inbound (in die Firewall hinein) und wird jetzt geprüft, ob ein NAT nötig ist. Es folgt die Quell-Adresse in Hex (AC.10.01.21 entspricht 172.16.1.33) und der Port Dezimal (Port 42923). Die Ziel-Adresse ist auch in Hex (AC.10.16.02 entspricht 172.16.22.2) und der Zielport ist 23, der Telnet-Port. Die Länge des Paketes wird mit 44 Byte angegeben - es ist also der IP-Header schon abgezogen. Da das Paket von der sicheren Seite kommt, hat die NAT Routine nichts zu tun, und 0.163320 msec später übergibt die NAT Ausgaberoutine (fwnati_after) das unveränderte Paket. Die nächste Routine (fltri4) ist die Filterroutine für Inbound IPv4 Pakete. Nach 0.093056 msec konnte für dieses Paket eine zutreffende Regel gefunden werden. Diese Regel besagt, das Paket zuzulassen (PERMIT). Die Information über diese Regel ist sehr gering. Man muß dazu das Firewall-Log auswerten: 

 
Aug 12 12:19:56 elguardia : 2003;5422: 2151;ICA1075i;1;504;501;1;p;i;172.16.1.1; 172.16.1.33;172.16.22.2;tcp;sp:;42923;dp:;23;r;s;n;0;44;

Bis zur Jahreszahl 2003 sind die Einträge vom Syslog generiert. Danach wird die PID des fwlog-Prozesses angegeben, gefolgt von der Message ID nummerisch und als ICA-Code (Priorität ist informational). Der Filtertyp ist 1, also das Upper Layer (das höchste, was die FW zu bieten hat). Danach folgt die Connection-ID (504) sowie die Service-ID (501, hier nur ein Service). Die Regel, die zur Entscheidung geführt hat, ist die erste dieses Service mit der ID 501. Daher die Angabe im Trace. Der Buchstabe p steht für PERMIT, der Buchstabe i für Inbound. Danach folgen die IP-Adressen der FW (also des Interfaces, auf das sich die Regel bezieht), des Senders und des Empfängers, gefolgt von Protokoll und Quell- bzw. Zielport. Die weiteren Angaben bezeichnen die Art des Routing (routed oder loacl), das Interface (secure oder non-secure), ob das Paket fragmentiert ist oder nicht (yes oder no), die ID des Tunnels und schließlich die Länge des Paketes. Das Logging fuktioniert natürlich nur, wenn es für die Regel angeschaltet worden ist.

Das nächste Paket ist das Paket, was die Firewall nach den Prüfungen auf der unsicheren Seite auf das Netz gibt. Es ist also ein Paket, was aus der Firewall heraus geschickt wird - und schauen daher anders aus. Außerdem schlägt hier das NAT zu. 

 
2DF   22.488846592       0.385152                   IPSEC_FILTER_INFO fltro4: (en0) sad=AC100121 dad=AC101602 pr=6
2DF   22.488898304       0.051712                   IPSEC_FILTER_INFO fltro4: ak/rs=0 sprt=42923 dprt=23 loc=0 frg=0 frghdr=0 len=44
2DF   22.488982784       0.084480                   IPSEC_FILTER_INFO fltro4: Matched rule 2, action is PERMIT
2DF   22.489145600       0.162816                   IPSEC_FILTER_INFO fwnato_before: src=AC100121.42923 dst=AC101602.23 len=44 sum=16034
2DF   22.489421184       0.275584                   IPSEC_FILTER_INFO fwnato_after:  src=AC101603.42923 dst=AC101602.23 len=44 sum=10688 PERMIT

Die Routine heißt jetzt fltro4, also soetwas wie "Filter outbound für IPv4". Es wird das Interface, über welches das Paket gesendet werden wird, angegeben: en0. Die Quell- und Ziel-Adresse des Paketes wird in Hex angeben (sad und dad, 172.16.1.33 und 172.16.22.2). XXX pr?? XXX

Dieselbe Routine setzt danach noch ein paar Flags für das ausgehende Paket: Es ist weder das ACK noch das RST Bit gesetzt (ak/rs=0), die beiden Ports, es ist kein lokales Paket (loc=0), kein Fragment und somit kein Fragment-Header (frg und frghdr gleich 0). Die Länge ist 44 Byte. Dann schreibt der Filter heraus, daß das Paket aufgrund der Regel 2 akzeptiert ist. Da es ein Outbound-Paket ist, erfolgt der NAT-Check nach dem Durchlauf der Filterregeln. Die beiden Routinen sind fwnato_before und fwnato_after. Betrachtet man die Quell-Adresse (AC100121, also 172.16.1.33) so sieht man, das diese jetzt per NAT auf die registrierte NAT Adresse umgeschrieben wird (AC101603, also 172.16.22.3). An der Länge ändert sich nichts, nur die Checksumme wird angepasst. 

 
12:19:56.762438144 10:0:5a:14:54:9c 8:0:5a:ba:da:a6 0800 60: 172.16.22.3.42923 > 172.16.22.2.23: S 675900550:675900550(0) win 16384  (DF) [tos 0x10] (ttl 59, id 37078)

Im Tcpdump sieht man dann tatsächlich das durch NAT angepasste Paket auf das Netz gehen. 

 
Aug 12 12:19:56 elguardia : 2003;5422: 2151;ICA1075i;1;504;501;2;p;o;172.16.22.1
;172.16.1.33;172.16.22.2;tcp;sp:;42923;dp:;23;r;n;n;0;44;

Das Firewall-Log informiert wieder über die Connection und den Service, diesmal ist es die Rule 2, die über das Schicksal des Paketes bestimmt. Der vierte Wert von Hinten gibt das Interface an, der Buchstabe n steht für das non-Secure Interface.

Jetzt kommt das erste Paket von der unsicheren Seite in die Firewall hinein. Es handelt sich um den SYN/ACK dieses Handshakes. 

 
12:19:56.763904896 8:0:5a:ba:da:a6 10:0:5a:14:54:9c 0800 60: 172.16.22.2.23 > 172.16.22.3.42923: S 1274513824:1274513824(0) ack 675900551 win 17520  (ttl 60, id 20986)

Der Durchlauf durch die Regeln findet immer auf der sicheren Seite statt, das Paket läuft also zuerst durch die NAT-Filter (fwnati). 

 
2DF   22.491500416       2.079232                   IPSEC_FILTER_INFO fwnati_before: src=AC101602.23 dst=AC101603.42923 len=44 sum=43180
2DF   22.491785728       0.285312                   IPSEC_FILTER_INFO fwnati_after:  src=AC101602.23 dst=AC100121.42923 len=44 sum=48526 PERMIT
2DF   22.491882496       0.096768                   IPSEC_FILTER_INFO fltri4: Matched filter rule 3: Action is PERMIT

Wie zu sehen ist, wird die Ziel-Adresse durch das NAT entsprechend der Setzung abgeändert (von 172.16.22.3/AC101603 auf 172.16.1.33/AC100121), jeweils durch die Routinen fwnati_before und fwnati_after. Danach wird beim Durchgang durch das Regelwerk die Regel 3 gefunden und angewendet. 

 
Aug 12 12:19:57 elguardia : 2003;5422: 2151;ICA1075i;1;504;501;3;p;i;172.16.22.1
;172.16.22.2;172.16.1.33;tcp;sp:;23;dp:;42923;r;n;n;0;44;

Die Information bezüglich der Regeln kommt wieder aus dem Firewall-Log. Das Paket ist über das non-Secure Interface hereingekommen (n an vierter Stelle von Hinten).

Das eingetroffene Paket wird jetzt von der Firewall nach Intern weitergeleitet, also über das sichere Interface (en1) herausgeschickt. Also wird zuerst das Regelwerk abgearbeitet, und dann nach einem eventuellen NAT gecheckt. 

 
2DF   22.492318336       0.435840                   IPSEC_FILTER_INFO fltro4: (en1) sad=AC101602 dad=AC100121 pr=6
2DF   22.492373376       0.055040                   IPSEC_FILTER_INFO fltro4: ak/rs=1 sprt=23 dprt=42923 loc=0 frg=0 frghdr=0 len=44
2DF   22.492466816       0.093440                   IPSEC_FILTER_INFO fltro4: Matched rule 4, action is PERMIT
2DF   22.492624640       0.157824                   IPSEC_FILTER_INFO fwnato_before: src=AC101602.23 dst=AC100121.42923 len=44 sum=48526
2DF   22.492771584       0.146944                   IPSEC_FILTER_INFO fwnato_after:  src=AC101602.23 dst=AC100121.42923 len=44 sum=48526 PERMIT

Da dieses Paket das ACK Flag trägt, ist auch das entsprechende Feld gesetzt (ak/rs=1). Die Regel ist die Regel Nummer 4 im entsprechenden Service. Ein NAT ist nicht vorhanden. 

 
12:19:56.765837696 10:0:5a:ba:91:4c 8:0:5a:93:bc:ea 0800 60: 172.16.22.2.23 > 172.16.1.33.42923: S 1274513824:1274513824(0) ack 675900551 win 17520  (ttl 59, id 20986)

Ensprechend sieht das Paket aus, das nun auf das sichere Netz geht. 

  
Aug 12 12:19:57 elguardia : 2003;5422: 2151;ICA1075i;1;504;501;4;p;o;172.16.1.1;
172.16.22.2;172.16.1.33;tcp;sp:;23;dp:;42923;r;s;n;0;44;

Im Log ist der sichere Adapter als Ausgangs-Adapter angegeben.

Der TCP-Handshake wird durch das Beantworten des Server-seitigen SYN/ACK mit einem ACK beendet. Hier das Client-seitige ACK als tcpdump-Ausgabe: 

 
12:19:56.766609024 8:0:5a:93:bc:ea 10:0:5a:ba:91:4c 0800 60: 172.16.1.33.42923 > 172.16.22.2.23: . ack 1 win 17520 (DF) [tos 0x10] (ttl 60, id 37079)

Es ist ein eingehendes Paket, also wird zuerst nach einem eventuellen NAT geschaut (Routine fwnati). Da sich nichts findet - schließlich kommen wir von der sicheren Seite - wird das Paket durch die Filterregeln geschoben. 

 
2DF   22.494162048       1.390464                   IPSEC_FILTER_INFO fwnati_before: src=AC100121.42923 dst=AC101602.23 len=40 sum=16037
2DF   22.494319872       0.157824                   IPSEC_FILTER_INFO fwnati_after:  src=AC100121.42923 dst=AC101602.23 len=40 sum=16037 PERMIT
2DF   22.494408960       0.089088                   IPSEC_FILTER_INFO fltri4: Matched filter rule 1: Action is PERMIT

Die zutreffende Regel ist wieder die Regel 1 im entsprechenden Service (das Paket ist von den Regeln her analog zu Paket 1). 

 
Aug 12 12:19:57 elguardia : 2003;5422: 2151;ICA1075i;1;504;501;1;p;i;172.16.1.1;
172.16.1.33;172.16.22.2;tcp;sp:;42923;dp:;23;r;s;n;0;40;

Das Firewall-Log verrät wieder den Service und die Connection, aus der die angewandte Regel stammt. Das Interface ist das sichere Interface, und der Logeintrag beschreibt ein Inbound-Paket.

Dieses Paket wird jetzt weitergeleitet und somit über das Interface en0 auf die unsichere Seite geleitet. Das entsprechende Bit für ein ACK Flag ist gesetzt. Die angewandte Regel ist Regel 2, analog zum zweiten Paket dieses Handshake. 

 
2DF   22.494837120       0.428160                   IPSEC_FILTER_INFO fltro4: (en0) sad=AC100121 dad=AC101602 pr=6
2DF   22.494891776       0.054656                   IPSEC_FILTER_INFO fltro4: ak/rs=1 sprt=42923 dprt=23 loc=0 frg=0 frghdr=0 len=40
2DF   22.494979968       0.088192                   IPSEC_FILTER_INFO fltro4: Matched rule 2, action is PERMIT
2DF   22.495151488       0.171520                   IPSEC_FILTER_INFO fwnato_before: src=AC100121.42923 dst=AC101602.23 len=40 sum=16037
2DF   22.495426688       0.275200                   IPSEC_FILTER_INFO fwnato_after:  src=AC101603.42923 dst=AC101602.23 len=40 sum=10691 PERMIT

Nach dem Durchlauf durch die Regeln wird auf ein NAT geprüft und der eingetragene NAT auch durchgeführt (AC100121 wird zu AC101603, womit sich auch die Checksumme ändert). Das im Speicher abgelegte IP-Paket wird modifiziert und dem Adapter zum Senden übergeben. 

12:19:56.768418176 10:0:5a:14:54:9c 8:0:5a:ba:da:a6 0800 60: 172.16.22.3.42923 > 172.16.22.2.23: . ack 1 win 17520 (DF) [tos 0x10] (ttl 59, id 37079)

Das Paket, auf dem Adapter mitgeschnitten (falls es wieder in Vergessenheit geraten sein sollte: der Größenunterschied von 40 zu 60 Byte beruht auf dem jetzt mitgezählten IP-Header. 

 
Aug 12 12:19:57 elguardia : 2003;5422: 2151;ICA1075i;1;504;501;2;p;o;172.16.22.1
;172.16.1.33;172.16.22.2;tcp;sp:;42923;dp:;23;r;n;n;0;40;

Das gleiche Paket im Firewall-Log. Connection und Service wie gehabt, das Paket ist Outbound, und zwar über das unsichere Interface.

Als Anhang noch die Start-Meldung des trace-Kommandos. Es gibt allgemein Informationen über die Maschine und die Art des Traces aus. Danach folgen Informationen über das Hochfahren des Filter-Interfaces. Der oben auseinander genommene Trace ist dann abgeschnitten worden. 

 
Tue Aug 12 12:19:33 2003
System: AIX elguardia Node: 4
Machine: 005001274D00
Internet Address: AC100101 172.16.1.1
The system contains 1 cpus, of which 1 were traced.
Buffering: Kernel Heap
This is from a 32-bit kernel.



trace -a -j 2df 


ID     ELAPSED_SEC     DELTA_MSEC   APPL    SYSCALL KERNEL  INTERRUPT

001    0.000000000       0.000000                   TRACE ON channel 0
                                                    Tue Aug 12 12:19:34 2003
2DF   14.668515328   14668.515328                   IPSEC_FILTER_INFO filter_if_mpx in
2DF   14.668559872       0.044544                   IPSEC_FILTER_INFO filter_if_mpx out
2DF   14.668919424       0.359552                   IPSEC_FILTER_INFO filter_if_open
2DF   14.669099904       0.180480                   IPSEC_FILTER_INFO filter_if_ioctl
2DF   14.669238272       0.138368                   IPSEC_FILTER_INFO filter_if_close
2DF   14.669294976       0.056704                   IPSEC_FILTER_INFO filter_if_mpx in
2DF   14.669320064       0.025088                   IPSEC_FILTER_INFO filter_if_mpx out

[ Main | Local ]

[ 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
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )