FortiGate:Diagnose-Sniffer-Guide
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 in einfachen oder doppelten Anführungszeichen eingeschlossen ist.
Syntax:
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:
"[ [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] ]"
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[13] & 4 != 0" 6 0 a
Alternativ kann auch folgender Syntax verwendet werden:
diagnose sniff packet any "tcp[tcpflags] & tcp-rst == tcp-rst" 6 0 a
Aufzeichnen von nur fragmentierten IPv4 Packeten:
- Infos können hier entnommen werden: RFC 791 3.1
diagnose sniffer packet any "ip[6] & 32 != 0 or ip[7] != 0" 6 0 a
Die Flags bedeuten folgendes:
- Bit 0: Reserviert; muss Null sein
- Bit 1: Nicht Fragmentiert (Don't Fragment DF)
- Bit 2: Weitere Fragmente (More Fragment MF)
Unter folgendem Link findest du weitere Informationen zur Erstellung erweiterter Filter:
- https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Using-the-FortiOS-built-in-packet-sniffer/ta-p/194222
- https://www.tcpdump.org/manpages/pcap-filter.7.html
- https://wiki.wireshark.org/CaptureFilters
add 13.03.2024 - 4Tinu
Details zu der Option VERBOSE
diagnose sniffer packet [interface] "[filter]" [verbose] [count][timestamp_format]
Aus der folgenden Tabelle kann entnommen werden wie ausführlich die Ausgabe ist, wenn der Verbose Wert angepasst wird:
| Level | IP Headers | Packet Payload | Ethernet Headers | Interface Name |
| 1 | ja | nein | nein | nein |
| 2 | ja | ja | nein | nein |
| 3 | ja | ja | ja | nein |
| 4 | ja | nein | nein | ja |
| 5 | ja | ja | nein | ja |
| 6 | ja | ja | ja | ja |
|
|
In diesem Beispiel sehen wir exakt das selbe Paket, einmal mit dem Level 4 und einmal mit dem Level 6:
Verbosity auf Level 4:
diagnose sniffer packet any 'icmp and host 1.1.1.1' 4 0 a
interfaces=[any]
filters=[icmp and host 1.1.1.1]
2024-03-13 12:14:11.529757 WORK_VLAN_42 in 192.168.42.4 -> 1.1.1.1: icmp: echo request
2024-03-13 12:14:11.529978 wan1 out 192.168.0.38 -> 1.1.1.1: icmp: echo request
Verbosity auf Level 6:
diagnose sniffer packet any 'icmp and host 1.1.1.1' 6 0 a
interfaces=[any]
filters=[icmp and host 1.1.1.1]
2024-03-13 12:14:11.529750 WORK_VLAN_42 in 192.168.42.4 -> 1.1.1.1: icmp: echo request
0x0000 0000 0000 0001 f2e8 1b35 47fb 0800 4500 .........5G...E.
0x0010 0054 c5eb 4000 4001 880f c0a8 2a04 0101 .T..@.@.....*...
0x0020 0101 0800 bf7b 0005 0001 9394 da62 0000 .....{.......b..
0x0030 0000 03b4 0800 0000 0000 1011 1213 1415 ................
0x0040 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060 3637 67
2024-03-24 12:14:11.529974 wan1 out 192.168.0.38 -> 1.1.1.1: icmp: echo request
0x0000 0000 0000 0000 704c a5f1 0e30 0800 4500 ......pL...0..E.
0x0010 0054 c5eb 4000 3f01 b2ed c0a8 0026 0101 .T..@.?......&..
0x0020 0101 0800 d37a ec05 0001 9394 da62 0000 .....z.......b..
0x0030 0000 03b4 0800 0000 0000 1011 1213 1415 ................
0x0040 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060 3637 67
add 13.03.2024 - 4Tinu
Details zu der Option COUNT
diagnose sniffer packet [interface] "[filter]"[verbose] [count] [timestamp_format]
Der Count Parameter definiert, wieviele Pakette geangezeigt werden.
Wenn kein Wert oder der Count Wert auf Null (count 0) gesetzt wird, läuft der Sniffer unendlich weiter, bis dieser mit <CTRL+C> gestoppt wird.
|
Tipp: Für weitere Untersuchungen ist es immer eine gute Idee, die SSH-Ausgabe in eine Datei zu protokollieren. weitere Infos in diesem Wikiartikel |
add 14.03.2024 - 4Tinu
Details zu der Option TIMESTAMP_FORMAT
diagnose sniffer packet [interface] "[filter]"[verbose] [count] [timestamp_format]
Definiert das Format des Zeitstempels:
- a: absolute UTC-Zeit, jjjj-mm-tt hh:mm:ss.ms
- l: absolute LOKALE Zeit, jjjj-mm-tt hh:mm:ss.ms-
- ansonsten: relativ zum Beginn des Sniffing, ss.ms
add 14.03.2024 - 4Tinu
Wie kann ich das Sniffen abbrechen?
Mit der Tastenkombination CTRL und C wird das Sniffen unterbrochen.
Nachdem du den Sniffer mit CTRL+C gestoppt hast, erhälst du einen Bericht, wie viele Pakete erfasst (empfangen) und wie viele Pakete vom Kernel verpasst (verworfen) wurden.
Weiterhin ist zu beachten, dass bei der Ausführung des Befehls diagnose sniffer packet
im Hintergrund effektiv ein "Linux-basierter tcpdump" durchgeführt wird.
Dabei wird die "libpcap"-Bibliothek verwendet. Der Puffer, den diese Bibliothek nutzt,
beträgt 2 MB. Wenn der Befehl diagnose sniffer packet speziell mit der Option "full capture"
ausgeführt wird, z. B. diagnose sniffer packet any 6 0 l,
kann es bei hohem Traffic auf der FortiGate nach Beendigung des Befehls zu folgender Ausgabe kommen:
604617 packets received by filter
480271 packets dropped by kernel
Diese Ausgabe deutet nicht darauf hin, dass Pakete verworfen wurden, sondern signalisiert einen "filter buffer overflow".
Wenn dies auftritt, ist es möglich, dass das, was versucht wurde zu erfassen, tatsächlich nicht erfasst wurde. Das Aktivieren des Sniffers verbraucht zusätzliche CPU-Ressourcen. Dies bedeutet, dass die 2 MB des Buffers nicht ausreichten, um die Pakete zu speichern und sie daher verworfen wurden (Bufferüberlauf). Dies kann bei Low-End-Modellen bis zu zusätzlichen 25% der CPU-Auslastung betragen. Daher kann die Aktivierung auf einer FortiGate, die bereits übermässig hohe CPU-Auslastung aufweist, die Situation nur verschlimmern. Wenn es notwendig ist, eine Erfassung durchzuführen, halte die Sniffer Sessions kurz.
- Eine Lösung, um dies zu verhindern, besteht beispielsweise darin, einen niedrigeren "verbose" Level zu verwenden. Das heisst anstelle von "6" wird ein niedrigerer "verbose" Level verwendet. Weitere Informationen zu den "verbose" Levels findest du im Artikel: Details zu der Option VERBOSE.
- Eine weitere Möglichkeit, dies zu verhindern, besteht darin, den Filter genauer durch Angabe von Destination, Source usw. festzulegen. Informationen wie der Filter gesetzt werden kann findet man in diesem Wiki Artikel: Details zu der Option FILTER
- Eine weitere Möglichkeit ist die Verwendung der "Capture" -Funktion anstelle des Befehls
diagnose sniffer packet, da für diese Funktion die Anzahl der zu erfassenden Pakete definiert werden kann, um einen Bufferüberlauf zu vermeiden.
Weitere Gründe:
- Kurze Ethernet-Frames, die von der FortiGate gesendet werden, können unter der Mindestlänge von 64 Bytes (auch bekannt als 'Runts') erscheinen. Dies liegt daran, dass der Sniffer keine Ethernet-Trailer-/Padding-Informationen anzeigt, obwohl diese über das Kabel gesendet werden.
- Die Ethernet-Source- und/oder Destination-MAC-Adressen können falsch sein, bei Verwendung von 'any' bei der Interface Option. Diese können dann als alles Nullen (00:00:00:00:00:00) oder 00:00:00:00:00:01 angezeigt werden.
- Das Ausführen einer Paketerfassung beim Anschliessen an den Konsolenport erfasst möglicherweise nicht den gesamten Datentraffic. Das liegt daran, dass die Geschwindigkeit des Konsolenports signifikant niedriger ist, als bei anderen Ports. Darum wird die Ausgabe gekürzt.
Ein erfolgreiches Beispiel bei welchem alle Pakete gesnifft wurden sieht folgendermassen aus:
7161 packets received by filter
0 packets dropped by kernel
add 13.03.2024 - 4Tinu
Beispiele fuer diagnose sniffer packet
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