Was können wir mit den "unbekannten" Anträgen machen?

Was ist das unbekannte-TCP oder unbekanntes-UDP, das manchmal in Verkehrs Protokollen auftaucht? In Bezug auf die APP-ID handelt es sich dabei um Verbindungen, bei denen nicht genügend Daten oder Daten, die nicht mit dem Verhalten der bekannten Anwendungen übereinstimmen, übertragen wurden und APP-ID nicht in der Lage war, eine bekannte Anwendung zu identifizieren. Wenn diese Art der Anwendung innerhalb der Organisation gesehen wird, gibt es eine gute chance, das ist gutartig Verkehr: vielleicht ein Homebrew-Backup oder eine skriptbasierte Wartungsaufgabe. Wenn diese sich auf Sitzungen ausgehen, oder kommen aus dem Internet auftauchen, sollten sie einen Grund zur Sorge sein.

Als Faustregel gilt: Best Practice ist es, alle unbekannten-UDP/Unknown-TCP zu blockieren, da man sich nicht sicher ist, welche Art von Sessions diese sind und Sie böswillig sein könnten.

Es kann jedoch ein wenig drastisch sein, jeden unbekannten Verkehr blind zu blockieren, da ein Teil davon legitim sein kann und für operative Zwecke erforderlich sein kann. Die beste Lösung besteht darin, den Datenverkehr zu identifizieren, indem kundenspezifische Anwendungen erstellt werden, so dass Sicherheitsrichtlinien erstellt werden können, um besser zu kontrollieren, welche Ströme erlaubt sind und welche blockiert werden sollten.

Der schnellste Weg, dies zu tun, ist, eine einfache benutzerdefinierte Anwendung zu erstellen und eine APP-über Überschreitung zu setzen. Dies ist hilfreich, wenn die Quelle und das Ziel intern und statisch sind, wie eine scripted-Verbindung von einem Server zum nächsten innerhalb einer kontrollierten Umgebung:

1. Erstellen Sie eine vereinfachte benutzerdefinierte Anwendung ohne erweiterte Attribute oder Signaturen.
   
   Ich habe den Risikofaktor auf 5 gesetzt, weil diese Methode ohne weitere Prüfung ein AppID auf Sitzungen anwendet.
   
   
2. Creat eine Anwendung übertreibt Richtlinien, um den beabsichtigten Fluss genau zu entsprechen (Application override sollte nur verwendet werden, um Ströme zu identifizieren, die dem Administrator bekannt sind).
   
3. Die Sitzungen werden nun identifiziert, da die benutzerdefinierte Anwendungs-und Sicherheitsrichtlinien erstellt werden können, um die Sitzung auf der Grundlage der Anwendung zu kontrollieren.
   

Der beste Weg, die Anwendung zu identifizieren, ist, eine packetcapture einzurichten, um ein gutes Verständnis dafür zu gewinnen, wie die Anwendung auf die Firewall aussieht, und dann eine Signatur zu erstellen, die den erwarteten Inhalten entspricht. Auf diese Weise können Sie absolut sicherstellen, dass die Sitzung legitim ist.

1. Stellen Sie die Paket Erfassung ein und sammeln Sie die pcap-Dateien, nachdem Sie eine vollständige Sitzung gesammelt haben. Weitere Informationen zu den Paketaufnahmen finden Sie in seinem Artikel: Start: Paket Erfassung
   
2. Analysieren Sie die Paket Aufnahme für eine entsprechende Signatur.
   
   
   Für das folgende Beispiel werde ich den Hex-Wert von "2f69 6E66 6f3f 7478 7441 6972 506c 6179 2674 7874 5241 4f50" verwenden, der das Klartext-Äquivalent von "/Info? Txtairplay & Txtraop" in meiner packetcapture ist.
   
   
3. Erstellen Sie eine neue benutzerdefinierte Anwendung, die den Parametern der Sitzung entspricht, die Sie identifizieren werden: in meinem Beispiel habe ich ein individuelles AirPlay-Protokoll erfasst, das ich einem Risikofaktor von 1 zugeordnet habe, da es innerhalb der Organisation als sicher gilt.
   
   
   
   Es wird TCP-Port 7000 als Zielport vom Client zum Server verwenden.
   
   
   In der Signatur können Sie den Hex-Wert aus dem pcap verwenden, wie in diesem Beispiel zu sehen ist: (für Hex-Muster, vergewissern Sie sich, dass Sie ein führendes und Trailing ' \x ' hinzufügen, damitder Motor weiß, dass er dem Hex entsprechen muss und nicht für übersetzte cleartext)
   
   
   oder einen Regex-String, wie in t gesehen sein Beispiel: (für Strings von ClearText, vergewissern Sie sich, dass Sie alle Sonderzeichen mit einem vorwärts-Schrägstrich ' \ ' kommentieren, um anzuzeigen, dass dies eine wörtliche Übereinstimmung mit dem Zeichen ist, sonst könnte es als Wildcard identifiziert werden).
   Um den Standort der Zeichenkette weiter zu begrenzen, habe ich einen Qualifikant für HTTP-Methode GET gesetzt, da hier die Zeichenkette im Gegensatz zu weiter im Körper gefunden werden sollte. Der Kontext für diese Signatur ist der HTTP-Request-Parameter, da das benutzerdefinierte AirPlay-Protokoll HTTP-Befehle verwendet, um mit dem Server zu kommunizieren, muss die Kontext Option auf das entsprechende Protokoll gesetzt werden, falls dies in der Kommunikation zwischen Client und Server.
   
   Weitere Beispiele finden Sie im Video- Tutorial: kundenspezifische Anwendung und Einstieg : kundenspezifische Anwendungen und App-override . Zu den gängigen Kontexten gehören ' unknown-req-TCP-Nutzlast ', ' unknown-RSP-TCP-Nutzlast ', ' http-req-Host-Headers ' und einige andere, bei denen-req-für Client-Anfragen steht und-RSP-Server-Antworten sind, die es Ihnen ermöglichen, zu wählen, welche Seite Sie abfangen und identifizieren möchten.
   
   
4. Nachdem die benutzerdefinierte Anwendung erstellt und die Konfiguration zugesagt wurde, sollten die unbekannten-TCP-Sessions durch die neue benutzerdefinierte Anwendung in den Protokollen ersetzt werden:
5. Das bedeutet, dass die Sicherheitspolitik nun geschaffen werden kann, um mehr Kontrolle über diese spezielle Anwendung zu haben, so dass Sie unbekannten Verkehr blockieren können, ohne die geschäftskritischen Anwendungen zu stören:
   

Ich hoffe, Sie fanden diesen Artikel informativ, lassen Sie sich gerne einen Kommentar hinterlassen.

Schnitter

Weitere Ideen und Beispiele zu kundenspezifischen Anwendungen finden Sie in der Palo Alto Networks Custom Signature Diskussions Tafel .

Siehe auch--

Getting Started: Paketerfassung

Video-Tutorial: individuelle Anwendung

Getting Started: Benutzerdefinierte Anwendungen und app-Überschreibung