Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 26 replies
  • Subscribers 6 subscribers
  • Views 47789 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos UTM 9 Firewall Regel für Dropbox IP

Paul Brennecke

Hallo Leute,

ich habe jetzt schon länger gesucht und keine Lösung für mein Problem gefunden.

In dem Violations Log einer Firewall führen 2 Source IPs die zu Dropbox gehören. Diese versuchen über HTTPS lokale IPs über dynamische Ports zu erreichen.

Ich habe schon Any regeln für Allow und Deny probiert, ohne Erfolg. Mein nächster Gedanke wäre eine NAT Regel, ich wüsste aber nicht ob das dann noch klappt, weil ich dann ja einen anderen Port nehmen würde. Habe auch schon überlegt das ganze an die Sophos umzuleiten.

Hat jemand Erfahrungen mit ähnlichen Fällen?



This thread was automatically locked due to age.
  • 0 in reply to Jas Man

    Guten Morgen Jas,

    nur damit wir uns richtig verstehen:

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

  • 0 in reply to Paul Brennecke

    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.

  • 0 in reply to Jas Man

    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.
  • 0 in reply to Paul Brennecke

    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.

  • 0 in reply to Jas Man

    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

  • 0 in reply to Jas Man

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

     

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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

  • 0 in reply to Jas Man

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

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hallo Luca,

    beide Optionen sind bei mir nicht angestellt.

  • 0 in reply to Paul Brennecke

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

    __________________________________________________________________________________________________________________

Unfiltered HTML