This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall-Härtung - Frage zu Filtern + Logging

Hallo zusammen,

eine bestehende UTM-Firewall (9.7) Umgebung, die aktuell zum größten Teil mit ANY-Regeln arbeitet, soll optimiert (gehärtet) werden.

Das Problem dabei: Einen Überblick über den Traffic zu bekommen, ist nahezu unmöglich, da via ANY Zentrale und ca. 20 Remote-Standorte über den SG-Cluster laufen, und das Live-Logging wie auch die manuellen Logs (allein für die Firewall ca. 1 GB pro Tag) sind schlicht erschlagend. Die meisten Anfragen sind die klassischen Webzugriffe via HTTPS, vereinzelt auch HTTP, von internen Netzen, Remote-Netzen, Gäste-Netz, WLAN aus - also quasi von überall Richtung Internet.

Meine Hoffnung war folgendes Vorgehen: jeweils die Regel zu klonen und vor die geklonte Policy zu stellen, dort als Service explizit HTTPS auszuwählen und dafür das Logging zu deaktivieren. Allerdings hat das leider nichts gebracht und das Logging für die darauffolgende ANY-Regel scheint immer noch zu greifen - das Log bleibt also unverändert sehr voll.

Hier dargestellt mal konkret als Beispiel:

VORHER

Paketfilter-Regel-3 - Zentrale 10.30.0.0/16 ANY Internet (Logging aktiviert)
Paketfilter-Regel-8 - Standort-A 192.168.33.0/24 ANY Internet (Logging aktiviert)

NACHHER

Paketfilter-Regel-2 - Zentrale 10.30.0.0/16 HTTPS Internet (Logging nicht aktiv)
Paketfilter-Regel-3 - Zentrale 10.30.0.0/16 ANY Internet (Logging aktiviert)
Paketfilter-Regel-7 - Standort-A 192.168.33.0/24 HTTPS Internet (Logging nicht aktiv)
Paketfilter-Regel-8 - Standort-A 192.168.33.0/24 ANY Internet (Logging aktiviert)

Ich würde für die bestehenden Regeln am liebsten eine "ANY minus X" Option für die Service-Definition verwenden, wo ich dann einen oder mehrere Dienste (wie HTTP / HTTPS) ausklammern könnte, denn ich kann die aktuell genutzten Ports / Services aufgrund der schieren Menge gar nicht alle effektiv sammeln und dann auch noch überall händisch anlegen. Sollte es eine Lösung konkret hierfür geben, würde immerhin schon mal das Log deutlich entschlankt werden und ich könnte dann für das gewünschte Firewall Hardening nach und nach die genutzen Services auslesen und entsprechend gezielt als Policy für die jeweiligen Netzsegmente erstellen.

Ansonsten würde mir für ein effizientes Härten der Firewall aktuell leider keine machbare oder brauchbare Option einfallen.

Kennt jemand diese Situation und kann mir vielleicht einen hilfreichen Tipp geben?

Gruß Daniel



This thread was automatically locked due to age.
Parents
  • Was soll denn die Auswertung der Gigabyte großen Logs bringen? Ernsthaft?

    Erkenntnisse über die benötigten Protokolle kann man schneller über eine Analyse der restlichen Infrastruktur gewinnen. Ich meine damit die benötigten und nicht die tatsächlich genutzten Ports und Protokolle!

    Ansonsten bringt eine solche Form der Härtung nämlich nichts.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • Na wenn es hier darum geht von ANY auf "sinnvolle" Rules umzustellen ist der Ansatz doch nicht verkehrt.

    Für bekannte/erkannte/gewollte Traffic werden "oben" Regeln geschrieben, welche nicht loggen. Übrig bleibt, was man nicht auf dem Schirm hat oder gar nicht möchte.
    Ich habe oft den Fall, dass der Admin nur einen Teil der Traffic vorher kennt.

    @ddiez: wenn eine Rule matcht (und diese nicht loggt), sollte keine weitere mehr aufgerufen werden. Vergleiche mal die Rule-ID. Ich denke die vorgelagerte Rule hat einen Fehler und matcht nicht. Evtl. die Vorgelagerte Rule mal hier zeigen.
    Ein häufiger Fehler ist, dass eine Interface(adresse) und kein Netz verwendet wird.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Genau das war der erhoffte Effekt. Aktuell sieht das dort so aus, hier zwei der Regeln.

    Leider lassen sich hier keine Screenshots anhängen, das wäre deutlich einfacher!

    So stehen diese in der Übersicht in der Firewall-Liste, der einzige Unterschied in der jeweiligen Konfiguratoin ist, dass in Nr. 16 der Haken bei "Verkehr protokollieren" nicht gesetzt ist:

    16    SURF (Network)    HTTPS    Internet IPv4    SURF_Internet_HTTPS_No_Logging
    17    SURF (Network)    Any        Internet IPv4    SURF to Internet

    Entspricht die Nummer der Firewall-Policy nicht automatisch der Rule-ID bei der Sophos? Falls ja, wo und wie könnte ich die dann irgendwo auslesen? Hab dazu gerade mal online gar nicht so wirklich was finden können. Im Network-Protection-Log wird ja auch nur auf diese Nummern verwiesen, die hier in der GUI angezeigt werden.

  • Zum Anhängen von Screenshots diese als Bild speichern und Bild anhängen.

    Ja, bei der SG ist die Listennummer auch die Rule-ID.

    Steht im Log, dass Rule 17 matcht ... wenn geloggt wird?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Argh, jetzt noch mal geschaut und auch die (etwas versteckte) Funktion zum Upload von Dateien hier entdeckt, hatte mich schon etwas gewundert. Danke.

    Ja, genau, im FW-Log wird bei all diesen geklonten Regel-Pärchen immer nur die Nummer der originalen Policy mit ANY + Logging angezeigt - als gäbe es die neuen vorgeschalteten Regeln davor überhaupt nicht.

Reply
  • Argh, jetzt noch mal geschaut und auch die (etwas versteckte) Funktion zum Upload von Dateien hier entdeckt, hatte mich schon etwas gewundert. Danke.

    Ja, genau, im FW-Log wird bei all diesen geklonten Regel-Pärchen immer nur die Nummer der originalen Policy mit ANY + Logging angezeigt - als gäbe es die neuen vorgeschalteten Regeln davor überhaupt nicht.

Children
  • Dann sollten wir uns genau die vorgeschaltete Regel genauer ansehen.
    Ein Screenshot macht es einfacher.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Ich kann da absolut nichts Auffälliges oder Falsches entdecken.

    Es ist allerdings tatäschlich jedes Mal bei allen FW-Policies (bestehende wie neue) das jeweilige Interface verwendet.
    In der ersten Antwort hattest Du das als häufigen Fehler bei dieser Nutzung erwähnt. Könnte das die Ursache hier sein, und falls ja, warum ist das so? (Die bestehenden Firewall-Regeln sind ja schließlich auch funktional damit am Laufen!)

      

  • Der "typische" Fehler wäre, bei der Definition steht "Surf(Address)". Ist hier aber nicht.
    Noch mal die Frage ... matcht wirklich die Rule 17 ... oder evtl. eine spätere?
    Befinden sich die Clients wirklich im Subnetz, welches an das Interface "SURF" gebunden ist, oder ist evtl. noch ein weiterer Routing-Hop in dem Netz vorhanden.

    Bei der SG bedeutet diese Definition NICHT: "Alles was über dieses Interface reinkommt" ... sondern tatsächlich muss die Client-IP dem angegebenen Interface-Subnetz entsprechen.
    Bitte einen Screenshot der Interface-Definition und der Zeile aus dem Logging.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Ich habe jetzt noch mal ein anderes Netz genommen, da dort deutlich mehr im Logging auftaucht. Die Screnshots noch mal vollständig hier, vom Prinzip aber genau die gleiche Grundkonfiguration:

       

  • Soweit sieht das ja erst einmal stimmit aus, da es keine direkten Überschneidungen gibt und das Ganze analog zu den Regeln dort im Log auftaucht ... Und jetzt gerade ist mir erst beim wiederholten Blick darauf aufgefallen, dass hier gar nicht TCP verwendet wird, ich hatte mich bisher nur auf den Port konzentriert. Damit also UDP-443, was in HTTPS ja gar nicht gesprochen wird. Kurz online geschaut, es handelt sich dabei um QUIC - und das wird dort offenbar in den verschiedenen Regeln gar nicht zu knapp verwendet. Damit kann ich nun wohl doch erst einmal dort weiterschauen, aber auf jeden Fall schon mal vielen Dank für die schnelle Reaktion und den bisherigen Input!

    Daniel

  • UDP 443 wird meist verwendet um "performanter" surfen zu können und gleichzeitig die Firewall bei DNS, WebFilter usw zu umgehen oder um ein VPN damit zu realisieren.

    Wir haben es nahezu immer verboten und für nötige Gegenstellen eine Ausnahmeregel eingerichtet.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Zum Thema QUIC:

    QUIC wird die Zukunft des HTTPS (und ist am Ende nichts anderes, nur nicht statusbehaftet und deshalb viel schneller) und so gut wie alle Big Player wie Microsoft, Google… nutzen dies bereits.

    Kann man zwar ganz gut per GPO bei den Browsern ausschalten aber Microsoft nutzt QUIC z.B. auch bei 365, Updates und Co. Ganz raus bekommt man es also nicht.

    Die XGS hat immerhin eine Proxy-Option QUIC autom. rauszufiltern. Ist vermutlich auch nur eine Frage der Zeit bis QUIC auf Firewalls voll supportet wird (man wird es nicht ewig ignorieren können).

    Zum Thema ANY to Internet (sofern aktiv):

    Wäre ich (auf der UTM) vorsichtig, da hier der Proxy nur auf die bekannten HTTP(S) Ports schaut. Bis auf eine Hand voll, haben so gut wie alle Well-Known Ports in Richtung Internet nichts verloren. Ebenso die Dynamic Port Range.

    Auf der XGS schaut das schon anders aus, hier wird in alle Pakete geschaut (egal welcher Port). Da kann man auch die Registered Ports zulassen, wenn man keine Lust hat für jeden Web-Meeting Anbieter die Ports einzeln freizuschalten -> einer der deutlichen Verbesserung im Vergleich zur UTM.