Snort, Portscans und gescanntes IP-Bereichsfeld

Question

Laut manual.snort.org werden TCP-Portscans von einem Computer zum anderen übertragen, aber wenn Sie sich eine TCP-Portscan-Warnung in Snort/Snorby ansehen, können Sie Folgendes sehen:

In einer Hand: Quelle: 136.238.4.165 Ziel: 10.19.0.5

Auf der anderen Seite: Priority.Count:.5.Connection.Count:.18.IP.Count:.1.IP-Bereich des Scanners: 10.10.28.88:136.238.78.44.Port/Proto.Anzahl:.6.Port/Proto.Bereich:.199:58891.

Auf der einen Seite haben wir also die Quell- und Zielfelder, die besagen, dass die Maschine 10.19.0.5 von 136.238.4.165 aus gescannt wurde. Auf der anderen Seite sagt der Scanner-IP-Bereich, dass von 10.10.28.88 bis 136.238.78.44 bis 10.19.0.5 gescannt wurde.

Wie soll ich diese Information verstehen? Welches Gerät hat den Scan gestartet?

Answer 1

Ich glaube, Sie versteifen sich zu sehr auf die TCP-Verbindungsterminologie und deren Zusammenhang mit dem, was Snort unter Quelle und Ziel versteht.

Obwohl Snort einige Statusinformationen für die Stateful Inspection (sogenannte Flowbits) speichern kann, werden die Signaturen anhand einzelner Pakete verarbeitet. Dies bedeutet, dass Quelle und Ziel nicht Client und Server zugeordnet werden, sondern direkt den Quell- und Zieladressfeldern im IP-Header. Das bedeutet, dass das spezifische Paket, das diese Regel ausgelöst hat, 10.19.0.5 im Zieladressfeld und 136.238.4.165 im Quelladressfeld hatte. Wir sprechen hier von einem einzelnen Paket, es hat nichts damit zu tun, wer die Sitzung initiiert hat.

Bedenken Sie auch, wie der Präprozessor sfPortscan funktioniert. Sein Erkennungsalgorithmus prüft eigentlich nur anhand von 3 Mustern:

1. TCP/UDP-Verkehr, bei dem ein Host mit einem Host kommuniziert und viele Ports erreicht
2. TCP/UDP-Verkehr, bei dem viele Hosts mit einem Host kommunizieren und viele Ports erreichen
3. TCP/UDP/ICMP-Verkehr, bei dem ein Host über einen einzigen Port mit mehreren Hosts kommuniziert

Hauptsächlich wegen Punkt 3 kann dieser Alarm von praktisch jedem System ausgelöst werden, das tatsächlich einen Dienst bereitstellt. Aus irgendeinem Grund scheinen Windows SMB-Dateiserver die schlimmsten Übeltäter bei Fehlalarmen zu sein. Dies macht den sfPortscan-Präprozessor außergewöhnlich laut. Tatsächlich so laut, dass es sich fast nicht lohnt, diesen Präprozessor zu aktivieren, es sei denn, Sie haben ein stark eingeschränktes Netzwerk und das Fachwissen, um die Ausgabe erheblich zu optimieren.