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.

Als letzte Regel eine ANY - ANY Drop mit Log machen. Was keine Allow-Regel weiter oben (ohne Log) hat, taucht im Drop-Log auf (ob sinnvoll oder nicht kann man dann selbst entscheiden).

Mit Filtern und Notepad++ kann man sehr schnell den Müll rausfiltern. Alternativ eine zweite Drop-Regel vor der letzten erstellen (ohne Log), wo man die ganzen Services reinmacht, welche sonst den Log zumüllen würden.

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.

Diese ANY-ANY-Drop-Regel am Ende der Liste gibt es dort tatsächlich bereits.

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

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.