Frage "Möglicher SYN-Flooding" im Log trotz geringer Anzahl von SYN_RECV-Verbindungen


Kürzlich hatten wir einen Apache-Server, der aufgrund von SYN-Flooding sehr langsam reagierte. Die Problemumgehung dafür war tcp_syncookies (net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).

Ich habe eine Frage dazu gestellt Hier wenn du mehr Hintergrund willst.

Nach dem Aktivieren von syncookies haben wir ungefähr alle 60 Sekunden die folgende Nachricht in / var / log / messages gesehen:

[84440.731929] possible SYN flooding on port 80. Sending cookies.

Vinko Vrsalovic informierte mich, dass dies bedeutet, dass das syn-Backlog voll wird, also habe ich tcp_max_syn_backlog auf 4096 erhöht. Irgendwann habe ich tcp_synack_retries auch auf 3 (ab der Standardeinstellung 5) gesenkt, indem ich ausgestellt habe sysctl -w net.ipv4.tcp_synack_retries=3. Danach schien die Frequenz zu fallen, wobei das Intervall der Nachrichten zwischen ungefähr 60 und 180 Sekunden schwankte.

Als nächstes gab ich aus sysctl -w net.ipv4.tcp_max_syn_backlog=65536, bekomme aber immer noch die Nachricht im Log.

Während all dem habe ich die Anzahl der Verbindungen im SYN_RECV-Zustand beobachtet (durch Ausführen von watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), und es geht nie höher als etwa 240, viel viel niedriger als die Größe des Rückstandes. Dennoch habe ich einen Red Hat Server, der um 512 herum schwebt (das Limit für diesen Server ist der Standardwert von 1024).

Gibt es irgendwelche anderen TCP-Einstellungen, die die Größe des Backlogs einschränken würden oder breche ich den falschen Baum auf? Sollte die Anzahl der SYN_RECV-Verbindungen in netstat -tuna korrelieren mit der Größe des Rückstandes?


Aktualisieren

Soweit ich es beurteilen kann, habe ich es hier mit legitimen Verbindungen zu tun, netstat -tuna|wc -l schwebt um 5000. Ich habe das heute untersucht und gefunden dieser Beitrag von einem last.fm-Mitarbeiter, was ziemlich nützlich war.

Ich habe auch entdeckt, dass das tcp_max_syn_backlog keine Wirkung hat, wenn syncookies aktiviert sind (laut dieser Link)

Als nächsten Schritt setze ich folgendes in sysctl.conf:

net.ipv4.tcp_syn_retries = 3
        # default=5
net.ipv4.tcp_synack_retries = 3
        # default=5
net.ipv4.tcp_max_syn_backlog = 65536
        # default=1024
net.core.wmem_max = 8388608
        # default=124928
net.core.rmem_max = 8388608
        # default=131071
net.core.somaxconn = 512
        # default = 128
net.core.optmem_max = 81920
        # default = 20480

Ich habe dann meinen Reaktionszeittest eingerichtet, ran sysctl -p und deaktiviert syncookies von sysctl -w net.ipv4.tcp_syncookies=0.

Danach blieb die Anzahl der Verbindungen im Zustand SYN_RECV immer noch bei 220-250, aber die Verbindungen begannen wieder zu verzögern. Sobald ich diese Verzögerungen bemerkt habe, habe ich die Syncookies wieder aktiviert und die Verzögerungen gestoppt.

Ich glaube, dass das, was ich gesehen habe, immer noch eine Verbesserung gegenüber dem ursprünglichen Zustand war, einige Anfragen wurden jedoch immer noch verzögert, was viel schlimmer ist, als wenn Syncookies aktiviert wären. Es sieht so aus, als ob ich bei ihnen hängen bleibe, bis wir mehr Server online bekommen können, um mit der Last fertig zu werden. Selbst dann bin ich mir nicht sicher, ob ich einen gültigen Grund sehe, sie wieder zu deaktivieren, da sie (scheinbar) nur gesendet werden, wenn die Puffer des Servers voll werden.

Aber das syn-Backlog scheint nicht voll mit nur ~ 250 Verbindungen im SYN_RECV-Zustand zu sein! Ist es möglich, dass die SYN-Flooding-Nachricht ein Red-Hering ist und sich etwas anderes als das syn_backlog füllt?

Wenn jemand andere Tuning-Optionen hat, die ich noch nicht ausprobiert habe, wäre ich mehr als glücklich, sie auszuprobieren, aber ich beginne mich zu fragen, ob die Einstellung syn_backlog aus irgendeinem Grund nicht richtig angewendet wird.


30
2017-07-26 13:59


Ursprung


Siehe verwandte serverfault.com/questions/78820/dmesg-syn-flood-on-80-sysctl-p - Vinko Vrsalovic


Antworten:


Also, das ist eine nette Frage.

Anfangs war ich überrascht, dass du gesehen hast irgendein Verbindungen im SYN_RECV-Status mit aktivierten SYN-Cookies. Das Schöne an SYN-Cookies ist, dass Sie sich statisch am TCP-3-Wege-Handshake als kryptografischer Server beteiligen können. Daher würde ich erwarten, dass der Server überhaupt keine halboffenen Verbindungen darstellt, da dies genau der gleiche Zustand wäre werde nicht behalten.

In der Tat zeigt ein kurzer Blick auf die Quelle (tcp_ipv4.c) interessante Informationen darüber, wie der Kernel SYN-Cookies implementiert. Im Wesentlichen verhält sich der Kernel trotz seiner Aktivierung wie normal, bis die Warteschlange der ausstehenden Verbindungen voll ist. Dies erklärt Ihre bestehende Liste von Verbindungen im SYN_RECV-Status.

Nur wenn die Warteschlange ausstehender Verbindungen voll ist, UND ein weiteres SYN-Paket (Verbindungsversuch) empfangen wird, UND es mehr als eine Minute seit der letzten Warnmeldung vergangen ist, sendet der Kernel die Warnmeldung, die Sie gesehen haben ("Cookies senden") ). SYN-Cookies werden gesendet, auch wenn die Warnmeldung nicht angezeigt wird. Die Warnmeldung dient nur dazu, Sie darauf aufmerksam zu machen, dass das Problem nicht verschwunden ist.

Anders ausgedrückt: Wenn Sie SYN-Cookies deaktivieren, wird die Nachricht nicht mehr angezeigt. Das wird nur für dich funktionieren, wenn du nicht mehr SYN überflutet wirst.

Um einige der anderen Dinge anzugehen, die Sie getan haben:

  • net.ipv4.tcp_synack_retries:
    • Die Erhöhung dieses Werts hat keine positive Auswirkung auf eingehende Verbindungen, die gefälscht werden, und auch nicht auf solche, die anstelle eines serverseitigen Status ein SYN-Cookie erhalten (auch keine Wiederholungen).
    • Bei eingehenden gefälschten Verbindungen erhöht dies die Anzahl der Pakete, die Sie an eine gefälschte Adresse senden, und möglicherweise die Zeit, die diese gefälschte Adresse in Ihrer Verbindungstabelle verbleibt (dies könnte ein erheblicher negativer Effekt sein).
    • Bei höherer Auslastung / Anzahl eingehender Verbindungen ist es umso wahrscheinlicher, dass Sie Verbindungen über Verbindungen, die Pakete löschen, schneller / erfolgreicher abschließen. Es gibt abnehmende Renditen, um dies zu erhöhen.
  • net.ipv4.tcp_syn_retries: Diese Änderung kann keine Auswirkungen auf eingehende Verbindungen haben (betrifft nur ausgehende Verbindungen)

Die anderen Variablen, die Sie erwähnen, habe ich nicht untersucht, aber ich vermute, dass die Antworten auf Ihre Frage ziemlich genau hier sind.

Wenn Sie nicht mit SYN überflutet sind und der Computer auf Nicht-HTTP-Verbindungen (z. B. SSH) reagiert, denke ich, dass es wahrscheinlich ein Netzwerkproblem gibt, und Sie sollten einen Netzwerkingenieur haben, der Ihnen hilft, es zu betrachten. Wenn der Computer im Allgemeinen nicht reagiert, auch wenn Sie nicht SYN-geflutet werden, klingt es wie ein schwerwiegendes Ladeproblem, wenn es die Erstellung von TCP-Verbindungen beeinträchtigt (ziemlich niedrige Ebene und Ressource nicht intensiv)


27
2017-08-04 04:28



Danke - das ist eine interessante und informative Antwort. Es beantwortet sicherlich meine Abfrage über die Beziehung zwischen den Verbindungen im Status SYN_RECV und dem Senden von Cookies. Die Maschine reagierte auf nicht-HTTP, einschließlich SSH und HTTPS, die viel weniger Verkehr als HTTP empfängt. Daher haben wir entschieden, dass die Reduzierung des Verkehrs der richtige Weg ist. - Alex Forbes
Im Hinblick darauf, einen Netzwerkingenieur dazu zu bringen, einen Blick darauf zu werfen - guter Vorschlag, aber wir migrieren weg von diesem Datenzentrum, also lohnt es sich wahrscheinlich nicht, wenn wir ein paar neue Server an anderer Stelle online bringen. Ich denke, Sie haben vielleicht recht, wenn Sie ein Netzwerkproblem haben - vielleicht ein Problem mit dem Load Balancer oder der Firewall. Nochmals vielen Dank für Ihre Einsichten! - Alex Forbes


Ich habe genau das gleiche Problem bei einer neuen Installation von Ubuntu Oneiric 11.10 mit einem Webserver (Apache2) mit einer stark geladenen Website konfrontiert. Unter Ubuntu Oneiric 11.10 waren die Syncookies standardmäßig aktiviert.

Ich hatte die gleichen Kernel-Nachrichten, die einen möglichen SYN-Flood-Angriff auf den Webserver-Port anzeigen:

Kernel: [739408.882650] TCP: Möglicher SYN-Flooding auf Port 80. Senden von Cookies.

Zur gleichen Zeit war ich mir ziemlich sicher, dass es keinen Angriff gab. Ich hatte diese Nachrichten im Abstand von 5 Minuten. Dies schien wie ein Last-Peek, da ein Angreifer die Last ständig hoch hielt, während er versuchte, den Server dazu zu bringen, auf Anfragen nicht mehr zu reagieren.

Tuning der net.ipv4.tcp_max_syn_backlog Parameter führte zu keiner Verbesserung - die Nachrichten fuhren mit der gleichen Geschwindigkeit fort. Die Tatsache, dass die Anzahl der SYN_RECV-Verbindungen immer sehr niedrig war (in meinem Fall unter 250), war ein Indikator, dass es einen anderen Parameter geben musste, der für diese Nachricht verantwortlich ist.

Ich habe diese Bug-Nachricht gefunden https://bugzilla.redhat.com/show_bug.cgi?id=734991 auf der Red Hat-Site, die besagt, dass die Kernel-Nachricht als Folge eines Fehlers (oder einer Fehlkonfiguration) auf der Anwendungsseite ausgegeben werden kann. Natürlich ist die Log-Nachricht sehr irreführend! Dies ist nicht der Kernel-Parameter, der in diesem Fall verantwortlich ist, sondern der Parameter Ihrer Anwendung, der an den Kernel übergeben wird.

Daher sollten wir uns auch die Konfigurationsparameter unserer Webserver-Anwendung ansehen. Ergreifen Sie Apache Docs und gehen Sie zu http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog

Der Standardwert von ListenBacklog Der Parameter ist 511. (Dies entspricht der Anzahl der Verbindungen, die Sie auf Ihrem Red Hat-Server beobachtet haben. Möglicherweise ist auf Ihrem anderen Server eine niedrigere Anzahl konfiguriert.)

Apache hat einen eigenen Konfigurationsparameter für die Backlog Queue für eingehende Verbindungen. Wenn Sie viele eingehende Verbindungen haben und jeden Moment (zufällig) zufällig alle zusammen fast gleichzeitig ankommen, so dass der Webserver nicht in der Lage ist, sie schnell genug in angemessener Weise zu bedienen, wird Ihr Rückstand voll sein mit 511 Verbindungen und Kernel wird die obige Nachricht auslösen, die einen möglichen SYN-Flood-Angriff anzeigt.

Um das zu lösen, füge ich folgende Zeile hinzu /etc/apache2/ports.conf oder eine der anderen .conf-Dateien, die von Apache geladen werden (/etc/apache2/apache2.conf sollte auch ok sein):

ListenBackLog 5000

Sie sollten auch die net.ipv4.tcp_max_syn_backlog zu einem vernünftigen Wert. In meinem Verständnis wird das Kernel-Maximum den Wert begrenzen, den Sie in der Apache-Konfiguration konfigurieren können. also lauf:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

Vergiss nicht, deinen Apache neu zu starten, nachdem du die Konfiguration angepasst hast:

sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )

In meinem Fall hat diese Konfigurationsänderung die Kernelwarnungen sofort beendet. Ich bin in der Lage, die Nachrichten zu reproduzieren, indem ich einen niedrigen ListenBackLog-Wert in der Apache-Konfiguration festlege.


13
2018-02-15 13:40



Gute Antwort. Angenommen, was Sie sagen, ist richtig, ich würde dies als die akzeptierte Antwort markieren, aber ich kann es nicht wirklich testen - Reduzierung der Last löste das Problem und ich habe eine Politik, nicht mit Produktionsservern ohne guten Grund zu basteln :) - Alex Forbes
Ich kann bestätigen, dass dies funktioniert im Wesentlichen ist es eine Kernel-Anti-DDOS-Funktion, aber wenn Sie sagen, eine Menge Web-Traffic endet am Ende Ihre legitimen Benutzer! - Areeb Soo Yasir


Nach einigen Tests mit Kernel 3.4.9 hängt die Anzahl der SYN_RECV Verbindungen in Netstat ab

  • /proc/sys/net/core/somaxconn auf die nächste Potenz von 2 aufgerundet (z. B. 128 -> 256)
  • 75% von /proc/sys/net/ipv4/tcp_max_syn_backlog ob /proc/sys/net/ipv4/tcp_syncookies ist eingestellt auf 0 oder 100% wenn /proc/sys/net/ipv4/tcp_syncookies ist eingestellt auf 1
  • ListenBackLog in der Apache-Konfiguration aufgerundet auf die nächste Potenz von 2 (z.B. 128 -> 256)

Das Minimum jedes dieser Parameter wird verwendet. Nach dem Ändern von Somacconn oder ListenBackLog muss der Apache neu gestartet werden.

Und nach dem Erhöhen von tcp_max_syn_backlog muss auch Apache neu gestartet werden.

Ohne tcp_syncookies blockiert Apache, warum in diesem Fall nur 75% von tcp_max_syn_backlog das Limit ist, ist seltsam. Wenn Sie diesen Parameter erhöhen, werden die SYN_RECV-Verbindungen auf 100% des alten Werts erhöht, ohne den Apache neu zu starten.


5
2017-10-10 15:50



Und auch der Anruf /bin/echo m >/proc/sysrq-trigger führt oft zu einem mögliche SYN Flooding auf Port 80. Senden von Cookies Botschaft. - usoft