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

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