Website nicht mehr erreichbar
- Thread starter Spumm2001
- Start date
ThomasChr
Active Member
Zeig mal die Ausgabe des Befehls 'nestat -tulpen'.
Es scheint so zu sein als würde irgendein Programm viele Verbindungen gleichzeitig aufmachen - und die gleichzeitigen Verbindungen sind bei eurer Virtualisierungslösung (wahrscheinlich Virztuozzo) auf ein relativ niedriges Limit beschränkt!
Thomas
Es scheint so zu sein als würde irgendein Programm viele Verbindungen gleichzeitig aufmachen - und die gleichzeitigen Verbindungen sind bei eurer Virtualisierungslösung (wahrscheinlich Virztuozzo) auf ein relativ niedriges Limit beschränkt!
Thomas
SorryPHP-Friends
Active Member
Du hast dich aber sicher schon mal per SSH auf deinen Server bzw. konkret dessen Shell verbunden..?
nexus
Well-Known Member
Ist jetzt nicht böse gemeint, aber bei deinem Wissensstand wäre es nicht zielführend, dich an die Hand zu nehmen und gemeinsam auf Problemsuche zu gehen. Außerdem dürfte es sich hier wahrscheinlich nicht nur um ein einzelnes kleines Problem handeln sondern um mehrere, die sich in ihrem Ergebnis potenzieren.
Ich würde dir zu folgendem Vorgehen raten:
Such dir einen professionellen Admin, der deine Grundsituation analysiert und dein aktuelles System begutachtet.
Laß dich durch ihn beraten, was du tatsächlich als Basis für dein Hobbyprojekt brauchst, denn oft reicht ein Webspace-Paket aus, es muß nicht zwangsläufig ein eigener (v)Server sein. Wenn es notwendig sein sollte, das Ganze auf einem eigenen Server zu betreiben, dann solltest du die Möglichkeit in Betracht ziehen, einen Managed Server als Basis zu nutzen.
In beiden Fällen (Webspace und managed Server) würde für dich jegliche administrative Tätigkeit wegfallen, du bräuchtest dich nicht um Updates, Upgrades oder evtl. auftretende Probleme kümmern, da diese Tätigkeiten vom Hoster erledigt werden würden. So könntest du dich ganz auf dein Kerngeschäft, dein Hobbyprojekt konzentrieren.
tulpen ist zwar eine schöne Eselsbrücke, nur hilft manchmal ein Esel nicht so ganz weiter:
Da nur tcp sockets Probleme bereiten, ist -u nicht nötig.
-l zeigt nur listening sockets an, das dürfte nicht aussagekräftig sein. Deshalb besser mit -a auch die established connections anzeigen lassen.
Es kann passieren, dass mit 2x -e mehr Informationen angezeigt werden.
--
.A.
ThomasChr
Active Member
@.A.: Stimmt, die UDP-Dinger wären egal, aber nur listen ist doof...
Momentan ist der Server ruhig und idelt. Ich vermute die TCP-Sockets gehen aufgrund irgendeines Floods hoch und hoffe dass der nur aus einer bestimmten IP-Range kommt die man mit iptables blocken kann... (ich glaube Virtuozzo hat mittlerweile iptables Zugriff implementiert...)
Ich werde berichten wenns was zu berichten gibt. Momentan monitore ich die Seite, aber in den letzten Stunden lief alles.
Thomas
Momentan ist der Server ruhig und idelt. Ich vermute die TCP-Sockets gehen aufgrund irgendeines Floods hoch und hoffe dass der nur aus einer bestimmten IP-Range kommt die man mit iptables blocken kann... (ich glaube Virtuozzo hat mittlerweile iptables Zugriff implementiert...)
Ich werde berichten wenns was zu berichten gibt. Momentan monitore ich die Seite, aber in den letzten Stunden lief alles.
Thomas
Na dann
Code:
iptables -A INPUT -m conntrack --ctstate NEW -m hashlimit --hashlimit-above 90/second -j LOG--
.A.
ThomasChr
Active Member
Hab mir das nun mal ansehen können. (nachdem bislang die ganze Zeit Ruhe war spielte mein Monitoring ab heute früh um 2 Uhr Weihnachtsbaum) Die Attacke kommt von verschiedenen IP-Adressen und sorgt dafür dass die Verbindungen im Status FIN_WAIT_2 oder TCP_CLOSE_WAIT stehen bleiben bis die numtcpsocks voll sind. Wenn das passiert gibts eine Abkühlphase (in der keine Verbindungen mehr angenommen werden) und ~10 Minuten später kommt die Attacke wieder.
Zielports sind übrigens 25, 80 und 443.
Logfiles kann ich vom Handy gerade schlecht liefern (zumal ich gerade selber nicht mehr per SSH drauf komme).
Ideen wie man nun hier weiter vorgeht?
Thomas
Zielports sind übrigens 25, 80 und 443.
Logfiles kann ich vom Handy gerade schlecht liefern (zumal ich gerade selber nicht mehr per SSH drauf komme).
Ideen wie man nun hier weiter vorgeht?
Thomas
MadMakz
Active Member
Evtl. hilft dir schon
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 5
ggf. KeepAlive im HTTP ebenfalls niedriger setzen.
Andernfalls google mal nach "TCP Synflood" / "Half open connection" und setzt dich mit
net.ipv4.tcp_sack
net.ipv4.tcp_window_scaling
net.ipv4.tcp_keepalive_*
und was sonst alles dazu noch rausgeworfen wird auseinander.
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 5
ggf. KeepAlive im HTTP ebenfalls niedriger setzen.
Andernfalls google mal nach "TCP Synflood" / "Half open connection" und setzt dich mit
net.ipv4.tcp_sack
net.ipv4.tcp_window_scaling
net.ipv4.tcp_keepalive_*
und was sonst alles dazu noch rausgeworfen wird auseinander.
ThomasChr
Active Member
Hallo MadMakz,
Syn-Cookie klingt gut, es sieht nur so aus als hat man bei Virtuozzo da keinen Zugriff drauf, 'sysctl -n' gibt keine Ausgabe genauso wie 'cat /proc/sys/net/ipv4/tcp_syncookies'.
Ich fürchte wenn ich das einstelle und reboote wird es nicht aktiv sein.
Mist-Virtuozzo...
Aber die Suchbegriffe helfen mir schonmal sehr, vielen Dank schonmal!
Thomas
Syn-Cookie klingt gut, es sieht nur so aus als hat man bei Virtuozzo da keinen Zugriff drauf, 'sysctl -n' gibt keine Ausgabe genauso wie 'cat /proc/sys/net/ipv4/tcp_syncookies'.
Ich fürchte wenn ich das einstelle und reboote wird es nicht aktiv sein.
Mist-Virtuozzo...
Aber die Suchbegriffe helfen mir schonmal sehr, vielen Dank schonmal!
Thomas
ThomasChr
Active Member
@stefkey: Wie gesagt, keine Ausgabe.
Gepriesen sei Virtuozzo! (ist ein 1&1 vServer)
Thomas
Update: Es müsste aber evtl. schon gehen, siehe https://kb.plesk.com/en/1357
Gepriesen sei Virtuozzo! (ist ein 1&1 vServer)
Thomas
Update: Es müsste aber evtl. schon gehen, siehe https://kb.plesk.com/en/1357
Last edited by a moderator: