FortiGate:Diagnose-Sniffer-Guide: Unterschied zwischen den Versionen
4Tinu (Diskussion | Beiträge) |
4Tinu (Diskussion | Beiträge) |
||
| Zeile 243: | Zeile 243: | ||
Es werden nur Packete gesnifft bei welchen das TCP RST Bit gesetzt ist: | Es werden nur Packete gesnifft bei welchen das TCP RST Bit gesetzt ist: | ||
* <small> Infos können hier entnommen werden: [https://datatracker.ietf.org/doc/html/rfc793#section-3.1 RFC 793 3.1] | * <small> Infos können hier entnommen werden: [https://datatracker.ietf.org/doc/html/rfc793#section-3.1 RFC 793 3.1] | ||
diagnose sniffer packet any | diagnose sniffer packet any "tcp[<span style="color red"13</span>] & 4 != 0" 6 0 a | ||
---- | ---- | ||
Version vom 13. März 2024, 09:25 Uhr
FortiGate:Diagnose-Sniffer-Guide
Vorwort
Das Kommando "diagnose sniffer packet" ist ein mächtiges Kommando/Tool und basiert im Hintergund auf "tcpdump". Es lohnt sich die verschiedenen Möglichkeiten von "diagnose sniffer packet" anzuschauen um bei Problemen Schritt für Schritt ein Troubleshooting durchzuführen.
Datenschutz
*********************************************************************
* *
* THIS FILE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY *
* PROTECTED INFORMATION. YOU ARE PROHIBITED FROM COPYING, *
* DISTRIBUTING OR OTHERWISE USING IT WITHOUT PERMISSION FROM *
* ALSO SCHWEIZ AG SWITZERLAND. *
* *
*********************************************************************
"Die in diesen Artikeln enthaltenen Informationen sind vertraulich und dürfen ohne
schriftliche Zustimmung von der ALSO Schweiz AG gegenüber Dritt-Unternehmen nicht
bekannt gemacht werden"
Grundlagen beim Sniffen
Welche Methoden stellt die FortiGate zu Verfuegung zum sniffen?
Vergleich der FortiOS-Paketaufzeichnungsmethoden:
| WebGUI bis und mit 7.0 |
WebGUI ab 7.2 |
CLI | |
| Features ist unter folgendem Menu im Gui abrufbar: | Network → Packet Capture | Network → Daignostics → Packet Capture | N/A |
| Anzahl maximal erfasste Packete: | 10'000 | 50'000 | unlimitiert |
| Supportet erweiterte Filters (Logische Operationen) | Nein | Ja | Ja |
| Herunterladbare .PCAP Datei | Ja | Ja | Ja |
| Unterstützt "any" Interface | Nein | Ja | Ja |
| Sichtbare Erfassung in Echtzeit | Nein | Ja | Ja |
| Unterstützt von Fortigates ohne SSD-Speicher | Nein | Ja | Ja |
* Hängt von der Konfiguration des Terminalemulators ab
add 29.02.2024 - 4Tinu
Was muss beim Sniffen beachtet werden?
Bevor versucht wird den Traffic auf der FortiGate zu Capturen ist folgendes sicherzustellen:
1.) Das ASIC Offloading muss in der betroffenen Firewall Regel deaktiviert werden. Grund dafür ist, dass Sessions welche in die Netzwerkporzessoren(NP6, NP6Lite) ausgelagert werden, nicht vom Sniffer erfasst werden!
Folgendermassen kann das Offloading in einer Firewallregel deaktiviert werden:
 Konfiguration über die CLI:
|
config firewall policy edit <POLICY_ID> set auto-asic-offload disable end |
Damit eine übermässige CPU Auslastung auf der FortiGate verhindert werden kann, empfehlen wir eine spezifische Firewall Regel zu erstellen und in dieser das ASIC Offloading darin zu deaktivieren. Nach dem Troubleshooting nicht vergessen, die Änderungen (Konfigurierte Firewallregeln) wieder rückzubauen.
| Konfiguration über die CLI:
|
config firewall policy edit <POLICY_ID> set auto-asic-offload enable end |
2.) Stelle sicher, dass der Output in eine Textdatei geschrieben wird, damit im Nachgang die Daten einfacher analysiert werden können. Das Sniffen kann sehr viele Daten generieren, daher wird mit grosser Wahrscheinlichkeit auch der Buffer überlaufen und es werden dann nicht alle Daten angeschaut werden können.
Wie mann das Putty konfiguriert um den Output in eine Datei schreiben zu lassen ist im folgenden Artikel :
add 29.02.2024 - 4Tinu
FortiOS packet sniffer - CLI
Das generelle sniffer Kommando setzt sich aus folgenden Komponenten zusammen:
diagnose sniffer packet [interface] "[filter]" [verbose] [count] [timestamp_format]
| Term: | Beschreibung: |
| [interface_name] |
Der Name des Interfaces, welches gesnifft werden soll. z.B. port1 oder internal. |
| ['filter'] |
Der Filter definiert welche Informationen, die der Sniffer liest, angezeigt werden sollen none bedeutet keine das es keinen Filter gibt und alle Pakete werden so angezeigt, wie es die anderen Argumente angeben. Der Filter muss in einfachen Anführungszeichen (') oder doppelten Anführungszeichen (") stehen. |
| [verbose] |
verbose definiert die Stufe der Ausführlichkeit als eine von:
|
| [count] |
Count definiert die Anzahl der Pakete, die der Sniffer liest, bevor er aufhört. Wenn keine bei Coundt keine Zahl angegeben wird, läuft der Sniffer, bis er mit der Tastenkombination <CTRL+C> gestoppt wird. |
|
[timestamp_format] |
Definiert das Format des Zeitstempels:
|
edit 06.03.2024 - 4Tinu
Details zu der Option INTERFACE
diagnose sniffer packet [interface] "[filter]" [verbose] [count] [timestamp_format]
Diese Option beschreibt den Interface Name, auf welchem die Paketerfassung durchgeführt wird.
Um auf allen Interfaces den Datentraffic zu erfassen kann die Option "ANY" konfiguriert werden:
Ein paar Beispiele:
diagnose sniffer packet wan2 "<filter>" <verbose> <count> <timestamp_format> → Sniffen auf dem wan2 Interface diagnose sniffer packet port1 "<filter>" <verbose> <count> <timestamp_format> → Sniffen auf dem port1 Interface diagnose sniffer packet any "<filter>" <verbose> <count> <timestamp_format> → Sniffen auf allen Interfaces
add 13.03.2024 - 4Tinu
Details zu der Option FILTER
diagnose sniffer packet [interface] "[filter]" [verbose] [count] [timestamp_format]
Der Filter Parameter gibt an, welche Art von Datenverkehr erfasst werden soll. Dabei ist darauf zu achten, dass der Ausdruck immer eingeschlossen in einfachen oder doppelten Anführungszeichen ist.
Basis Filter Beispiele:
Erfassen des gesamten Datenverkehr von der Source IP Adresse 198.18.20.1: src
diagnose sniffer packet any "src 198.18.20.1" 4 0 a
Erfassen des gesamten Datenverkehr von der Source oder Destination mit der IP Adresse 198.18.20.1: host
diagnose sniffer packet any "host 198.18.20.1" 4 0 a
Erfassen des gesamten Datenverkehr von oder zu einem spezifischen Subnet. In diesem Beispiel mit dem Netz 198.18.20.0/24: net
diagnose sniffer packet any "net 198.18.20.0/24" 4 0 a
Erfassen von allem DNS Traffic vom Port 53 port
diagnose sniffer packet any "port 53" 4 0 a
Erfassen von allem ICMP Traffic icmp
diagnose sniffer packet any "icmp" 4 0 a
oder
diagnose sniffer packet any "proto 1" 4 0 a
Dabei können auch verschiedene Parameter wie Source und Destinationen mit logischen Operationen verknüpft werden:
| Vorrangige Bedeutung | Operator | Symbol |
| High | NOT | ! |
| Medium | AND | $$ |
| Low | OR | || |
Die folgenden Beispiele zeigen komplexere Anwendungen um den Filter zu setzen:
Um den ICMP- oder HTTP-Verkehr von/nach oder 85.251.22.54 zu erfassen müssen logische Operationen verwendet werden:
diagnose sniffer packet any "host 85.251.22.54 and (icmp or port 80)" 6 0 a
Damit der Traffic mit der Source IP Adresse 198.18.20.1 aber ohne SSH traffic aufgezeichnet werden kann, muss SSH negiert werden mit dem Operator <coce> no :
diagnose sniffer packet any "src 198.18.20.1 and not port 22)" 6 0 a
Folgendermassen wird der Broadcast Traffic auf dem port1 mit Ausnahme von ARP gesnifft:
diagnose sniffer packet any "broadcast and not arp" 6 0 a
So wird der gesamten ARP Traffic an Trunk-Port1 mit VLAN-ID 10 gesnifft:
diagnose sniffer packet any "vlan 10 and arp" 6 0 a
Damit LACP-Frames aufgezeichnet werden können, muss EtherType (Hex) verwendet werden:
diagnose sniffer packet any "ether proto 0x8809" 6 0 a
Es werden nur Packete gesnifft bei welchen das TCP RST Bit gesetzt ist:
- Infos können hier entnommen werden: RFC 793 3.1
diagnose sniffer packet any "tcp[<span style="color red"13] & 4 != 0" 6 0 a
add 13.03.2024 - 4Tinu
diagnose sniffer packet
Wie benutze ich das Sniffer Kommando "diagnose sniffer packet"?
Das Sniffer Kommando ist folgendermassen aufgebaut:
# diagnose sniffer packet <interface_name> <‘filter’> <verbose> <count> a
<interface_name>
Name des Interfaces auf dem der Sniffer ausgeführt wird zB port1 oder internal. Es kann ebenfalls "any" benutzt werden
um auf "allen" Interfaces den Sniffer auszuführen!
<‘filter’>
Definition nach "was" gefiltert werden soll. Das Keyword "none" bedeutet kein Filtering und somit werden alle Packete
angezeigt. Ein Filter muss innerhalb von "quotes" definiert werden! Als "quotes" kann folgendes benutzt werden: ‘ ' "
Syntax: '[ [src|dst] host<host_name_or_IP1> ] [ [src|dst] host<host_name_or_IP2> ] [ [arp|ip|gre|esp|udp|tcp] [port_no] ] [ [arp|ip|gre|esp|udp|tcp] [port_no] ]'
Beispiele:
Nicht Port 443 = '!port 443'
Port 443 = 'port 443'
Host = 'host 192.168.1.1'
Host und Host = 'host 192.168.1.1 and host 192.168.1.2'
Host und Port 443 = 'host 192.168.1.1 and port 443'
Host und nicht Port 443 = 'host 192.168.1.1 and !port 443'
Host oder Port 443 = 'host 192.168.1.1 or port 443'
Nur udp Traffic = 'udp'
Nur SYN Flag = 'tcp[13]&2==2'
Nur ARP Packete = 'arp'
<verbose>
Definiert den Level der "Verbosity":
1 - Zeigt header des Packets
2 - Zeigt header und data von IP Packeten
3 - Zeigt header und data von Ethernet Packeten (Frames ACSII und HEX)
4 - Zeigt header und Interface Name des Packets
5 - Zeigt header und data von IP Packeten mit Interface Namen
6 - Zeigt header und data von Ethernet Packeten mit Interface Namen
Datei:Fortinet-1420.jpg
<count>
Definiert den Counter resp. die Anzahl der Packete die angezeigt werden sollen bevor der Sniffer stoppt. Wenn kein
Counter defniert wird gilt "unlimited". Dies bedeutet wiederum um den Sniffer abzubrechen muss folgendes in der
Session/Console durchgeführt werden:
<CTRL C>.
Wird nach dem Counter "a" angegeben so wird das Datum ausgegeben mit genauer Zeit!
Diese Informationen stammen aus vers. Quellen sowie folgender link:
http://kb.fortinet.com/kb/documentLink.do?externalId=11186
Desweiteren ist folgendes zu berücksichtigen: Wenn ein "diagnos sniffer packet" ausgeführt wird so wird im Hintergrund im eigentlichen Sinne ein "Linux basierender tcpdump" ausgeführt. Die dazu benutzte Library ist die "libpcap" Library. Der Buffer der diese Library benutzt liegt bei 2 MB. Wenn ein "diagnose sniffer packet" ausgeführt wird speziell mit der Angabe eines "full capture" dh. zB "diagnose sniffer packet any 6 0 l" kann bei sehr hohen Traffic auf der FortiGate nach dem beenden des ""diagnose sniffer packet any 6 0 l" folgendes ausgegeben werden:
xxxxxx packets dropped by kernel
Diese Ausgabe indiziert nicht das Packete verworfen worden sind, sondern inidiziert einen "filter buffer overflow" was wiederum bedeutet die 2 MB reichten nicht aus um die Packete in den "Buffer" vn 2 MB zu schreiben und wurden deshalb verworfen (überlauf des "Buffers". Eine Lösung wie dies verhindert werden kann ist zB einen tieferen "verbose" Level zu benutzen dh. anstelle von "6" wird ein tieferer "verbose" Level benutzt. Weitere Informationen zu den "verbose" Level siehe oben. Eine weitere Möglichkeit dies zu verhindern ist eine genauere Angabe des Filters anhand Destination, Source usw. Wiederum eine weitere Möglichkeit ist anstelle des "diagnose sniffer packet" Kommandos die "Capture" Funktion zu benutzen, denn für diese Funktion kann die Anzahl der Packete definiert werden um einen "Buffer" Ueberlauf zu verhindern. Diese Funktion findet man für FortiOS 5.0 sowie 5.2 unter folgender Position im Web Mgmt. Interface:
System > Network > Packet Capture
Weitere Informationen zur "Capture" Funktion siehe auch nachfolgende Artikel:
FortiGate-5.0-5.2:FAQ#Packet_Capture
Wie Sniffe den Traffic auf einem PPPoE Interface?
Wenn man auf einem PPPoE Interface den Traffic sniffen möchte ist das "so" nicht einfach möglich. Dies bedeutet, wenn auf dem "wan1" Interface (PPPoE konfiguriert) folgendes Kommando benutzt wird "diagnose sniffer packet wan1" sieht man nur die PPPoE "encapsulated" Packete jedoch nicht die effektive Source und Destination. Um den Traffice zu sniffen "bevor" diese "encapsulated" werden muss das Interface "ppp0" benutzt weden. Das bedeutet folgendes:
| Konfiguration über die CLI:
| ||
# diagnose sniffer packet ppp0
|
Wie Sniffe den Traffic und zeige für das Packet Datum und Zeit an?
Wenn man innerhalb der Sniffer-Ausgabe für jedes Packet das Datum und die Zeit anzeigen möchte muss dies nach dem Counter mit "a" angegeben werden:
| Konfiguration über die CLI:
| ||
# diagnose sniffer packet any 1 0 a
|
Wie sniffe ich den gesamten Traffic ausser den Port 22?
Um einen bestimmten Wert zu negieren wird dass Ausrufezeichen ! vor den Term gesetzt. In unserem Beispiel soll der Port 22 nicht berücksichtigt werden. Darum wird vor port das Ausrufezeichen gesetzt:
| Konfiguration über die CLI:
|
# diagnose sniffer packet [Interface Name] "!port 22" Benutze den Level "3" um die Ethernet Frames in ACSII und HEX anzeigen zu lassen dh.: # diagnose sniffer packet [Interface Name] "!port 22" 3 |
Wie sniffe ich den Traffic für einen bestimmten Port auf allen Interfaces?
Wenn der "level" 4 benutzt wird so werden die benutzen Interfaces zusätzlich angezeigt dh. auf welchem Interface das Packet angeliefert wird und auf welchem Packet es ausgeliefert wird:
| Konfiguration über die CLI:
|
# diagnose sniffer packet any "port 443" 4 Beispiel: # diagnose sniffer packet any "port 443" 4 interfaces=[any] filters=[port 443] 0.445818 port1 out 198.18.0.1.3447 -> 198.18.0.103.443: syn 1329431818 0.446355 port1 in 198.18.0.103.443 -> 198.18.0.1.3447: syn 2498061333 ack 1329431819 0.446374 port1 out 198.18.0.1.3447 -> 198.18.0.103.443: ack 2498061334 0.476534 npu0_vlink1 in 54.165.240.89.443 -> 146.4.73.70.42840: ack 2789816400 0.476545 sg0e0-cisco0 out 54.165.240.89.443 -> 198.18.1.2.42840: ack 2789816400 0.476546 sg0e0-cisco1 in 54.165.240.89.443 -> 198.18.1.2.42840: ack 2789816400 0.476551 sg0-cisco-lan out 54.165.240.89.443 -> 198.18.1.2.42840: ack 2789816400 0.476552 alsochlu-sg0-ag out 54.165.240.89.443 -> 198.18.1.2.42840: ack 2789816400 0.476554 port8 out 54.165.240.89.443 -> 198.18.1.2.42840: ack 2789816400 0.645094 port2 in 178.197.236.9.32773 -> 146.4.73.73.443: psh 1701351578 ack 1210662339 0.645104 pe_wan-nu0 out 178.197.236.9.32773 -> 146.4.73.73.443: psh 1701351578 ack 1210662339 0.645106 pe_wan-nu1 in 178.197.236.9.32773 -> 146.4.73.73.443: psh 1701351578 ack 1210662339 0.645113 vl-nu-slan out 178.197.236.9.32773 -> 198.18.5.100.443: psh 1701351578 ack 1210662339 Benutze den Schalter "3" um die Ethernet Frames in ACSII und HEX anzeigen zu lassen dh.: # diagnose sniffer packet any "port 443" 3 interfaces=[any] filters=[port 443] 2.452878 92.107.9.16.61230 -> 146.4.73.66.443: ack 607065881 0x0000 0000 0000 0001 105a f76e 10e2 0800 4500 .......Z.n....E. 0x0010 0028 6eeb 4000 7706 5423 5c6b 0910 9204 .(n.@.w.T#\k.... 0x0020 4942 ef2e 01bb 3ebb 04ed 242f 1719 5010 IB....>...$/..P. 0x0030 0201 fd37 0000 ...7.. 2.452883 92.107.9.16.61230 -> 146.4.73.66.443: ack 607065881 0x0000 0000 0000 0000 105a f76e 10e2 0800 4500 .......Z.n....E. 0x0010 0028 6eeb 4000 7706 5423 5c6b 0910 9204 .(n.@.w.T#\k.... 0x0020 4942 ef2e 01bb 3ebb 04ed 242f 1719 5010 IB....>...$/..P. 0x0030 0201 fd37 0000 ...7.. 2.452884 92.107.9.16.61230 -> 146.4.73.66.443: ack 607065881 0x0000 0000 0000 0001 105a f76e 10e2 0800 4500 .......Z.n....E. 0x0010 0028 6eeb 4000 7706 5423 5c6b 0910 9204 .(n.@.w.T#\k.... 0x0020 4942 ef2e 01bb 3ebb 04ed 242f 1719 5010 IB....>...$/..P. 0x0030 0201 fd37 0000 ...7.. |
Sniffe den Traffic "für einen bestimmten Host/IP" auf "allen Interfaces"?
# diagnose sniffer packet any "host [IP Adresse für Dst]" 4
Benutze den Schalter "3" um die Ethernet Frames in ACSII und HEX anzeigen zu lassen dh.:
# diagnose sniffer packet any "host [IP Adresse für Dst]" 3
Sniffe den gesamten Traffic "von und zu einem bestimmten Host auf port 80"?
# diagnose sniffer packet [Interface Name] "host 10.0.1.10 and port 80"
Benutze den Schalter "4" um den Interface Namen anzeigen zu lassen dh. :
# diagnose sniffer packet [Interface Name] "host 10.0.1.10 and port 80" 4
Sniffe den gesamten UDP/DNS Traffic für ein bestimmtes Interface?
# diagnose sniffer packet [Interface Name] "udp and port 53"
Sniffe alle TCP Packete "mit einem SYN Flag"?
# diagnose sniffer packet any 'tcp[13] == 2'
Sniffe alle TCP Packete "mit einem SYN Flag und nur HTTP"?
# diagnose sniffer packet any "port 80 and tcp[13]&2==2" 4
Sniffe alle TCP Packete "mit einem RST Flag"?
# diagnose sniffer packet any "tcp[13] & 4 != 0"
Sniffe alle ICMP Packete "ausser die für Ping"?
# diagnose sniffer packet any 'icmp[0] != 8 and icmp[0] != 0' 4
Sniffe alle 802.1q Tagging Packete?
# diagnose sniffer packet any "none" 6 0 a
Sniffe Packete im Format das in Wireshark benutzt werden kann?
Wenn über das "sniffer" Kommando ein Format ausgegeben werden soll das später im WireShark eingelesen werden kann muss der "level" 3 oder 6 benutzt werden. Der "level" 3 und 6 stehen für:
3 - Zeigt header und data von Ethernet Packeten (Frames ACSII und HEX)
6 - Zeigt header und data von Ethernet Packeten mit Interface Namen
Somit muss im zB "putty" Logging in ein File aktiviert werden. Danach geben das entsprechende "sniffer" Kommando ein zB:
# diagnose sniffer packet any [3 oder 6]
Danach kann der Output resp. nur der Output der Ausgabe des sniffer Kommandos vom Log von "putty" in ein File kopiert werden mit der Endung .pcap um es später in Wireshark einlesen zu können.
Sniffe Packete um "fragmentation" Informationen zu erhalten?
Das Kommando um eine "fragmentation" zu eruieren zB anhand "udp" auf Interface "wan1" sieht folgendermassen aus
# diagnose sniffer packet wan1 "udp" 4 0 a
interfaces=[wan1]
filters=[udp]
2015-02-18 09:28:00.095018 wan1 in 10.108.16.82.9388 -> 255.255.255.255.9388: udp 2394 (frag 37572:1472@0+)
2015-02-18 09:28:00.095111 wan1 in 10.108.16.82 -> 255.255.255.255: ip-proto-17 (frag 37572:930@1472)
NOTE Auf was muss geachtet werden: Die Uebetragung der Session wird identifiziert anhand der "ID=37572". Hier sieht man das
in der ersten Uebettragung "1472" bytes übermittelt wurden und danach für die gleiche Ubertragung (37572) ein zweites
Packet mit "930" bytes. In der zweiten Uebtragung wird indiziert das die ID aus zwei Packeten besteht dh. "930@1472". Somit
ergiebt sich ein gesamt Packet von "2402" bytes. Da unter normalen Umständen eine MTU gilt von "1500" konnte das Packet über
"2402" bytes nicht in einem Packet übertragen werden und aus diesm Grund musste ein zweites Packet gesendet werden. Dies
bedeutet: Eine Fragmentation hat stattgefunden jedoch in regulärer Form da durch die MTU Size von "1500" ist die Uebertragung
gezwungen zwei Packete zu senden!
Sniffe Packet für LDAP Port 389 um entsprechende "error" Nachrichten zu erhalten?
Wenn für LDAP Verbindungen resp. Authentifizierungs Probleme ein Troubleshooting durchgeführt werden soll, kann dies ebenfalls über das Sniffer Kommando durchgeführt werden:
# diagnose sniffer packet any "port 389" 3
NOTE Kombinationen wie zB die IP des Clients mit den Authentifizierungs Probleme einzuschränken sind möglich
wie zB. "port 389 and host 192.168.1.1"!
Im Output dieses Sniffer Kommandos durch die Angabe "3" werden die "error" Nachricht in HEX dargestellt. Diese haben folgende Bedeutung:
0x525 - user not found
0x52e - invalid credentials
0x530 - not permitted to logon at this time
0x531 - not permitted to logon from this workstation
0x532 - password expired
0x533 - account disabled
0x701 - account expired
0x773 - user must reset password
0x775 - account locked out
Sniffe Packete für IPSec betreffend IKE sowie ESP Traffic (NAT/NAT-T)?
Wenn man für ein IPSec ein Troubleshooting durchführen will muss unterschieden werden ob Phase-1/2 untersucht werden soll oder der IKE sowie ESP Traffic. Für das Debug für Phase-1/2 ist "diagnose debug application ike -1" zu benutzen. Weitere Informationen dazu siehe nachfolgenden Artikel:
FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_IPSec_VPN_f.C3.BCr_Phase-1_und.2Foder_2_ein_Debugging_ausf.C3.BChren.3F
Wenn der initial Traffic betreffend IKE sowie ESP IP Protokol untersucht werden soll kann der Sniffer benutzt werden. Dabei ist Wichtig zu wissen welche Ports benützt werden in welcher Situation (NAT / NAT-T):
Protokol NAT und NAT-T No NAT
IKE Initial UDP Port 500 UDP Port 500
UDP Port 4500 nachdem NAT erkannt wurde
ESP Encapsulated in UDP Port 4500 IP Protokoll 50
Um die Packet mit dem Sniffer betreffend obiger Aufstellung aufzuzeichnen ist folgendes zu benutzen:
No NAT
Für IKE Traffic:
# diagnose sniffer packet [Interface Name] "host [Remote Gateway IP] and udp port 500"
Für ESP Traffic:
# diagnose sniffer packet any "host [Remote Gateway IP] and esp"
NAT und NAT-T
Für IKE und ESP Traffic:
# diagnose sniffer packet any "host [Remote Gateway IP] and (udp port 500 or udp port 4500)"
Es muss berücksichtigt werden wenn der Traffic aufgezeichnet wird das die benutzen IP Protokoll sowie UDP Ports abhängig sind ob NAT resp. NAT-T (NAT Traversal) benutzt wird. Ist kein NAT Device zwischen den involvierten Gateways so wird IKE UDP 500 sowie ESP IP Protokoll 50 benutzt. Wenn ein NAT Device zwischen den involvierten Gateway vorhanden ist (NAT-T) so benutzt IKE Initial UDP Port 500 und wechselt auf UDP Port 4500. Zusätzlich wird in so einer Situation in der ein NAT Device zwischen den Gateways existiert das IP Protokoll 50 in UDP 4500 eingepackt sprich "encapsulated" (NAT Traversal).
Sniffe Packete basierend auf "TCP Flags" Informationen?
Die nachfolgenden Informationen basieren auf dem folgenden File das durch den Fortinet Support zur Verfügung gestellt wird:
Datei:TCP flags v2.txt
Die im File "TCP_flags" basierenden technischen Informationen wurden dem Handbuch "tcpdump" entnommen (siehe auch http://de.wikipedia.org/wiki/Transmission_Control_Protocol)! Um ein "diagnose sniffer packet" Kommando auszuführen und den Filter so zu setzen, dass nach bestimmten "TCP Flags" gefilter werden kann, muss als Grundlage der Aufbau der "TCP Flags" verstanden werden. Nachfolgend eine Ausführung um die Grundlagen zu verstehen:
Die "TCP control bits section" des TCP Header besteht aus 8 bits:
Als Beispiel nehmen wir an, dass wir die Packet Filter möchten, die bei der Etablierung einer TCP Verbindung benötigt werden (SYN, ACK).
Dabei rufen wir uns in Erinnung, dass eine TCP Verbindung -wenn diese neu initiert wird- basiert auf einem "3-way handshake". Die Sequenzen
in so einem Fall sprich "3-way handshake" werden über die "TCP control bits section" gesteuert und sind die Folgenden:
1) Der "caller" der die Verbindung initiert sendet dem "recipient" (Empfänger) ein "SYN" Packet
2) Der "recipient" sendet dem "caller" als Antwort "SYN, ACK" Packete
3) Als Bestätigung sendet der "caller" ein "ACK" Packet
In unserem Beispiel möchten wir nur "SYN" Packete Filter (1). Packete aus der Sequenz 2 dh. "SYN-ACK" sollen dabei nicht gefilter werden dh.
wir möchten ausschliesslich das Initiale "SYN" (1) Filtern. Um dies zu bewerkstelligen benötigen wir den korrekten "Filter". Als Grundlage
dazu gilt der Aufbau eines TCP Header's. Zur Erinnerung:
0 15 31 Octet
-----------------------------------------------------------------
| source port | destination port | 0 - 3
-----------------------------------------------------------------
| sequence number | 4 - 7
-----------------------------------------------------------------
| acknowledgment number |
-----------------------------------------------------------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size | 7 - 14
-----------------------------------------------------------------
| TCP checksum | urgent pointer |
-----------------------------------------------------------------
Ein TCP-Header enthält in der Regel 20 Bytes, es sei den es sind Optionen vorhanden:
0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
----------------|---------------|---------------|----------------
| | 14th octet | | |
Wenn bei 0 gestartet wird, sind die "relevanten" Informationen für unser Beispiel in Octet "13" enthalten (SYN). Dies wiederum bedeutet:
Octect 07 C = CWR (Congestion Window Reduced)
Octect 08 E = ECE (ECN-Echo)
Octect 09 U = URG (Urgent)
Octect 10 A = ACK (Acknowledgment)
Octect 11 P = PSH (Push)
Octect 12 R = RST (Reset)
Octect 13 S = SYN (Synchronize)
Octect 14 F = FIN (Finish)
Diese Position stellt die "TCP control bits" dar. Wenn das Octect "13" näher betrachtet wird ergiebt sich folgendes:
| |
|---------------|
|C|E|U|A|P|R|S|F| <- TCP (und ECN) Flags
|---------------|
|7 5 3 0| <- bit Positionen
Diese Positionen stellen die "TCP control bits" dar und in diesen versteckt sich unser "SYN" Flag. Die "bits" in diesem Octet wurden Nummeriert
dh. von Rechts nach Link resp. 0 bis 7. PSH (puffer) bit ist Nummer (von Rechts das vierte bit) und das URG (urgent) bit ist Nummer 6 (das
sechste von Rechts). Was wir nun wollen ist nur das "SYN" Packet. Wenn nun ein initial Datenpacket übermittelt wird (nur SYN) sieht das TCP
Datagram betreffend Header folgendermassen aus:
|C|E|U|A|P|R|S|F| <- TCP and ECN flags
|---------------|
|0 0 0 0 0 0 1 0| <- bit value
|---------------|
|7 6 5 4 3 2 1 0| <- bit position
Wenn wir die "TCP control bits section" anschauen (value) ist nur das "SYN" Flag gesetzt (1). Unter der Annahme, dass die Oktett-Nummer 13 ein
8-Bit-Integer darstellt ist der Binäre Wert des Oktet's der Folgende:
00000010
Wenn der Binary Wert = 00000010 ist wäre der Hexdecimale Wert "2". Errechnet wird dies folgendermassen:
| bit | dec. | bit | | TCP
| pos. | value | value | total | Flag
____|______|________|_______|_______|_____
| | | | |
2 ^ 7 = 128, x 0 = 0 | CWR (ECN Congestion Window Reduced)
2 ^ 6 = 64, x 0 = 0 | ECE (ECN Capable Echo)
2 ^ 5 = 32, x 0 = 0 | URG
2 ^ 4 = 16, x 0 = 0 | ACK
2 ^ 3 = 8, x 0 = 0 | PSH
2 ^ 2 = 4, x 0 = 0 | RST
2 ^ 1 = 2, x 1 = 2 | SYN*
2 ^ 0 = 1, x 0 = 0 | FIN
____|______|________|_______|_______|_____
sum: 2
==========================================
('2 ^ 7 = 128' means '2 to the power of 7 equals 128')
NOTE Wer einfacher Binary to Hexdecimal oder umgekehrt berrechnen möchte benutzt einen Online Calculator wie zB:
http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html
Somit ergiebt sich folender Filter für "diagnose sniffer packet"
'tcp[13]==2'
Dieser Filter bedeutet nichts anderes als folgendes:
"Alle "TCP Datagrams" und deren "Octect 13" (SYN) und dessen value 2 (dh. Binary 1 = Aktiviert)"
Wenn wir diesen Filter setzen erreichen wir nicht das was wir als Beispiel angenommen haben das ALLE Datenpacket mit SYN gefilter werden dh. wenn
ein Datenpacket ebenfalls ein ACK gesetzt hätte wuerde diesese ebenfalls gefiltert werden da nur "Octet 13" gefilter wird egal welche anderen Flag's
noch gesetzt sind. Der einzige Weg dies zu erreichen dh "ausschliesslich" nur "SYN" ist das "Octet 13" dh. "SYN" mit allen anderen Flag's zu
vergleichen. Dies wird mit "AND" erreicht. Dies bedeutet wiederum:
v v
00010010 SYN-ACK 00000010 SYN
AND 00000010 (we want SYN) AND 00000010 (we want SYN)
-------- --------
= 00000010 = 00000010
^ ^
Somit ergiebt sich in anderen Worten:
( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
Dies kann wiederum folgendermassen im "diagnose sniffer packet" Filter abgebildet werden:
'tcp[13]&2==2'
Daraus ergeben sich zB folgende Filter Möglichkeiten:
'tcp[13]==1' Nur Packete mit FIN bit auf Wert 1
'tcp[13]&4==4' Alle Packet mit RST bit Wert 1
'tcp[13]&8==8' Alle Packet mit PSH bit Wert 1
'tcp[13]==16' Nur Packete mit ACK bit auf Wert 1
'tcp[13]&32==32' Alle Packet mit URG bit Wert 1
'tcp[13]&64==64' Alle Packet mit ECE bit Wert 1
'tcp[13]&128==128' Alle Packet mit CWR bit Wert 1
'tcp[13]==24' Nur Packete mit PSH und ACK bit auf Wert 1