Lösen Sie das Problem des Syn Flooding in der MySQL-Datenbank

Der SYN-Angriff ist die häufigste und am leichtesten auszunutzende Angriffsmethode. Dabei werden die Mängel des TCP-Protokolls ausgenutzt, um eine große Anzahl gefälschter TCP-Verbindungsanfragen zu senden. Eine große Anzahl von SYN-Paketen wird häufig unter Verwendung gefälschter IPs gesendet. Der angegriffene Server antwortet mit SYN+ACK. Da es sich bei der anderen Partei um eine gefälschte IP handelt, wird sie das Paket niemals empfangen und nicht antworten. Infolgedessen hält der angegriffene Server eine große Anzahl von Halbverbindungen im SYN_RECV-Zustand aufrecht und wiederholt die standardmäßigen 5 Antwort-Handshake-Pakete, füllt die TCP-Warteschlange für Warteschlangen, erschöpft Ressourcen und verhindert, dass normale Geschäftsanfragen eine Verbindung herstellen.

SYN-Angriffe kommen häufig auf Anwendungsservern vor, und Datenbankserver befinden sich im Intranet, sodass es unwahrscheinlich ist, dass dort ähnliche Angriffe auftreten. Wenn die Anwendung jedoch manchmal nicht richtig mit der Datenbank verbunden ist, wird dies auf der Datenbankseite als SYN-Angriff betrachtet und die Verbindung wird abgelehnt.

[Problembeschreibung]

Die Datenbank verweigert plötzlich die Verbindung und die Anwendung meldet einen Fehler. Zum Zeitpunkt des Problems ist im Betriebssystemprotokoll des Datenbankservers, d. h. /var/log/messages, die folgende Fehlermeldung zu sehen:

Kernel: Mögliches SYN-Flooding auf Port 3306. Senden von Cookies.

【Problemanalyse】

An dem Punkt, an dem das Problem auftrat, stieg der Indikator „Threads Connected“ (Verbundene Threads) den Indikatoren der Datenbanküberwachung zufolge an. Dies ist auch sehr offensichtlich, da Syn Flooding für die Datenbank bedeutet, dass die Anwendung plötzlich eine Verbindung zur Datenbank initiiert und das Betriebssystem dies nicht verarbeiten kann, sodass es Syn Flooding meldet. Aus Sicht der Datenbankleistungsindikatoren wird die Anzahl der Verbindungen definitiv plötzlich ansteigen. Die Lösung besteht darin, zu analysieren, woher diese plötzlichen Anstiege kommen, die Spitzen zu glätten und die Täler aufzufüllen und die Verbindung stabiler zu machen.

【Lösung】

Nehmen Sie auf der Datenbankserverseite die folgenden Anpassungen vor: Diese Anpassung bedeutet: Erhöhen Sie den TCP-Halbverbindungspuffer. Der Standardwert ist 2048, und wir passen ihn auf 8192 an, um die Fähigkeit des Systems zu erhöhen, plötzlichem Druck standzuhalten. Der Standardwert von Tcp_syn_retires und Tcp_synack_retires ist 5, was bedeutet, dass der Server fünf Pakete senden muss, bevor er den Wiederholungsversuch beendet. Wir stellen diesen Parameter auf 2 ein. Wir wiederholen den Versuch nur einmal, damit das fehlerhafte Paket so früh wie möglich aufgelöst werden kann, um die Anzahl der zwischengespeicherten Verbindungen zu verringern.

echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 2 > /proc/sys/net/ipv4/tcp_syn_retries
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries

Diese Parameteranpassung wird sofort und ohne Neustart wirksam. Nach dem Neustart des Servers werden diese Parameter natürlich auf die Standardwerte zurückgesetzt. Nach dieser Anpassung wurde die Belastbarkeit der Datenbank verbessert, das Problem war jedoch nicht vollständig gelöst.

Auch clientseitig nehmen wir entsprechende Anpassungen vor:

Um den Druck auf die Anzahl der Datenbankverbindungen zu verringern, empfehlen wir normalerweise, den Verbindungspool wie folgt zu konfigurieren:

testWhileIdle="false". Überprüfen Sie die Integrität der Verbindungszeichenfolge nicht im Leerlauf.
minIdle="0". Die Mindestanzahl inaktiver Verbindungen im Verbindungspool
maxAge="30000". Ein Link kann nach einer bestimmten Anzahl von Millisekunden wiederverwendet werden.
Anfangsgröße = "1". Die Mindestanzahl an Erstverbindungen im Verbindungspool
ZeitBetweenEvictionRunsMillis="5000". Das Ausführungsintervall des Recycling-Threads (Millisekunden)

Für das aktuelle Szenario empfehlen wir, den Parameter minIdle von 0 auf 5 zu erhöhen. Lassen Sie den Verbindungspool normalerweise 5 inaktive Verbindungen haben. Auf diese Weise werden diese 5 inaktiven Verbindungen zuerst verwendet, wenn eine Anforderung an die Datenbank initiiert wird. Um den Effekt der Reduzierung von Spitzen und Füllung von Tälern zu erzielen. Der Nebeneffekt besteht natürlich darin, dass die Anzahl der Datenbankverbindungen zunimmt. Der entsprechende Anpassungsbetrag muss auf der tatsächlichen Datenbankverbindungslast basieren. Für .NET Programme gibt es auch entsprechende Connection Pool Parameter die angepasst werden können: Der Parameter minPoolSize kann entsprechend modifiziert und ebenfalls auf 5 eingestellt werden.

Nach dieser Anpassung können grundsätzlich die meisten Syn Flooding-Probleme der Datenbank gelöst werden.

Natürlich handelt es sich hierbei lediglich um Tuningmaßnahmen, die das System nur geringfügig verbessern können. Verbessern Sie Ihre Stressresistenz. Die endgültige Analyse hängt immer noch davon ab, woher der Anschlussdruck kommt. Und warum eine große Anzahl von Verbindungen zur Datenbank in Schüben hergestellt werden müssen. Ist es sinnvoll, für ein solches Notfallszenario eine Datenbank zu verwenden? Eine Alternative besteht darin, Redis als Puffer davor zu verwenden. Vermeiden Sie plötzliche Verbindungsanfragen an die Datenbank. Dabei handelt es sich um eine Transformation der Anwendung.

Zusammenfassen

Das Obige ist die Einführung des Herausgebers zur Lösung des Syn Flooding-Problems in MySQL-Datenbanken. Ich hoffe, es wird allen helfen. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und ich werde Ihnen rechtzeitig antworten. Ich möchte auch allen für ihre Unterstützung der Website 123WORDPRESS.COM danken!
Wenn Sie diesen Artikel hilfreich finden, können Sie ihn gerne abdrucken und dabei bitte die Quelle angeben. Vielen Dank!