Firewall-Härtung - Frage zu Filtern + Logging

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.

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.

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?

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.

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

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!)

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.

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.

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.