Hoher ausgehender DSL Traffic

@predator

Ich weiß jetzt nicht genau wie kooperativ dein Provider bzw. Provider im Allgemeinen bei so einem Problem sind, aber vielleicht ist dein Provider ja so nennt und blockiert NTP-Verbindungen in Richtung deine(s)/deiner externen Interfaces bereits intern.

Eine entsprechende Anfrage würde ja nichts kosten,
ist vielleicht einen Versuch wert!?

Leider ist das Problem damit natürlich nicht aus der Welt,
aber zumindest dann nicht mehr auf deiner Firewall [:D]!

Gruß, Datax

@predator  Ich weiß jetzt nicht genau wie kooperativ dein Provider bzw. Provider im Allgemeinen bei so einem Problem sind, aber vielleicht ist dein Provider ja so nennt und blockiert NTP-Verbindungen in Richtung deine(s)/deiner externen Interfaces bereits intern.  Eine entsprechende Anfrage würde ja nichts kosten, ist vielleicht einen Versuch wert!?  Leider ist das Problem damit natürlich nicht aus der Welt, aber zumindest dann nicht mehr auf deiner Firewall [:D]!  Gruß, Datax

Hallo Datax, das ist eine gute Idee. Werde morgen mal bei QSC anfragen :-)

Gruß Martin

Hi Predator

Das Problem mit den grossen Firewall Logs hatte ich gelegentlich schon gesehen. Das Problem ist ja, dass die UTM per default alle verworfenen Pakete loggt (obwohl diese von extern in 99% uninteressant sind, ausser man ist grad am debuggen/troubleshooten). Ich nutze dafür seit Jahren einen einfachen Trick. Du erstellst im Firewall folgende zwei Rules als letzte Regeln:

Zweitletzte Regel
Source [Alle Deinen internen Netze] - Service "ANY" - Destination "ANY"
Aktion "REJECT" und "LOG"

Letzte Regel
Source "ANY" - Service "ANY" - Destination "ANY"
Aktion "DROP" und "NOLOG" (Logging Haken raus)

Diese Rules haben drei nette Eigenschaften:
1. Pakete von intern nach irgendwohin ohne passende Regel werden rejected. ==> Kein Timeout auf betroffenen Applikationen, und die Rejects tauchen im Live Log gelb auf. Damit siehst DU schnell, dass da was von intern verworfen wurde, und findest auch schnell den einen oder anderen Service, den man ggf. noch öffnen könnte (Klassiker sind NTP und DNS Server)

2. Ankommende Pakete von extern ohne passende Regel werden gedroppt - im Gegensatz zur Default Rule aber OHNE Logeintrag. 

3. Das FIrewall Log wird dadurch normalerweise um Faktoren kleiner

Die einzigen Drops bei denen Du die Logeinträge damit nicht wegkriegst sind die Drops mit den 60000er ID's...das sind die Drops der Portscan Detection, IDS/IPS, Applikationskontrolle etc.

[:D]

/Sascha

  Hallo Datax, das ist eine gute Idee. Werde morgen mal bei QSC anfragen :-)  Gruß Martin

Filter und Firewall-Dienste sind nicht im Vertrag enthalten. 
Dann werd ich mal den Tipp von Sascha testen. Gestern 23 Millionen geblockte Pakete. Cpu 25,6 im Schnitt.
Firmware ist übrigens die aktuelle 9.109-1, nicht die aus meiner Signatur ;-)

Sent from my iPhone using Astaro.org

Filter und Firewall-Dienste sind nicht im Vertrag enthalten. 
Dann werd ich mal den Tipp von Sascha testen. Gestern 23 Millionen geblockte Pakete. Cpu 25,6 im Schnitt.
Firmware ist übrigens die aktuelle 9.109-1, nicht die aus meiner Signatur ;-)

Sent from my iPhone using Astaro.org

Hi Martin

Die NTP Anfragen nehmen mit der Zeit schon ab, wenn die bösen Jungs mal merken, dass der NTP nicht mehr auf ist. Ich tippe mal darauf, dass die Anfragen via BOT's kommen, und mit UDP daherkommen, was einfach zu spoofen ist (hiesse die Anfragen kommen von hunderten verschiedener IP Adressen). Die bösen Jungs prüfen wohl nicht regelmässig, ob deren "Bombardierung" mit Paketen auch erfolgreich ankommt...ist ja normalerweise weder deren Rechenleistung noch Bandbreite die da verschwendet wird...

Falls die Anfragen von wenigen Source IP Adressen herkommen - insbesondere falls es TCP wäre, kanst Du auch mal versuchen vor der ANY ANY ANY Block Regel eine spezifische Regel für die IP's zusetzen, wo die NTP Pakete für NTP nicht gedroppt, sondern rejected werden. Sofern die Pakete nicht gespooft waren (bei gespooften IP Adressen würdest Du Du mit rejectlediglich "unbeteiligte" Opfer IP's mit RST oder "port unreachable" ICMP Paketen fluten), könnten dem admin der betroffenen Firewall mit dem/den voraussichtlich infizierten Rechnern welche die Anfragen stellen auffallen, dass er plötzlich viele RST oder "port unreachable" Pakete für NTP Anfragen erhält, was ihn hoffentlich stutzig machen sollte...

Bei wenigen IP's (natürlich auch nur sofern nicht gespooft) kann man natürlich auch einfach versuchen via RDNS und WHOIS ggf. den Betreiber / Kunden mit der IP rausfinden, und versuchen diejenigen (ISP oder Kunde direkt) zu kontaktieren.

Mit den von mir erwähnten 2 "Last Rules" Regeln solltest Du zumindest das übermässige Wachstum vom Paketfilter log in den Griff kriegen ;o)

/Sascha

Filter und Firewall-Dienste sind nicht im Vertrag enthalten. 
Dann werd ich mal den Tipp von Sascha testen. Gestern 23 Millionen geblockte Pakete. Cpu 25,6 im Schnitt.
Firmware ist übrigens die aktuelle 9.109-1, nicht die aus meiner Signatur ;-)

Sent from my iPhone using Astaro.org

Hi Martin

Die NTP Anfragen nehmen mit der Zeit schon ab, wenn die bösen Jungs mal merken, dass der NTP nicht mehr auf ist. Ich tippe mal darauf, dass die Anfragen via BOT's kommen, und mit UDP daherkommen, was einfach zu spoofen ist (hiesse die Anfragen kommen von hunderten verschiedener IP Adressen). Die bösen Jungs prüfen wohl nicht regelmässig, ob deren "Bombardierung" mit Paketen auch erfolgreich ankommt...ist ja normalerweise weder deren Rechenleistung noch Bandbreite die da verschwendet wird...

Falls die Anfragen von wenigen Source IP Adressen herkommen - insbesondere falls es TCP wäre, kanst Du auch mal versuchen vor der ANY ANY ANY Block Regel eine spezifische Regel für die IP's zusetzen, wo die NTP Pakete für NTP nicht gedroppt, sondern rejected werden. Sofern die Pakete nicht gespooft waren (bei gespooften IP Adressen würdest Du Du mit rejectlediglich "unbeteiligte" Opfer IP's mit RST oder "port unreachable" ICMP Paketen fluten), könnten dem admin der betroffenen Firewall mit dem/den voraussichtlich infizierten Rechnern welche die Anfragen stellen auffallen, dass er plötzlich viele RST oder "port unreachable" Pakete für NTP Anfragen erhält, was ihn hoffentlich stutzig machen sollte...

Bei wenigen IP's (natürlich auch nur sofern nicht gespooft) kann man natürlich auch einfach versuchen via RDNS und WHOIS ggf. den Betreiber / Kunden mit der IP rausfinden, und versuchen diejenigen (ISP oder Kunde direkt) zu kontaktieren.

Mit den von mir erwähnten 2 "Last Rules" Regeln solltest Du zumindest das übermässige Wachstum vom Paketfilter log in den Griff kriegen ;o)

/Sascha