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. :)

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".

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.

Hallo,

ich kann es leider aktuell nicht testen, da die RST Pakete von der äußersten Firewall blockiert werden.. 

Aber es gibt mehrere Möglichkeiten.

Testen der beiden Option wie hier angegeben. 

Firewall Rule ganz unten SRCPort: High - DSTPort: Low Range - Drop und Logging deaktivieren.

Etc. 

Gruß. 

N'abend.

Ich habe soeben auch probiert die Pakete per Firewall Regel zu droppen, aber es klappt wirklich nicht.

Grund hierfür ist, dass die Pakete durch die Input Chain durchgelassen, und erst von der Output Chain Regel 60003 gedroppt werden. Das Paket wird also erst zum LAN Interface der UTM geblockt. Die Regeln, die wir über die WebGUI anlegen können, greifen aber schon vorher in der Input Chain. Somit muss es irgendeine höhere Regel geben die die RST Pakete durchlässt. Aus meiner Sicht besteht daher keine Möglichkeit die Pakete aus dem Log zu bekommen.

Jas

Wenn ich meine Firewalls so durchchecke, habe ich bei vielen externe IPs in den Top Source Hosts mit mehr oder weniger vielen Paketen. Ich gehe mal davon aus das es sich dabei zu 90% auch um toten Traffic handelt. Wäre echt schön zu wissen wie man sowas aus den Logs bekommt.

Ich habe auch bemerkt das es anscheinend mehr Server werden. Ganz oben steht jetzt der Exchange Active Sync Server der Firma, mit dem sich mein Handy synct.

Wenn ich den transparenten Proxy deaktiviere, sind die "dropped RSTs" sofort weg. Es hängt also mit dem Proxy zusammen. Nutzt Du den transparenten oder den normalen Proxy?

Als Workaround könnte man die betroffenen Server als Ausnahme für den transparenten Proxy unter "Web Protection" -> "Filtering Options" -> "Misc" einfügen. Für den normalen Proxy müssten diese Ausnahmen in die Proxy Konfigurationsdatei geschrieben werden. Aber wer will schon die ganzen Server da einpflegen.

Wenn trotz Proxy auf der Firewall Einträge erscheinen ist irgendwas faul oder über eine Ausnahme (Skiplist oder wpad.dat) eben dies gewünscht, bei Nichtverwendung der wpad.dat bliebe auch noch falsche Config am Client bei dediziertem Proxy.

Sprichst Du Euren Exchange über Split-DNS mit seiner internen IP an oder versucht das Handy, sich auf die externe IP zu verbinden?

Das Handy geht auf die externe IP Adresse. Die UTM steht bei mir zu Hause.

Das die Pakete trotz Proxy an der Firewall aufschlagen liegt einfach daran, dass der Proxy die Verbindung nicht (mehr) kennt und somit ist es für die UTM eine unbekannte Verbindung, die durch die Firewall gedroppt wird. Das passt schon so, alles korrekt.

Nur das ich die Pakete nicht blocken kann weil sie schon die Input-Chain durchlaufen haben ist komisch. Anscheinend werden TCP Pakete mit RST Flag anders behandelt. Oder wir haben irgendeine Funktion aktiviert/deaktiviert, die das Verhalten steuert. Aber ich hab schon alle relevanten Häkchen gesetzt bzw. nicht gesetzt die meiner Meinung was damit zu tun haben könnten. Jedoch ohne Erfolg.

Gruß

Jas

Jas Man said:

Als Workaround könnte man die betroffenen Server als Ausnahme für den transparenten Proxy unter "Web Protection" -> "Filtering Options" -> "Misc" einfügen. Für den normalen Proxy müssten diese Ausnahmen in die Proxy Konfigurationsdatei geschrieben werden. Aber wer will schon die ganzen Server da einpflegen.

Nach ewigem getüfftel und der Tatsache das ich diese Antwort erst nur überflogen habe hat mir das geholfen. Die Pakete tauchen in den Logs nicht mehr auf. Jetzt muss ich nur ne Definition für die "Leichen" machen.