paketverluste auf meinem rootserver

[szenenight]

Hallo,

ich habe einen Rootserver bei Strato stehen, Suse10 - aktueller Patch Stand, mod_security installiert, seit einigen Wochen habe ich immer ab 18 ca. 20 Uhr Paketverluste. Ich habe darauf hin mal ein tcpdump gemacht

Auszug:

Code: Select all

20:08:03.929874 IP www.svetozar.ru.56881 > h****.serverkompetenz.net.http: S 1173541183:1173541183(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258333844 0>
20:08:07.905987 IP www.cia-center.ru.58310 > h****.serverkompetenz.net.http: S 751310977:751310977(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258334241 0>
20:08:10.900370 IP www.cia-center.ru.58310 > h****.serverkompetenz.net.http: S 751310977:751310977(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258334541 0>
20:08:14.100700 IP www.cia-center.ru.58310 > h****.serverkompetenz.net.http: S 751310977:751310977(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258334861 0>
20:08:14.805431 IP node-217-23-143-224.caravan.ru.64195 > h****.serverkompetenz.net.http: S 3058964628:3058964628(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 1967965 0>
20:08:14.805461 IP h****.serverkompetenz.net.http > node-217-23-143-224.caravan.ru.64195: S 4037896957:4037896957(0) ack 3058964629 win 5792 <mss 1460,sackOK,timestamp 170800809 1967965,nop,wscale 2>
20:08:14.866392 IP node-217-23-143-224.caravan.ru.64195 > h****.serverkompetenz.net.http: . ack 1 win 33304 <nop,nop,timestamp 1967972 170800809>
20:08:14.867977 IP node-217-23-143-224.caravan.ru.64195 > h****.serverkompetenz.net.http: P 1:658(657) ack 1 win 33304 <nop,nop,timestamp 1967972 170800809>
20:08:14.867989 IP h****.serverkompetenz.net.http > node-217-23-143-224.caravan.ru.64195: . ack 658 win 1777 <nop,nop,timestamp 170800825 1967972>
20:08:14.870956 IP h****.serverkompetenz.net.40506 > rns30.rl.b.rz-ip.net.domain:  13064+ AAAA? node-217-23-143-224.caravan.ru. (48)
20:08:14.872961 IP h****.serverkompetenz.net.40506 > rns30.rl.b.rz-ip.net.domain:  50869+ A? node-217-23-143-224.caravan.ru. (48)
20:08:14.874860 IP h****.serverkompetenz.net.40506 > rns30.rl.b.rz-ip.net.domain:  37453+ AAAA? node-217-23-143-224.caravan.ru. (48)
20:08:14.876317 IP h****.serverkompetenz.net.40506 > rns30.rl.b.rz-ip.net.domain:  34482+ A? node-217-23-143-224.caravan.ru. (48)
20:08:15.011808 IP www.lisnyak.ru.59309 > h****.serverkompetenz.net.http: S 4292278669:4292278669(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258334952 0>
20:08:15.144188 IP h****.serverkompetenz.net.http > node-217-23-143-224.caravan.ru.64195: P 1:370(369) ack 658 win 1777 <nop,nop,timestamp 170800894 1967972>
20:08:15.144302 IP h****.serverkompetenz.net.http > node-217-23-143-224.caravan.ru.64195: F 370:370(0) ack 658 win 1777 <nop,nop,timestamp 170800894 1967972>
20:08:15.205457 IP node-217-23-143-224.caravan.ru.64195 > h****.serverkompetenz.net.http: . ack 371 win 33119 <nop,nop,timestamp 1968005 170800894>
20:08:15.206190 IP node-217-23-143-224.caravan.ru.64195 > h****.serverkompetenz.net.http: F 658:658(0) ack 371 win 33304 <nop,nop,timestamp 1968005 170800894>
20:08:15.206200 IP h****.serverkompetenz.net.http > node-217-23-143-224.caravan.ru.64195: . ack 659 win 1777 <nop,nop,timestamp 170800909 1968005>
20:08:18.010905 IP www.lisnyak.ru.59309 > h****.serverkompetenz.net.http: S 4292278669:4292278669(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258335252 0>
20:08:18.614779 IP gw.yasno.ru.56086 > h****.serverkompetenz.net.http: S 3197417694:3197417694(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 1772278 0>
20:08:19.401686 IP gw.yasno.ru.56230 > h****.serverkompetenz.net.http: S 2739338883:2739338883(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 1772357 0>
20:08:21.211521 IP www.lisnyak.ru.59309 > h****.serverkompetenz.net.http: S 4292278669:4292278669(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 258335572 0>
20:08:21.608474 IP gw.yasno.ru.56086 > h****.serverkompetenz.net.http: S 3197417694:3197417694(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 1772578 0>
20:08:22.398519 IP gw.yasno.ru.56230 > h****.serverkompetenz.net.http: S 2739338883:27393388

dabei habe ich pre grep auf .ru gefiltert. Trotzdem sieht mir das irgendwie nach einer ddos aus, liege ich da richtig? Ich habe nun erst angefangen einige IP Bereiche per iptabels zu sperren, aber das geht immer weiter? Die Frage ist, sind diese Einträge ggf. gefälscht und kommen die ganzen Anfragen in wirklichkeit wo anders her? Und wie bekomme ich das dann raus? Habt ihr noch ein Tipp, was ich weiter auswerten kann? Bzw wie ich mich davor schützen kann? mod_evasive habe ich gelesen bringt nur etwas bei einer Attacke von einem Rechner?

Ich würde mich über ein konstruktive Anregung freuen.
Danke!

[oxygen]

Die Adressen sind zwar tatsächlich etwas merkwürdig, aber ein Hinweise auf ein (d)DoS oder anderen Angriff kann man diesem Auszug nicht entnehmen. Da müsste man sich die ensprechenden Webserverlogs anschauen.
Paketverlust klingt auch eher nach einem Verbindungsproblem.

[szenenight]

Ja die Frage die sich mir stellt: Kann ein Verbindungsproblem entstehen, wenn diese Anfragen einfach zu oft reinkommen? Ich frage mich einfach wo sonst diese Verbindungsprobleme immer wieder herkommen (Strato fragt sich das zur Zeit übrigens auch...^^)

Wegen den anderen Logauswertungen, dort kann ich eigentlich nicht wirklich was erkennen, kann gerne mal ein Logauszug posten. Auf dem Server wird nur eine Domain produktiv gehostet, daher wäre das sicher kein Problem.

[szenenight]

1. Ja und nein, wenn die Anfragen die Bandbreite Deines Netzwerkes vollständig auslasten, kann es durchaus zu verbindungsproblemen kommen.

Das wäre ja zumindest denkbar, denn 18-20 ist ja auch sicher eine Zeit wo viele Leute auf meine Seite surfen...

2. Paketverluste deutet jedoch eher auf ein Problem in der Kommunikation hin. /var/log/messages mal genauer unter die Lupe nehmen. Könnte ja durchaus sein, dass die Netzerkkarte am sterben ist.

Was wäre denn ein Zeichen dafür??

Was sich nun Strato dabei fragt... Vieleicht ein internes Problem welches Dir nicht auf die Nase gebunden werden soll.

Naja das wäre die Vermutung Paketverluste müssen ja auch nicht bedingt durch mein Rechner auftreten. Naja ich hab denen mal ein Einschreiben zukommen lassen, mal gucken wie die dann reagieren.

[szenenight]

Was wäre denn ein Zeichen dafür??

Link down z.B.

HAA Volltreffer:

Code: Select all

Sep 19 18:32:44 h***** kernel: tg3: eth0: Link is down.
Sep 19 18:32:44 h***** kernel: klogd 1.4.1, ---------- state change ---------- 
Sep 19 18:32:46 h***** kernel: tg3: eth0: Link is up at 100 Mbps, full duplex.
Sep 19 18:32:46 h***** kernel: tg3: eth0: Flow control is off for TX and off for RX.

So die Frage ist, warum ist das jetzt so? Und warum kommt das nur 2-3 mal vor und nicht die ganze Zeit über wenn die Paketverluste sind?

Update: Das ist auch nur an einem Tag vorgekommen, sprich es kommt nicht immer vor wenn der Server Paketeverluste hat.

[szenenight]

Weil es nicht zwangsläufig der Fall sein muss, dass sich die Netzwerkkarte wirklich abmeldet, wenn Sie keine Daten versenden kann.
Bei einem technischen Defekt, nach dem es ziemlich aussieht, ist es nicht sicher und 100% genau zu definieren, wie die Hardware reagiert.


Für Dich heisst das, mehrmals den Hardware test anstossen lassen und hoffen, dass dieser auf Fehler läuft.

Für diesen Fehler übrigens gibt es 2 Möglichkeiten:
Netzwerkarte Deiner Pizzabox ist defekt oder der Port am Switch.

Einer meiner Server verabschiedete sich wegen einem solchen Problem. Nach 2 Wochen und endlosem nerven des Supports, gab es dann eindlich eine neue Maschine, keine derartigen Einträge mehr im Log und eine uptime von 100 % seit 2 Jahren. Geduld ist nun angesagt. Denn ws der Support dabei denkt ist leider erst mal irrelevant.
Diese verlassen sich nur auf Ergebnisse des Hardwaretests, welcher in einem frühen Stadium des Hardwaredefektes leider nicht fündig wird.
Leider ein sehr ungenügender Hardwaretest der dort eingesetzt wird.

Gruss Matthias

UUrgs neuer Server hört sich nach MASSIV arbeit für mich an - sollen die doch die blöde Karte tauschen *grummel*

Die Frage ist aber, wieso tritt das Problem immer zwischen 18 und 20 Uhr auf und nicht durchgehend???

[szenenight]

Kann devirse Gründe haben, warum es ausgerechnet zwischen 18:00 und 20:00 passiert. Durchaus auch denkbar, dass ein Nachbarsystem zu dem Zeitpunkt den Switch ins trudeln bringt.
Auch denkbar, dass es wegen der stärkeren auslastung um diese Urzeit erst auffällt.
-> Apropo, wie machst Du den Paketverlusst eigentlich aus?

Ein Kartentausch finden übrigens nicht statt. Entweder die komplette Blade oder gar nichts.
Gruss Matthias

Ok zu Nachbarsystem: Schön, aber das darf ja dann nicht MEIN Problem sein

Paketverlust, ganz einfach ping IP -t -> Zeitüberschreitung + tcpdump -> dropped packets + pingplotter pro

Stichwort Blade = Mehrere Server inner halb einer Blade oder? Und dann würde bei nem Netzwerkkartentausch die anderen einen Ausfall haben, gell?

Fakt ich brauch nen neuen Server... Und dann darf ich alles neu einreichten... omg! So und das alles unverschuldet? Da müsste sich Strato dann aber kulant zeigen... holla...

[szenenight]

hab ich denn ne chance ne 2. Kiste erstmal paralell zu bekommen? Damit ich alles in ruhe aufbauen kann? Naja ok die Frage sollte ich meinem Provider stellen, aber vielleicht hat ja jemand Erfahrung :-)

[szenenight]

Da ich schon den größten Server habe, muss ich sagen - da gibt es für mich kein Verhandlungsspielraum. Eine 2. Kiste habe ich auch schon, darauf wird die Seite aber nicht laufen. Fakt ist, wenn sich Strato das erlauben kann, bin ich da weg. Dann ziehe ich alle Server von Strato ab, und die können sich sicher sein, dass ich keine Werbung für Starto Dienstleistungen mehr machen werde...

Der Server ist kein ganzes Jahr alt, also gut schaun wir mal. Ich werde da heute nochmal wieder anrufen und fragen, ob Sie mein Einschreiben erhalten haben. Meine Geduld neigt sich dem Ende nach 2 Monaten Störungen und Suchen und Telefonaten mit der Hotline.

[daemotron]

Möglicherweise ist es auch gar kein "richtiger" Hardware-Defekt, sondern ein Problem mit TSO oder Auto-Negotiate. Beides kannst Du der Karte abgewöhnen (mit ethtool) und mal schauen, ob die Probleme dann immer noch auftreten.

HTH

[daemotron]

Ui, ich dachte immer, dass S. Sun-Blech nur für die eigenen Shared-Hosting-Angebote nutzt. Weißt Du denn, was das konkret für Kisten sind? Kann ja eigentlich nix aus der Standard-Produktpalette sein. Und überhaupt: Warum gibt's die dann nicht mit Solaris?

[daemotron]

<OT>
Sun verbaut in seinen x64-Produkten und den aktuellen Workstations AMD-Prozessoren (ok, ich mag die Ultra Sparc III auch lieber... den T1 hatte ich noch nicht in den Fingern) - und die Dinger laufen standardmäßig unter Solaris. Die Spec der X2100 passt im Übrigen nicht zu dem, was S. in den Racks stecken hat (die M2-Variante, bei der es erst die 12xx-Opterons gibt, ist mit 4 eth-Interfaces ausgestattet). Auch die verlinkten Artikel sprechen nur von Suns im Zusammenhang mit Shared Hosting. Ich denke, dass S. wie viele andere Provider auch irgendwelche Massenware in die Racks steckt (wenn auch vielleicht standardisierte Massenware). Hochwertige Systeme rechnen sich in der Serververmietung nur bei extrem kräftigen Preisen, und das Segment wird eher von Spezialhostern bedient.
</OT>

Back to Topic:
Von daher wäre ein Versuch mit TSO oder deaktivieren von Auto-Negotiate auf jeden Fall angebracht => kostet nicht viel Zeit, und wenn's das wirklich war (kann ja auch am Switchport liegen), hat der OP auf jeden Fall eine Menge Streß und Ärger gespart, die ein Tausch des Server nun mal mit sich bringen.

[szenenight]

Back to Topic:
Von daher wäre ein Versuch mit TSO oder deaktivieren von Auto-Negotiate auf jeden Fall angebracht => kostet nicht viel Zeit, und wenn's das wirklich war (kann ja auch am Switchport liegen), hat der OP auf jeden Fall eine Menge Streß und Ärger gespart, die ein Tausch des Server nun mal mit sich bringen.

Also ich klammer mich an jeden Versuch.
Ok das habe ich mal geändert - ich warte grade gespannt auf 18 Uhr ;-)

ps: Strato bietet seit heute: ClusterIP an. Klingt schonmal vielversprechend... naja ich werd mal gucken. Ich halte euch auf dem Laufenden.

Gruss KAI

[szenenight]

Aber mal noch eine Frage:

Code: Select all

17:44:07.870839 IP support.express.ru.55061 > h***.serverkompetenz.net.http: S 3394312082:3394312082(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 9742238 0>
17:44:07.941833 IP support.express.ru.55080 > h***.serverkompetenz.net.http: S 481843782:481843782(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 9742245 0>
17:44:10.866160 IP support.express.ru.55061 > h***.serverkompetenz.net.http: S 3394312082:3394312082(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 9742538 0>
17:44:10.936144 IP support.express.ru.55080 > h***.serverkompetenz.net.http: S 481843782:481843782(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 9742545 0>

support.express.ru = via who.is = 87.242.75.160
In meinen Regeln steht aber genau diese IP als geblockt. Wieso bekomme ich die dann noch bei tcpdump angezeigt? Ist das normal? Sprich tcpdump ist vor iptables?

[szenenight]

So, also heute Abend gab es keine Paketverluste.
Und das Beste: Ne Mail von Starto, das sie den Sachverhalt bedauern und mir aus Kulanz 35 Euro gutschreiben. Naja immerhin.
Ich bin allerdings mal sehr gespannt, ob das Problem nun gelöst ist, oder ob es morgen wieder muter weitergeht...

Fortsetzung folgt...

[szenenight]

ok dachte ich mir so schon...

hier jetzt die offizielle Mail von Strato. Ich habe nun seit 3 Tage keine Beschwerden, bin nur gespannt wie lange das andauert!

Sehr geehrter Herr Schoening, wir möchten Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren. Nach erneuter Prüfung konnten wir nun die Beeinträchtigung der Erreichbarkeit Ihres Servers bleibend beheben. Wir bitten die entstandene Verzögerung zu entschuldigen. Für weitere Fragen stehen wir Ihnen selbstverständlich gerne zur Verfügung.

Danke an ALLE Beteiligten hier ;-)
*closed*