Quelltext der Seite FortiGate:Diagnose-Sniffer-Guide

FortiGate:Diagnose-Sniffer-Guide

[[Category:Fortinet]]

__TOC__

= 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.

<br/>

= Datenschutz =

<pre>
        *********************************************************************
        *                                                                   *
        *  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"

</pre>

= Grundlagen beim Sniffen=
== Welche Methoden stellt die FortiGate zu Verfuegung zum sniffen? ==
Vergleich der FortiOS-Paketaufzeichnungsmethoden:
{| class="wikitable" 
|- style="background:#89E871"
| style="width:375px"| 
| style="width:200px"| '''WebGUI''' <br><small>bis und mit 7.0</small>
| style="width:300px"| '''WebGUI''' <br><small>ab 7.2</small>
| style="width:200px"| '''CLI'''
|-
| Features ist unter folgendem Menu im Gui abrufbar:
| Network &rarr; Packet Capture
| Network &rarr; Daignostics &rarr; 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
|-
|}
<nowiki>*</nowiki> <small>''Hängt von der Konfiguration des Terminalemulators ab''</small>
----
<small>add 29.02.2024 - 4Tinu</small>
== Was muss beim Sniffen beachtet werden?==
Bevor versucht wird den Traffic auf der FortiGate zu Capturen ist folgendes sicherzustellen:

<big>'''1.)'''</big> 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!
 [[Datei:Fortinet-3348.jpg|550px|link=]]
Folgendermassen kann das Offloading in einer Firewallregel deaktiviert werden:

{| class="wikitable" style="width:850px"
|- style="background:#89E871"
| [[file:config_cli.png|25px|link=]] '''Konfiguration über die CLI:''' 
|- 
| 
<pre style="background-color:#252269;color: #FFFFFF"> 
config firewall policy
edit <POLICY_ID>  
set auto-asic-offload disable
end
</pre>
|}

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.

{| class="wikitable" style="width:850px"
|- style="background:#89E871"
| [[file:config_cli.png|25px|link=]] '''Konfiguration über die CLI:''' 
|- 
| 
<pre style="background-color:#252269;color: #FFFFFF"> 
config firewall policy
edit <POLICY_ID>  
set auto-asic-offload enable
end
</pre>
|}

<big>'''2.)'''</big> 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 : 
* [[FortiGate:FAQ#Wie_kann_ich_im_Putty_den_Output_in_eine_Textdatei_schreiben_lassen?|Wie kann ich im Putty den Output in eine Textdatei schreiben lassen?]]
----
<small>add 29.02.2024 - 4Tinu</small>

== FortiOS packet sniffer - CLI ==
Das generelle sniffer Kommando setzt sich aus folgenden Komponenten zusammen:

      diagnose sniffer packet <span style="background-color: #FFB991;">[interface]</span> <span style="background-color:#A9C5F9;"> "[filter]"</span> <span style="background-color:#B1F3FF;">[verbose]</span> <span style="background-color:#E5DDFE;">[count]</span> <span style="background-color:#F695BE;">[timestamp_format]</span>

{| class="wikitable" 
|- style="background:#89E871"
| style="width:300px"| '''Term:'''
| style="width:550px"| '''Beschreibung:'''
|-
|<span style="background-color: #FFB991;">[interface_name]</span>
|
Der Name des Interfaces, welches gesnifft werden soll. z.B. '''port1''' oder '''internal'''. <br>
Dies kann kann auch '''any''' sein, um alle Interfaces abzufragen.
|-
|<span style="background-color:#A9C5F9;">['filter']</span>
|
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.
|-
|<span style="background-color:#B1F3FF;">[verbose]</span>
|
verbose definiert die Stufe der Ausführlichkeit als eine von:<br>
# Header der Pakete anzeigen<br>
# Anzeigen des  des Headers und der Daten von IP-Paketen<br>
# Anzeigen des Headers und der Daten von Ethernet-Paketen<br>
# Header der Pakete mit Interfacenamen anzeigen
|-
|<span style="background-color:#E5DDFE;">[count]</span>
|
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.
|-
|
<span style="background-color:#F695BE;">[timestamp_format]</span>
|
Definiert das Format des Zeitstempels
|-
|}
----
<small>edit 06.03.2024 - 4Tinu</small>
=== Details zu der Option INTERFACE ===

    diagnose sniffer packet <span style="background-color: #FFB991;">[interface]</span> "[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 <span style="background-color: #FFB991;">wan2</span> "<filter>" <verbose> <count> <timestamp_format>    &rarr; Sniffen auf dem wan2 Interface
    diagnose sniffer packet <span style="background-color: #FFB991;">port1</span> "<filter>" <verbose> <count> <timestamp_format>   &rarr; Sniffen auf dem port1 Interface
    diagnose sniffer packet <span style="background-color: #FFB991;">any</span> "<filter>" <verbose> <count> <timestamp_format>     &rarr; Sniffen auf allen Interfaces
----
<small>add 13.03.2024 - 4Tinu</small>
=== Details zu der Option FILTER ===

<big>    
     diagnose sniffer packet [interface] <span style="background-color:#A9C5F9;">"[filter]"</span> [verbose] [count] [timestamp_format]
</big>
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:'''<br>
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: <code> src </code>

    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"'''src''' 198.18.20.1"</span> 4 0 a
Erfassen des gesamten Datenverkehr von der Source oder Destination mit der IP Adresse 198.18.20.1: <code> host </code>	
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"'''host''' 198.18.20.1"</span> 4 0 a
Erfassen des gesamten Datenverkehr von oder zu einem spezifischen Subnet. In diesem Beispiel mit dem Netz 198.18.20.0/24: <code> net </code>
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"'''net''' 198.18.20.0/24"</span> 4 0 a	
Erfassen von allem DNS Traffic vom Port 53 <code> port </code>
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"'''port''' 53"</span> 4 0 a	
Erfassen von allem ICMP Traffic <code> icmp </code>
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"'''icmp'''"</span> 4 0 a
oder
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"'''proto 1'''"</span> 4 0 a	
Dabei können auch verschiedene Parameter wie Source und Destinationen mit logischen Operationen verknüpft werden:

{| class="wikitable" style="width:500px"
|- style="background:#89E871"
| '''Vorrangige Bedeutung'''
| '''Operator'''
| '''Symbol'''
|- 
|'''High'''
|NOT
|!
|-
|'''Medium'''
|AND
|&
|-
|'''Low'''
|OR
|<nowiki>|</nowiki>
|-
|}
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 <span style="background-color:#A9C5F9;">"host 85.251.22.54 '''and''' (icmp '''or''' port 80)"</span> 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 </code>:
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"src 198.18.20.1 '''and not''' port 22)"</span> 6 0 a 
Folgendermassen wird der Broadcast Traffic auf dem port1 mit Ausnahme von ARP gesnifft:
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"broadcast '''and not''' arp"</span> 6 0 a  
So wird der gesamten ARP Traffic an Trunk-Port1 mit VLAN-ID 10 gesnifft:
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"vlan 10 '''and''' arp"</span> 6 0 a  
Damit LACP-Frames aufgezeichnet werden können, muss EtherType (Hex) verwendet werden:
* <small>[https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml infos zu EtherType] </small>
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"ether proto 0x8809"</span> 6 0 a 
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>
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"tcp[<span style="color: #DA291C">'''13'''</span>] & <span style="color: #00B050">'''4'''</span> != 0"</span> 6 0 a 

    [[Datei:Fortinet-3349.jpg|550px|link=]]
Alternativ kann auch folgender Syntax verwendet werden:
     diagnose sniff packet any <span style="background-color:#A9C5F9;">"tcp[tcpflags] & tcp-rst == tcp-rst"</span> 6 0 a
Aufzeichnen von nur fragmentierten IPv4 Packeten:
* <small> Infos können hier entnommen werden: [https://datatracker.ietf.org/doc/html/rfc791#section-3.1 RFC 791 3.1]</small>
    diagnose sniffer packet any <span style="background-color:#A9C5F9;">"ip[<span style="color: #DA291C">'''6'''</span>] & <span style="color: #00B050">'''32'''</span> != 0 or ip[<span style="color: #FFC000">'''7'''</span>] != 0"</span> 6 0 a 

   [[Datei:Fortinet-3350.jpg|550px|link=]]

Die Flags bedeuten folgendes:
* Bit 0: Reserviert; muss Null sein
* Bit 1: Nicht Fragmentiert ('''D'''on't '''F'''ragment '''DF''')
* <span style="color: #00B050">Bit 2: Weitere Fragmente ('''M'''ore '''F'''ragment '''MF''')</span>

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
----
<small>add 13.03.2024 - 4Tinu</small>

=== Details zu der Option VERBOSE ===

<big>
      diagnose sniffer packet [interface] "[filter]" <span style="background-color:#B1F3FF;">[verbose]</span> [count][timestamp_format]
</big>

Aus der folgenden Tabelle kann entnommen werden wie ausführlich die Ausgabe ist, wenn der Verbose Wert angepasst wird:
{| class="wikitable" style="width:850px"
|- style="background:#89E871"
| '''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
|-
|}

{| class="wikitable" style="width:850px" 
|- 
| style="width:50px;background-color: #89e872;"| <span>[[File:hinweis.svg|50px|link=]]</span>
| style="background-color: #c4f3b8"|
* 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' <span style="background-color:#B1F3FF;">'''4'''</span> 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' <span style="background-color:#B1F3FF;">'''6'''</span> 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
----
<small>add 13.03.2024 - 4Tinu</small>

===Details zu der Option COUNT===

<big>
      diagnose sniffer packet [interface] "[filter]"[verbose] <span style="background-color:#E5DDFE;">'''[count]'''</span> [timestamp_format]
</big>

Der Count Parameter definiert, wieviele Pakette geangezeigt werden.

Wenn kein Wert oder der Count Wert auf Null (<span>count 0</span>) gesetzt wird, läuft der Sniffer unendlich weiter, bis dieser mit <code><CTRL+C></code> gestoppt wird.

{| class="wikitable" style="width:850px" 
|- 
| style="width:50px;background-color: #276ef1;"| <span>[[File:info.svg|50px|link=]]</span>
| style="background-color: #A9C5F9"|
'''Tipp:''' Für weitere Untersuchungen ist es immer eine gute Idee, die SSH-Ausgabe in eine Datei zu protokollieren.<br> 
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.

<small>weitere Infos in diesem [[FortiGate:FAQ#Wie_kann_ich_im_Putty_den_Output_in_eine_Textdatei_schreiben_lassen?|Wikiartikel]]
|}
----
<small>add 14.03.2024 - 4Tinu</small>

===Details zu der Option TIMESTAMP_FORMAT===
<big>
      diagnose sniffer packet [interface] "[filter]"[verbose] [count] <span style="background-color:#F695BE;">[timestamp_format]</span>
</big>

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
----
<small>add 14.03.2024 - 4Tinu</small>

==Wie kann ich das Sniffen abbrechen?==

Mit der Tastenkombination <code> CTRL und C </code> 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 <code>diagnose sniffer packet</code>
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 <code>diagnose sniffer packet</code> speziell mit der Option "full capture" 
ausgeführt wird, z. B. <code>diagnose sniffer packet any 6 0 l</code>, 
kann es bei hohem Traffic auf der FortiGate nach Beendigung des Befehls zu folgender Ausgabe kommen:
    604617 packets received by filter
    <span style="color: #DA291C">'''480271''' packets dropped by kernel</span>
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: [[FortiGate:Diagnose-Sniffer-Guide#Details_zu_der_Option_VERBOSE|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: [[FortiGate:Diagnose-Sniffer-Guide#Details_zu_der_Option_FILTER|Details zu der Option FILTER]]
* Eine weitere Möglichkeit ist die Verwendung der "Capture" -Funktion anstelle des Befehls <code>diagnose sniffer packet</code>, 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
    <span style="color: #00B050">'''0''' packets dropped by kernel</span>
----
<small>add 13.03.2024 - 4Tinu</small>
<!--Referenz KB: https://community.fortinet.com/t5/FortiAnalyzer/Troubleshooting-Tip-Packet-capture-CLI-sniffer-tips-and-best/ta-p/196143?externalID=11655 -->

= 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:
{| class="wikitable" style="width:850px"
|- style="background:#89E871"
| [[file:config_cli.png|25px|link=]] '''Konfiguration über die CLI:''' 
|- 
| 
 # diagnose sniffer packet ppp0
{| class="wikitable" style="width:800px" 
|- 
| style="width:50px;background-color: #276ef1;"| <span>[[File:info.svg|50px|link=]]</span>
| style="background-color: #A9C5F9"|    
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:
{| class="wikitable" style="width:850px"
|- style="background:#89E871"
| [[file:config_cli.png|25px|link=]] '''Konfiguration über die CLI:''' 
|- 
| 
 # diagnose sniffer packet any 1 0 '''a'''
{| class="wikitable" style="width:800px" 
|- 
| style="width:50px;background-color: #276ef1;"| <span>[[File:info.svg|50px|link=]]</span>
| style="background-color: #A9C5F9"|        
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:
{| class="wikitable" style="width:850px"
|- style="background:#89E871"
| [[file:config_cli.png|25px|link=]] '''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:
{| class="wikitable" style="width:80%"
|- style="background:#89E871"
| [[file:config_cli.png|25px|link=]] '''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 Pakete 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 Paket" 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 Paket 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" Paket
           2) Der "recipient" sendet dem "caller" als Antwort "SYN, ACK" Pakete
           3) Als Bestätigung sendet der "caller" ein "ACK" Paket
       
       In unserem Beispiel möchten wir nur "SYN" Pakete Filter (1). Pakete 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" Paket. Wenn nun ein initial DatenPaket ü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 Paket"
       
           '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 DatenPaket mit SYN gefilter werden dh. wenn
       ein DatenPaket 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 Paket" Filter abgebildet werden:
       
           'tcp[13]&2==2'
       
       Daraus ergeben sich zB folgende Filter Möglichkeiten:
       
           'tcp[13]==1'       Nur Pakete mit FIN bit auf Wert 1
           'tcp[13]&4==4'     Alle Paket mit RST bit Wert 1
           'tcp[13]&8==8'     Alle Paket mit PSH bit Wert 1
           'tcp[13]==16'      Nur Pakete mit ACK bit auf Wert 1
           'tcp[13]&32==32'   Alle Paket mit URG bit Wert 1
           'tcp[13]&64==64'   Alle Paket mit ECE bit Wert 1
           'tcp[13]&128==128' Alle Paket mit CWR bit Wert 1
           'tcp[13]==24'      Nur Pakete mit PSH und ACK bit auf Wert 
----
<small>edit 30.4.2024 - 4Tinu</small>