Netstat -n verstehen + evtl. DDoS Problem

P

Profizocker

New Member
Hey,
ich habe seit Tagen das Problem, dass mein Server extrems anfängt zu laggen. Wenn ich netstat -n eingebe, stehen ständig 5-10 Ip´s in der Liste, mit einem extrem hochen Send-Q Wert. Alle anderen IP´s haben da den Wert 0. Ich kann netstat -n fast zu egal welcher Uhrzeit eingeben, die IP`s stehen nahezu immer da. Wenn die Ip´s ausnahmesweise nicht da stehen, hört es auch auf zu laggen. Was hat der Send-Q Wert zu sagen?!

Lg
 
Okay, und wenn der Wert zu hoch liegt, kann es sein, dass es anfängt zu laggen? Als OS benutze ich FreeBSD. Vielleicht kennst du da auch eine Lösung, sehe ja, dass du einiges mit FreeBSD am hut hast. Meine PF+IPFW greift da anscheind nicht.

Lg
 
Wenn ich mich recht entsinne, sind mit Send-Q Datenpakete gemeint, die von Deinem System ausgehen und vom Remote-Host noch nicht bestätigt wurden.

Die Frage nach dem Performanceeinbruch klärt sich wahrscheinlich, wenn Du herausgefunden hast, welcher Prozess auf Deinem Rechner damit zu tun hat.
 
http://www.enterprisenetworkingplan...an-Eye-on-Your-Linux-Systems-with-Netstat.htm erklärt es unter "What it means" recht gut. Die exakte Ursache kannst Du aber nur selbst mit einem vollständigen System- und Netzwerk-Audit herausfinden, das können wir von hier aus nicht. Es kann durchaus eine kaputte oder zu schnell sendende Applikation auf Deinem System, oder ein einfacher DoS-Versuch, oder schlechtes Routing/Netzwerkmanagement, oder Korrosion am RJ-45-Stecker, oder ein Wackelkontakt, oder sonstwas sein.
 
Ich vermute mal einen DoS auf unseren Apache Server da ausschließlich der Port 80 von dem Problem betroffen ist. Sobald ich den Apache-Server abschalte, läuft alles sofort ohne Probleme und absolut laggfrei.

Hier mal ein Auszug auf "netstat -n":
Code: 
tcp4       0 230396 **.230.224.17.80      **.209.30.26.53287     ESTABLISHED
tcp4       0  66816 **.230.224.17.80      **.142.154.177.3174   ESTABLISHED
tcp4       0      0 **.230.224.17.80      **.143.95.81.61356     ESTABLISHED
tcp4       0   7352 **.230.224.17.80      **.107.156.114.3165    FIN_WAIT_1
tcp4       0 216208 **.230.224.17.80      **.201.152.107.54546  ESTABLISHED
tcp4       0  73508 **.230.224.17.80      **.102.90.21.33908     ESTABLISHED
tcp4       0  47072 **.230.224.17.80      **.10.237.13.51823     ESTABLISHED

Liebe Grüße
 
Bringt maybe nicht viel aber Syn-Flood-Protection sprich "iptables -A FORWARD -p tcp –syn -m limit –limit 1/s -j ACCEPT" und/oder "echo 1 > /proc/sys/net/ipv4/tcp_syncookies" sowie die betreffenden IPs sperren, wenn sie sich nicht ständig ändern. Bringt wahrscheinlich nicht viel - wäre aber einen Versuch wert.
 
SYN-Flood ist mit der pf-firewall eigtl. schon nahezu unmöglich. Habe es selber probiert den Server mit SYN-Flood anzugreifen, aber die IP wurde sofort gesperrt. Jedoch weiß ich nicht, wie ich mit diesem Problem umzugehen habe. Laut WhoIs sind es auch HomePc´s und keine Server (vllt. sogar ein Mini-Botnet) -> Ständig wechselnde IP´s.

Lg
 
Tjo, war halt der letzte Strohhalm. Sonst lässt sich bei nem DDoS wenig machen. Weil, wenn der Traffic einmal auf der Maschine ist, war's das. Hilft wohl nur Aussitzen.
 
Hast Du mal nach den zugehörigen Einträgen im access_log geschaut und geguckt welcher User-Agent was heruntergeladen hat und wie lange der Request dauert?
 
dotme said:
Hast Du mal nach den zugehörigen Einträgen im access_log geschaut und geguckt welcher User-Agent was heruntergeladen hat und wie lange der Request dauert?
Click to expand...

Habe diese log-Datei noch nie benutzt, könntest du mir sagen wo ich sie genau finde? O.o

Lg
 
Keine einzige der IP´s taucht in den Logs auf O.o Habe mich jedoch weiter erkundigt, und ich habe gelesen, dass es evtl. möglich sei, mit der PF-Firewall die IP´s zu blocken, die einen größeren Wert X bei Send-Q haben, als erlaubt.

Lg
 
Hmm, Apache logt eigentlich auch abgebrochen Anfragen.

Wenn Du das Apache-Modul "mod_status" aktiviert hast, kannst Du dort auch Details zu den aktuellen Anfragen sehen. Um irgendwelche Tricksereien in der TCP-Verbindung (fehlende ACKs) zu sehen müßte man "tcpdump" verwenden.

Du erwähnst zwar daß Du keine zugehörigen Einträge im "access_log" findest, aber ich weise trozdem nochmal auf die zusätzlich Parameter
  • %D - Dauer der Anfrage in Millisekunden
  • %{remote}p - Remoteport der Verbindung
  • %O - Anzahl der gesendeten Bytes
für das Logformat hin (LogFormat).
 
You must log in or register to reply here.
Back
Top