1 Stimme

Honeypot Ports für IPS

Mein Wunsch wären "Honeypot" Ports im IDS, sodass man schon viele ungebetene Gäste los wird.

Der Gedanke wäre, dass ich nicht genutzte Ports auf den globalen IPs (oder der Internet Schnittstelle) als "honeypot" eintragen kann, und so ein Zugriff auf diesen Port eine Sperrung auslöst.
Ideal wäre das, wenn man dies mit den Interface Objekten kombinieren könnte, oder überhaupt als Rule in die Firewall übernehmen. (Also zu "ACCEPT" oder "DROP" auch noch "IPS Blocking")


Beispiel: Port 123 eth0 -> IPS blocking.

Dadurch wären 80% der Angriffe und Portscans erledigt.

  • Guest
  • Jun 9 2020
  • Gibt es schon
  • Attach files
  • Admin
    Produkt Manager commented
    14 Mar 13:33

    Dieses Feature geht in eine ähnliche Richtung, auch wenn Portscans nicht damit geblockt werden: https://wiki.securepoint.de/UTM/APP/Connection-Rate-Limit

  • Guest commented
    June 10, 2020 07:56

    Das Problem ist, das Sie Portscans nicht auf diese Weise blockieren koennen. Eher verraten Sie so die Honeypots, da Sie von Netzen gescannt werden.

    Eine andere Sache waere Geoblocking.

    Was die Alerting-Mails angeht: Sie koennen definieren, ob und wann die Mails gesendet werden.

  • Guest commented
    June 10, 2020 07:41

    Kurzfassung: Ja, Portscans sind in sich nichts schlimmes.
    Portscans zu blockieren ist aber eine gute Methode, sich Hacker weitegehnd vom Hals zu halten.

    Wenn ich einem Portscan zuschaue, der aus den Seychellen erfolgt, sollte die Firewall eigentlich eingreifen. - Entweder per Rules, oder per Automation.
    Die Automation reagiert nicht, die Rules kann ich nicht setzen.

    Derzeit werde ich nur von ALERT Messages einesteils zu gemüllt, die soundso kein ALERT sind, und auf der anderen Seite kann ich mir den Tag damit verschönern, in den Logs Hackern zuzusehen, ohne dass ich (präventiv) eingreifen kann. - Nicht unbedingt Sinn einer Firewall.

    Ich würde vorschlagen, die Diskussion evlt. auf das genannte Ticket zu verlegen...

  • Guest commented
    June 10, 2020 07:31

    Portscans sind erst einmal nichts "Schlimmes". Zudem werden die Ports im Normalfall von Netzwerken abgetastet, nicht nur von einzelnen Systemen. Das kann man im Log sehr gut beobachten. Jede IP zu sperren, die die "falschen" Ports abtastet, wird nichts bringen, außer das die Firewall hierfuer unnoetig Ressourcen aufwendet. Wenn der eine Block an IPs gesperrt ist, kommt der naechste. Die Liste in der Firewall wird immer groeßer, mehr auch nicht.

    Die Alerting-Meldungen sind in drei Varianten aufgeteilt:

    Input: Aufruf von Diensten der Firewall (Mailfilter z.B.)


    Output: Die Firewall baut eine Verbindung auf (Kann z.B. der Proxy sein, der dafuer verwendet wird)


    Forwarding: Eine Portfilterregel (Schließt auch Implizierte ein) ermoeglicht die Verbindung zu einer gefaehrlichen IP-Adresse.

    Waehrend INPUT im Normalfall im Alerting-Center auf die Warnstufe "Warning" zurueckgesetzt werden kann, wenn die Dienste der Firewall korrekt konfiguriert sind, sollten FORWARDING- und OUTPUT-Meldungen ernst genommen werden. Sie sind im Normalfall immer eine Alarmmeldung wert. Diese koennen auf einen Angriff oder eine Infektion eines Clients innerhalb des Netzwerks hindeuten.

  • Admin
    Produkt Manager commented
    June 10, 2020 07:12

    Vielen Dank!

    Das habe ich auch so verstanden.

    Der Threat Intelligence Filter ist eine komplexe Technologie auf Basis vieler Metadaten, die ständig weiter entwickelt wird. Aufgrund der komplexeren Erkennung werden nur echte Angriffe erkannt. Die Ideen einfache Portscans zu filtern haben wir evaluiert und unsere Security-Spezialisten haben sich dagegen entschieden. Alarme von diesem sollten sie ernst nehmen. Sie können natürlich die Alarmierung im Alerting Center ausschalten. Das hat keine Auswirkung auf die Funktion.

  • Guest commented
    June 10, 2020 06:56

    Das ist aber genau nicht das wovon ich geschrieben habe.
    Es ist nämlich genau der Punkt im Ticket 358944...

    Während Threat Intelligence Filter sinnlose ALERTs produziert (Default Einstellung IPS Blocking), gehen simple Angriffsvorbereitungen, wie z.B. Portscans unter. (Kein Blocking erfolgt)

    FAilToBan und fehlgeschlagene SSH Authentifizierungen sortieren bereits direkte Angriffe aus (Authentifizierung)

    Mein Vorschlag war aber, dass alleine der ZUGRIFF auf bestimmte Honeypot-Ports zu einer temporären Sperre führt.
    Ports, wie 23, 123 oder 139 sind sehr gute Indikatoren dafür, dass jemand mein System scannt.
    Eine Sperrung über IPS ist ein klares Signal an den Scanner, bzw. findet der Scanner keine Ports mehr, und so wird der Angriff schon in der Vorbereitung abgewehrt. (Der Angreifer erfährt in dem Fall nicht mal, dass da ein Webserver läuft, weil der Zugriff aufgrund des Honeypot Scans blockiert wird)

    Das war mein Vorschlag.

  • Admin
    Produkt Manager commented
    June 10, 2020 06:19

    Sorry - hier der Wiki Eintrag https://wiki.securepoint.de/UTM/APP/IDS-IPS

    Der Support hat ja nicht falsch geantwortet. Die Funktion, so wie Sie diese wünschen, gibt es ja nicht. Allerdings gibt es aus unserer Sicht eine bessere Funktion für Ihre Anforderung.

  • Guest commented
    June 10, 2020 05:57

    Interessant:

    Ich habe bei eurem Support angefragt, ob es diese Möglichkeit gibt. - Ihr Support verweist mich auf die Wunschbox, wo ich mittels Flag erfahre "gibt es schon".
    Mein neuer Wunsch:
    1. Support wieder in der Qualität, wie er vor ein paar Monaten war,
    2. "Gibt es schon" mit dem entsprechenden Link auf den Wiki Artikel, so erspare ich mir "Wunschbox/Support Pingpong".

  • Admin
    Produkt Manager commented
    June 10, 2020 05:38

    Mit dem Threat Intelligence Filter haben wir eine Leistungsstarke IPS Engine in unserer UTM. Diese fügt auf Basis von Verbindungsmetadaten automatisch Blocking-Regeln in das Regelwerk ein.