Sophos UTM 9 Firewall Regel für Dropbox IP

Hallo Paul,

Was möchtest Du denn erreichen? Die IP's sperren oder erlauben, das log sauberhalten?

Poste doch einmal die entsprechenden Zeilen im Log.

CS

Moin CS,

es geht mir in erster Linie darum eine Deny Regel für diesen Verkehr zu erstellen. Es bestehen in der Umgebung besondere Umstände, weswegen ich an den Clients nichts verändern kann. Mein Stand ist, das es sich bei dem Verkehr nur noch um Dienste handelt, die nach der Deinstallation von Dropbox übrig geblieben sind. (Wurde wohl deinstalliert weil mein Vorgänger es nicht geschafft hat, den Verkehr durch die Sophos zu bekommen und man sich dann nach einer Alternative umgeschaut hat)

Wäre jetzt mal ein Beispiel. Das ganze gibts noch mit einer anderen Source IP und auch mit anderen Destination Hosts. Über die Firewall habe ich schon die üblichen Regeln probiert, ohne Erfolg.

PS. Im Vordergrund steht hier für mich grade, was über die Sophos und zukünftige, ähnliche Fälle zu lernen. Sprich Antworten gerne im Detail warum und wieso man das Problem so und so lösen würde. :)

Hi Paul,

um den Verkehr zu blocken, muss Du ihn erst Mal über ein eindeutiges Merkmal identifizieren. Sind es z.b. immer dieselben externen IP Adressen die von aussen kommen, legst Du die in der UTM als Host oder Netz an, und baust Dir eine Regel

Src: DropBox IPs

Dst: LAN Network

Service: SSL (wenn es nur 443 ist, ansonsten erweitern)

Action: Drop

Der richtige Weg wäre aber eher die Dienste auf den Clients zu deinstallieren. Falls das nicht möglich ist solltest Du den ausgehenden DropBox Verkehr der Clients identifizieren, und diesen blocken. Das geht auch über die Firewall oder über die Application Control.

Gruß

Jas

Moin Jas,

was den ersten Teil deines Replys angeht, habe ich alles schon gemacht. Hab auch einen extra Service gebaut 443 -> x. (Sprich umgedreht wie die normale Definition, die Anfrage läuft ja aber auch anders rum) hat auch nichts gebracht.

Ich werde mir jetzt mal den letzten Teil anschauen. Ich seh mal ob ich da mehr Informationen bekommen kann. Den outgoing Traffic finde ich über den Web Filter nehme ich mal an?

Am liebsten würde ich auch an den Clients direkt arbeiten um das grade zu ziehen. Da blutet das ITler Herz schon ein wenig.

PS. Mit der Application Control habe ich noch keine Erfahrungen gesammelt, ich schaus mir aber danach nochmal an.

Hi,

da warst Du eigentlich auf dem richtigen Weg. Vermutlich war noch irgendwo ein Fehler in der Regel weshalb sie nicht gegriffen hat. In so einem Fall würde ich grober anfangen. Z.b. erst mal nur die externen IPs von Dropbox der Drop-Regel hinzufügen, und den Rest auf Any lassen. Wenn die Regel dann greift, den Dienst als nächstes hinzufügen usw.. Ziel sollte sein nirgendswo ein Any stehen zu haben, wobei das bei Drop-Regeln nicht ganz so kritisch ist wie bei Allow-Regeln.

Wenn Du den Proxy nutzt, dann musst Du wie vermutet im Web Filter Log nach den Verbindungen suchen. Ansonsten siehst Du ihn in der Firewall. Ggf. muss das Logging für die HTTPS Regel aktiviert werden, damit er geloggt wird.

Gruß

Jas

Hab jetzt

Dropbox IPs -> Any -> Any Drop - kein Erfolg

Internal -> Any -> Dropbox IPs Drop um überhaupt Anfragen zu blockieren - kein Erfolg

Dropbox in der Application Control geblockt - kein Erfolg

Ich bekomme immer die gleichen Source IPs über Port 443 in den Default Drops.

Habe nochmal mit dem Betreuer gesprochen. Auf den CLients wird Dropbox genutzt, es funktioniert auch alles. Dennoch möchte ich diese IPs entweder auf Allow haben oder Deny. Hauptsache, es stehen nur noch relevante Meldungen in meinem Log.

Hi,

hört sich wie mein Problem an (siehe Post oben), dass der Server im Internet versucht den Client im LAN zu erreichen, obwohl die Verbindung über den Proxy schon ausgelaufen ist. Ist nur eine Vermutung...aber würde Sinn ergeben.

Wenn die User Dropbox nutzen, kannst Du den Verkehr von innen natürlich nicht sperren. D.h. es bleibt nur das Sperren von außen.
Du musst irgendwo einen Fehler in der Regel haben.....

- Hast Du die Host Objekte für die externen IPs fest auf einen Adapter/Interface gebunden, oder stehen die auf ANY? Wenn Du einen Adapter ausgewählt hast, bist Du sicher das es der richtige ist?

- Ist die Regel auch aktiv / eingeschaltet?

- Ist die Regel vielleicht auf einen falschen Adapter gebunden?

Gruß

Jas

Jas Man said:

- Hast Du die Host Objekte für die externen IPs fest auf einen Adapter/Interface gebunden, oder stehen die auf ANY? Wenn Du einen Adapter ausgewählt hast, bist Du sicher das es der richtige ist?

- > steht auf any Interface

- Ist die Regel auch aktiv / eingeschaltet?

- > aktiv und auf Log traffic

- Ist die Regel vielleicht auf einen falschen Adapter gebunden?

- > Hatte da jetzt keine Möglichkeit ein Interface für die Regel auszuwählen

Ich krieg die nicht mal mit ner 3x A Regel gedroppt. Sprich landet bei Default Drop

Jas Man said:

- Hast Du die Host Objekte für die externen IPs fest auf einen Adapter/Interface gebunden, oder stehen die auf ANY? Wenn Du einen Adapter ausgewählt hast, bist Du sicher das es der richtige ist?

- > steht auf any Interface

- Ist die Regel auch aktiv / eingeschaltet?

- > aktiv und auf Log traffic

- Ist die Regel vielleicht auf einen falschen Adapter gebunden?

- > Hatte da jetzt keine Möglichkeit ein Interface für die Regel auszuwählen

Ich krieg die nicht mal mit ner 3x A Regel gedroppt. Sprich landet bei Default Drop

Mmhh, da fällt mir erst mal auch nix mehr ein. Ich könnte am WE mal versuchen meinen Verkehr von den externen Servern zu blocken. Vielleicht verhält es sich da gleich. Dann wüssten wir, dass es kein Konfigurationsfehler ist, sondern irgendwoher anders kommt.

Kannst Du mal die entsprechenden Zeilen aus dem Textlog der Firewall hier posten? Also nicht aus dem Monitor, sondern aus dem Berech "Log -> Firewall Log". Vielleicht enthält der noch ein paar mehr Infos.

Gruß

Jas

Guten Morgen Jas,

nur damit wir uns richtig verstehen:

du meinst von Logging & Reporting -> Network Protection -> Firewall?

Ich habe aktuell keinen Zugriff auf meine UTM, und kenne die Punkte daher nicht auswendig. "Logging & Reporting" ist aber schon mal korrekt. :)

Und da gibt es irgendwo die "Log Files" wo Du dir die reinen Textdateien der Logs anschauen kannst. Ganz hinten kannst Du auch über "Search Logfiles" in den Dateien suchen.

Hab gefunden was du meinst. Hier erstmal die Info:

2017:05:18-06:31:53 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:53 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:53 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:53 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:54 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:54 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:56 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:31:58 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 
2017:05:18-06:32:00 utm ulogd[20680]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:1a:8c:44:99:a8" srcip="162.125.32.5" dstip="192.168.100.71" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="56638" tcpflags="RST" 

Da ich den Bereich bis jetzt immer übersehen habe werde ich mich auch mal dran machen und das ganze auswerten. 

Wieder was gelernt :-)

Wo ich den Log sehe, erinnere ich mich auch wieder etwas genauer an mein Problem. Also es ist wirklich so das wir das gleiche Problem haben, nur mit unterschiedlichen Servern/Services.

Ganz am Ende des Logs siehst Du immer das Feld

tcpflags="RST"

RST bedeutet, dass es sich rein um TCP Reset-Pakete handelt. Sprich der Server versucht die Verbindung zu beenden bzw. blockt Verbindungsanfragen. Die UTM handelt richtig, da es sich um keine bestehende Verbindung handelt. Was die Ursache für dieses "Problem" ist habe ich nie rausgefunden. Auch bei mir stehen die entsprechenden Server immer ganz oben bei den "Top blocked hosts". Ich könnte aber mal ausprobieren die Pakete per Regel ohne Logging zu blocken, so wie Du es auch wünschst.

Habe grade ähnliche Infos rausbekommen. Das schlimmste daran ist, das es sich insgesamt um einen Bug handeln soll und diese Pakete einem ständig die Firewall zu müllen werden. So wies aussieht werde ich solche und ähnliche Fälle ignorieren müssen.

Du kannst dir nicht vorstellen wie mich sowas triggert. :D

Hallo,

dies ist soweit korrekt.

Um das mal weiter auszuführen.

Wir arbeiten hier mit einer Stateful Firewall. https://en.wikipedia.org/wiki/Stateful_firewall

Bedeutet effektiv, die Appliance merkt sich die Verbindung. 

Nun sind diese "RST" Pakete von Webserver zum Client (erkennbar auch an der HighPort - Low Port Kommunikation). 

Das interessante nun ist die Zeit: Wann kommt dieses RST Paket? 

Auf einer gut verwendeten Appliance sieht man diese RST Pakete ständig - Aber die Verbindung dazu existiert nicht mehr (Ist also schon beendet vom Client). 

Nun kommt aber der Webserver auf die Idee nach 10 - X Minuten seine Verbindungen sich anzuschauen und die Timeout Verbindungen zu Reseten. Also sendet er RST Pakete an diese Clients raus. Das kommt zur Appliance. Dadurch, dass die Verbindung aufgrund eines Timeouts schon abgelaufen ist, dropped die Appliance das mit Default Drop. 

Zusammengefasst: Diese RST Pakete sind von abgelaufenen Verbindungen und nicht mehr relevant. 

Gruß. 

Hi Luca,

danke für die super Erklärung. Das "Keeping Alive" Pakete RST Flags verwenden, wusste ich noch nicht.

Die eigentliche Frage ist aber noch offen. Hast Du ne Idee warum Paul das nicht per Regel aus den Logs filtern kann, so das es in der Statistik nicht mehr auftaucht? Mich nervt das dauch, weil immer diese Server ganz oben stehen, und somit andere Server als "nicht so schlimm" erscheinen.

Gruß

Jas

Keep Alive ist hier nicht korrekt. Dies sind einfach veraltete Verbindungen.

Wie ist die Konfiguration hier bei: Network Protection > Firewall > Advanced

Hier existieren 2 Dinge:

Block invalid packets: If enabled, the firewall will check the data packets for conntrack entries. The conntrack entries will be generated by sending connection initializing packets, for example, TCP SYN or ICMP echo requests. If someone tries to send a packet which does not match to an existing connection, for example, TCP ACK or ICMP echo reply and the UTM cannot find a matching TCP SYN or ICMP echo request via the conntrack entry the data packet is invalid and will be dropped. A record will be written to the firewall log.

Log invalid packets: The UTM will log all invalid packets. If Block invalid packets is enabled the log records are marked by the string "INVALID_PKT".

Hallo Luca,

beide Optionen sind bei mir nicht angestellt.