Hoher ausgehender DSL Traffic

@serpi

Ohne mir groß Gedanken gemacht zu haben wäre meine Vermutung,
dass deine UTM eventuell Updates herunterlädt ( also Firmware-Updates, die teilweise recht groß sind ).

Kannst du mal im WebAdmin schauen, ob dort ausstehende Updates angezeigt werden?

Gruß, Datax

Wenn Du die Applikationskontrolle aktiviert hast, kannst Du auf dem WAN Interface mal den Bandbreitenmonitor starten, und schauen, was für Applikationen da laufen.

Wenn Du ohne Grund hohen ausgehenden Verkehr hast, gibt es wohl dutzende möglicher Ursachen. Ich würde ich als erstes folgende Punkte prüfen:
- Spielst Du u.U. versehentlich Open Proxy oder Open Mail Relay ? ("ANY" oder "Internet" in den proxy "allowed source" oder "allow relaying" Netzen ?
- Hast Du auf dem SMTP Proxy Relaying (ggf. mit Authentifizierung) erlaubt ?
- Liegen da ggf. Mails auf der UTM im Mailspooler die nicht rauswollen ?
- RAS oder S2S VPN aktiv ?

Aber Bandbreitenmonitor ist sicher eine gute Hilfe um zu sehen, welche Applikation welchen Verkehr verursacht.

/Sascha

@Datax_87
Updates herunterladen würde sie sicherlich nicht kontinuierlich über 14 Tage tun und außerdem ist es ja ausgehender Verkehr, da müsste sie ja Updates hochladen :-)

@all
Wir haben das Problem gefunden.

Beim Zeitdienst (NTP) hatten wir "Any" als erlaubte Netze eingetragen, weil ich ehrlich gesagt zu faul war, die ganzen Sub-Netze aus unserem Haus einzutragen.

Jetzt ist es aber offensichtlich so, dass es in letzter Zeit häufig Attacken auf eben diesen Dienst gibt und genau davon sind wir wohl Opfer geworden.

Seit dem ich nur die internen Netze eingetragen habe tauchen im Firewall-Log massig NTP-Anfragen aus dem Internet auf, die geblockt werden und der ausgehende Traffic ist verschwunden.

Gefunden habe ich das auch nur weil irgendwo ein wahnsinnig hohes Volumen für den Dienst angezeigt wurde, allerdings nicht eine hohe Bandbreite.

Danke für die Hilfe, Gruß & Ciao,
Alfred

Ja...ANY ist meistens böse und mit vorsicht zu geniessen ;o)

Gut dass "der Übeltäter" gefunden wurde ;o)

Sorry for short answers and typos. was written on mobile using astaro.org app.

@serpi

Sorry für meine unüberlegte Antwort.

Beim Downloaden von Updates werden natürlich Daten HERUNTERGELADEN, autsch [:D]!!!

Die DDos-Attacke auf NTP-Server ist mir auch bekannt:

Kommt Zeit, kommt

Schön, dass du den Fehler gefunden hast :-).

Gruß, Datax

Gefunden habe ich das auch nur weil irgendwo ein wahnsinnig hohes Volumen für den Dienst angezeigt wurde, allerdings nicht eine hohe Bandbreite.  

  

Hallo zusammen,
momentan beobachte ich einen Anstieg der NTP-Angriffe. Seit dem 19.2. wächst die Droprate ständig an, ich bin jetzt bei 21 Mio. Paketen täglich. Der Dienst läuft auch nur für die internen Netze, trotzdem bin ich etwas verunsichert weil die Protokolle jetzt bei 3GB pro Tag liegen und pro Tag immer größer werden. Die CPU-Last steigt ebenfalls mit an. Bin aber auch erst bei 24% im Schnitt.

Gruß Martin

@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

(Sorry, my German-speaking brain isn't working now. [:(])

If you're using the SMTP Proxy, you might have an email "stuck" in the outbound queue.  For the longest time, Yahoo broke communication after 10 MB, causing the email to be sent over and over again.  I don't think they have that limitation now, but you might have a correspondent that does something similar.

MfG - Bob (Bitte auf Deutsch weiterhin.)