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

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.

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.