Problem mit UDP_Flooding

H

Hirnrinde

New Member
Hallo erstmal,

zu meiner Situation:
Habe mit bei 1und1 nen vServer angemietet, eine von mir erstellte HP (PHP-Kit) und einen TS3-Server hochgeladen.

Lief alles auch 2-3 Wochen ohne Probleme, doch eines morgens musste ich feststellen, dass mein Server vom Hoster gesperrt wurde. Also Hotline angerufen, Server entsperren lassen. Neuinitialisierung gestartet und diesesmal wieder HP hochgeladen und TS-Server installiert.

Nun heute morgen das gleiche Problem. Wieder Hotline angerufen und gefragt woran es lag, dass sie ihn erneut gesperrt haben. Angeblich sind von meinem UDP-Port soviele Anfragen ausgegangen, dass dort die Alarmglocken geläutet haben...

Nun wurde der Server wieder entsperrt und darauf hingewiessen, dass es beim nächsten mal nicht so reibungslos ablaufen würde, sprich Unterlassungserklärung etc.

Um dieses zu vermeiden würde mich mal interessieren wie ich meinen TS-Server soweit absichern kann, dass genau dieses eben nicht wieder eintritt.

Da TS3 ja noch Beta ist, sollte ich erstmal wieder auf TS2 umsteigen oder gibt es ne einfache Möglichkeit den Skript-Kiddies den Spaß an meinem Server zu vermiesen, denn auf Dauer nervt es einfach alle paar Tage den Server zu löschen und neu aufzusetzen -.-

MfG,

Sascha
 
Und du denkst, dass der TS3 Server an der Sperre Schuld ist? Was verleitet dich zu dieser Annahme?

Schonmal den Datenverkehr getracked?
 
gehe mal ganz starl davon aus, dass es an ts liegt.. nutz einfach mal nur google zu diesem thema... da findest du etliche posts zu ts3 und udp-floods...

jedoch habe ich nichts brauchbares finden können...

an der hp kann es meiner meinung nach nicht liegen, da diese erst telativ neu ist und sogut wie kaum irgendwelche zugriffe hat...
 
Die Posts beziehen sich allesamt afaik auf aeltere Versionen die schon repariert wurden.
Solange du nicht Zugriff auf die Daten hast und eine Analyse durchfuehren kannst bleibt es ein Ratespiel...
 
hab server mal reinistialisiert und nur ts laufen, ohne apache etc.... mal schauen ob es wieder auftritt... sonst zur not ts einfach chrooten.... sollte denke ich die sicherste variante sein..
 
Also, hier nun das Logfile, welches mir von meinem Anbieter gemailt wurde, und worauf hin der Server zum dritten Mal gesperrt wurde:


11:11:39.066136 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066136 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066252 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066253 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066253 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066254 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066256 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066384 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066385 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066503 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066505 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066870 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066871 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066872 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066988 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066989 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15
11:11:39.066992 IP xx.xx.xx.xx.34072 > 89.44.246.5.22: UDP, length 15

usw. usf. -.-

Habe herausgefunden, dass die IP zu dem TSViewer gehört, der auf der HP von nem Kumpel liegt. Aber angeblich soll der schon lange abgeschaltet sein.

reicht es einfach, wenn ich die IP 89.44.246.5 komplett banne? oder was kann ich machen, damit der Server nicht morgen oder übermorgen gleich wieder gesperrt wird...

Hatte damals 4 Jahre lang nen TS-Server und nie solche Probleme...

Komische Sache.... :-(
 
reicht es einfach, wenn ich die IP 89.44.246.5 komplett banne?
Click to expand...
Die Richtung des Pfeiles ">" ist dir ja schon klar?
Der Server wird nicht von der externen IP angegriffen sondern greift diese an. Es reicht also nicht, sondern du musst die URSACHE finden.

oder was kann ich machen, damit der Server nicht morgen oder übermorgen gleich wieder gesperrt wird
Click to expand...
Wie bereits gesagt... die Ursache finden.

Hatte damals 4 Jahre lang nen TS-Server und nie solche Probleme...
Click to expand...
Teamspeak1 ist nicht Teamspeak2 ist nicht Teamspeak3.

Weiterhin kann man -aufgrund des seltsamen Zielports- nicht davon ausgehen dass der Server selbst flooded. Eventuell ist ein gemunkerter aber bislang nicht bestaetigte Bug im Filetransfer ausnutzbar um Code (meist Perl-Dateien) hoch zu laden und aus zu fuehren.
Zur Deaktivierung, siehe hier: http://forum.teamspeak.com/showthread.php?t=48760

Es ist ja weiterhin auch noch nicht bestaetigt dass Teamspeak3 die Ursache des Problems ist, jedgliche andere Software und Skripte koennen exploitet worden sein. Eventuell ist auch dein Shell-Zugang durch einen Trojaner bekannt und kompromittiert. (ja solche gibts mittlerweile)
 
d4f said:
Die Richtung des Pfeiles ">" ist dir ja schon klar?
Der Server wird nicht von der externen IP angegriffen sondern greift diese an. Es reicht also nicht, sondern du musst die URSACHE finden.
Click to expand...

Ok, wer lesen kann ist klar im Vorteil... Sry, hab ich vollkommen übersehen...

Nur wunderts mich dann, dass von meinem Server ausgerechnet der TSViewer-Server angegriffen wurde... Ist ja nun nicht wirklich spannend.



d4f said:
Es ist ja weiterhin auch noch nicht bestaetigt dass Teamspeak3 die Ursache des Problems ist, jedgliche andere Software und Skripte koennen exploitet worden sein. Eventuell ist auch dein Shell-Zugang durch einen Trojaner bekannt und kompromittiert. (ja solche gibts mittlerweile)
Click to expand...

Wie gesagt, nach den zweiten Sperren des Servers habe ich lediglich den TS-Server am laufen gehabt, um das PHPKit ausschliessen zu können.

Gibt es evtl. ne Möglichkeit den root-user umzubenennen, so dass es für andere schonmal erschwert wird sich überhaupt als dieser einzuloggen? ssh-port hatte ich schon manuell geändert...
 
Gibt es evtl. ne Möglichkeit den root-user umzubenennen
Click to expand...
Jein. Du kannst Zugriff mit dem Benutzer "root" verbieten und einen 2. Admin mit dem Namen toor (bsp) anlegen.
Allerdings wurde das System hoechstwahrscheinlich nicht ueber SSH kompromitiert sondern in eine Schwachstelle in Teamspeak - somit ist der Login irrelevant.
Zum flooden anderer Server bedarf es keiner Root-Rechte sondern ein normaler Benutzer (unter welchem TS laufen sollte) reicht locker aus.

Nur wunderts mich dann, dass von meinem Server ausgerechnet der TSViewer-Server angegriffen wurde
Click to expand...
Der Port (22 = SSH) des angegriffenen Servers ist auch interessant. Warum SSH? (Evtl weil die Firewalls hier keine DROP-Regeln haben?)
Aber ohne die Software oder den Grund des Angriffs zu kennen ist und bleibt es ein reines Ratespiel. Wir brauchen Fakten!
 
d4f said:
Der Port (22 = SSH) des angegriffenen Servers ist auch interessant. Warum SSH? (Evtl weil die Firewalls hier keine DROP-Regeln haben?)
Aber ohne die Software oder den Grund des Angriffs zu kennen ist und bleibt es ein reines Ratespiel. Wir brauchen Fakten!
Click to expand...

Welche Log-Dateien würden denn darüber Aufschluss geben? Hab die TS-Logs schon überflogen, aber konnte nichts wirklich auffälliges erkennen...
 
Normalerweise keine ;)
(Hoechstens dier kernel-Log wenn er Probleme mit der Paketverarbeitung hat)

Eine groessere Chance gibt es wenn du die Software suchst welche den Exploit benutzt hat. in /tmp/ gespeicherte Daten gehen jedoch idr nach einem Reboot verloren - und dort werden auch die Flooder am meisten gespeichert
 
Eine kleine Anmerkung noch, weil ich PHP Kit gelesen habe. PHP Kit zählt nicht gerade als sonderlich sicheres CMS. Ich hatte es auch schon einmal im Einsatz und nach ca. 2 Monaten wurde die Webseite gehacked. Absolut nicht empfehlenswert. Wenn es um eine gut besuchte Webseite geht würde ich empfehlen lieber auf CMS Systeme wie Joomla, Typo3, Webspell oder Typo Light auszuweichen, hier ist sichergestellt, dass diese immer weiterentwickelt werden.
 
Ja, das mit dem PHP-Kit war mir auch bekannt, deswegen haben ich nach der 2ten Reinitialisierung auch komplett darauf verzichtet, ebenfalls auf apache2 um sicherzustellen dass es nicht am Kit liegen kann.

Somit ist das Kit meiner Meinung nach nicht der Übeltäter.


Hab den Server gerade wieder gestartet. Werd noch ne Weile abwarten und es dann mal mit

# netstat -anp | grep 34072

und

# ls -l /proc/PID

versuchen.

Gucken was er ausspuckt...
 
Hab den Server gerade wieder gestartet.
Click to expand...
Ist das nicht defintiv fahrlaessig? Du solltest schon Analysewerkzeug haben welches den Missbrauch erkennt (zb am Traffic), alle Prozesse und deren Pfad speichert und dann den server ueber Kernel-Kommando (ohne sauberes Shutdown) runter faehrt...
 
Schon, wüsste aber nicht wie ich sonst etwas erreichen könnte...


evtl tcpdump? Oder welches Programm könnte ich sonst zur Auswertung nutzen?
 
Hebe den Server jetzt erstmal komplett zurückgesetzt, derzeit läuft somit nur rein debian, nix weiteres.. Werde mich heute Nachmittag erstmal ransetzten und versuchen das Ganze sicher zu bekommen, bevor ich anfange den TS-Server zu installieren.
 
Sorry, aber die sollten Dir die Kiste abschalten. Üben kannst Du in einer virtuellen Maschine.
 
Bau dir zu Hause ne Spiel Umgebung auf und lerne da mal ein bischen.
Ich werte die logs alle per Hand aus, altmodisch aber sehr zu empfehlen.
Da lernt man ne menge durch, und wenn fragen da sind hilft google oder huschi ganz schnell :D
 
dev said:
Sorry, aber die sollten Dir die Kiste abschalten. Üben kannst Du in einer virtuellen Maschine.
Click to expand...


Vielen Dank für den Tip, auch wenn es nicht unbedingt zur Lösung des Problems beisteuert.

Hab das Problem übrigens mittlerweile in den Griff bekommen... auch ohne abschalten des Geräts...
 
You must log in or register to reply here.
Back
Top