FortiGate:Diagnose-Sniffer-Guide

Aus Fortinet Wiki
Zur Navigation springen Zur Suche springen

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! 

Fortinet-3348.jpg

Folgendermassen kann das Offloading in einer Firewallregel deaktiviert werden:

Config cli.png 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.

Config cli.png 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.
Dies kann kann auch any sein, um alle Interfaces abzufragen.

['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:

  1. Header der Pakete anzeigen
  2. Anzeigen des des Headers und der Daten von IP-Paketen
  3. Anzeigen des Headers und der Daten von Ethernet-Paketen
  4. Header der Pakete mit Interfacenamen anzeigen
[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: 

   diagnose sniffer packet any "tcp[13] & 4 != 0" 6 0 a 

   Fortinet-3349.jpg

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: 

   diagnose sniffer packet any "ip[6] & 32 != 0 or ip[7] != 0" 6 0 a 

  Fortinet-3350.jpg

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:

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
Hinweis.svg
  • Benutze den Level 4, um den Trafficsfluss zu überprüfen und festzustellen, ob die FortiGate Pakete verwirft.
  • Benutze den Level 6, um Protokoll-Header und Payload zu sehen. Geeignet für die Konvertierung von .PCAP Files.

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.

Info.svg

Tipp: Für weitere Untersuchungen ist es immer eine gute Idee, die SSH-Ausgabe in eine Datei zu protokollieren.
Wenn Putty (ein kostenloser SSH-Client für Windows) verwendet wird, ist es möglich, alle Ausgaben in eine Datei zu protokollieren, die dann durchsucht/sortiert/verarbeitet werden kann.

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 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:

Config cli.png Konfiguration über die CLI: 
# diagnose sniffer packet ppp0
Info.svg

Dieses SubInterface ist nur vorhanden, wenn pppoe auf einen Interface konfiguriert ist.

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:

Config cli.png Konfiguration über die CLI: 
# diagnose sniffer packet any 1 0 a
Info.svg

Die Angabe 1 gibt die Verbosity an dh. 1 = Zeigt header des Packets". "0" indiziert den Counter was wiederum bedeutet "wieviele" Packet angezeigt werden sollen (0 = unlimited).

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:

Config cli.png 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:

Config cli.png 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
Abgerufen von „http://fortinet.also.ch/wiki/index.php?title=FortiGate:Diagnose-Sniffer-Guide&oldid=37132“