Firewall-Härtung - Frage zu Filtern + Logging

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.

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.

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

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:

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

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

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.

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?

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