[Sicherheits-Tutorial] SYN Flood-Angriffe, SYN-Cookie-Verteidigung und Kernel-Parameteränderung für Linux/FreeBSD

HackerEs ist eine begehrte und vielversprechende Karriere. Ich schätze gute Hacker und hasse schlechte Hacker. Der sogenannte Bad Hacker ist der Typ, der jemanden auf der anderen Seite dazu bringt, Überstunden zu machen.

    SYN Flood-Angriffe sind typische Denial-of-Service-Angriffe. Der sogenannte Denial-of-Service-Angriff zielt darauf ab, indirekt den Zweck des Angriffs zu erreichen, indem der Opferhost oder das Netzwerk nicht mehr in der Lage ist, einen guten Dienst zu leisten. Hacker spielen das gerne, um zu zeigen, dass sie auf Ebene, fähig und mutig sind, indem sie die andere Partei Überstunden arbeiten lassen, aber in Wirklichkeit ist es nichts.

   1: Was ist ein SYN Flood-Angriff?

    SYN Flood-Angriffe nutzen den dreifachen Handshake-Prozess des TCP-Protokolls in IPv4. Dieses Protokoll schreibt vor, dass, wenn ein Ende eine TCP-Verbindung mit dem anderen Ende initiieren möchte, es zunächst ein TCP SYN (Synchronize)-Paket an die andere Partei senden muss, und die andere Partei nach Empfang ein TCP SYN + ACK-Paket zurücksendet, woraufhin der Initiator ein TCP ACK (ACKnowledge Character)-Paket zurücksendet, sodass die drei Handshakes beendet sind.

    Im obigen Prozess gibt es einige wichtige Konzepte:

    Die Warteschlange ist nicht verbunden: Im Dreifach-Handshake-Protokoll unterhält der Server eine nicht verbundene Warteschlange, die für jedes SYN-Paket des Clients einen Eintrag (syn=j) öffnet, der anzeigt, dass der Server das SYN-Paket erhalten hat, und dem Kunden eine Bestätigung abgibt, während sie auf das Bestätigungspaket des Kunden wartet. Die durch diese Einträge identifizierte Verbindung befindet sich im Syn_RECV Zustand auf dem Server, und wenn der Server ein Bestätigungspaket vom Kunden erhält, wird der Eintrag gelöscht und der Server tritt in den ETABLIERTEN Zustand ein. Mit anderen Worten: Wenn der TCP-Server das TCP SYN-Anfragepaket erhält, muss der TCP-Server vor dem Rücksenden des TCP SYN+ACK-Pakets an den TCP-Client zunächst ein Datengebiet für die TCP-Verbindung dieser Hand zuweisen. Im Allgemeinen ist der Verbindungszustand, wenn das SYN-Paket empfangen wird, das ACK-Paket aber noch nicht empfangen istHalboffene Verbindung(Halboffene Verbindung)。

    Backlog-Parameter: Gibt die maximale Anzahl nicht verbundener Warteschlangen an.

    SYN-ACK Anzahl der Wiederholungen: Nachdem der Server das SYN-ACK-Paket gesendet hat, führt der Server, falls das Kundenbestätigungspaket nicht empfangen wird, die erste Wiederholung durch, wartet eine gewisse Zeit und erhält das Kundenbestätigungspaket nicht, und führt die zweite Wiederholung durch; übersteigt die Anzahl der Wiederholungen die vom System angegebene maximale Anzahl an Wiederholungen, löscht das System die Verbindungsinformationen aus der Halbverbindungswarteschlange. Beachten Sie, dass die Wartezeit für jede Wiederholung nicht unbedingt gleich ist.

    Halb-zusammenhängende Überlebenszeit: Bezieht sich auf die maximale Zeit, die ein Eintrag in der Semi-Connection-Warteschlange überlebt, also die maximale Zeit von dem Empfang des SYN-Pakets durch den Dienst bis zu dem Zeitpunkt, an dem das Paket als ungültig bestätigt wird, und der Zeitwert ist die Summe der maximalen Wartezeit für alle Retransmissionsanforderungspakete. Manchmal nennen wir auch halbvernetzte Überlebenszeit, SYN_RECV Überlebenszeit.

    Beim häufigsten SYN-Flood-Angriff sendet der Angreifer innerhalb kurzer Zeit eine große Anzahl von TCP-SYN-Paketen an das Opfer, wobei der Angreifer der TCP-Client und das Opfer der TCP-Server ist. Laut der obigen Beschreibung würde das Opfer jedem TCP SYN-Paket eine bestimmte Datenzone zuweisen, solange die SYN-Pakete unterschiedliche Quelladressen hatten (was für Angreifer leicht gefälscht werden konnte). Das belastet das TCP-Serversystem stark und führt schließlich dazu, dass das System nicht richtig funktioniert.

    2. Das Prinzip der SYN-Cookies

    Eine der Möglichkeiten, SYN Flood-Angriffe effektiv zu verhindern, sind SYN-Cookies. SYN Keks Grund D. Erfunden von J. Bernstain und Eric Schenk.

    SYN-Cookies sind eine Modifikation des TCP-serverseitigen dreifachen Handshake-Protokolls, um SYN Flood-Angriffe zu verhindern.Sein Prinzip lautet:Wenn der TCP-Server ein TCP SYN-Paket erhält und ein TCP SYN+ACK-Paket zurücksendet, weist er keinen dedizierten Datenbereich zu, sondern berechnet einen Cookie-Wert basierend auf diesem SYN-Paket. Wenn ein TCP-ACK-Paket empfangen wird, prüft der TCP-Server die Legitimität des TCP-ACK-Pakets anhand dieses Cookie-Werts. Wenn legal, wird ein dediziierter Datenbereich für zukünftige TCP-Verbindungen zugewiesen.

    Lassen Sie uns darüber sprechen, wie man Kernel-Parameter konfiguriert, um SYN-Cookies in Linux und FreeBSD zu implementieren

    Drittens: Linux-Einstellungen

    Wenn Ihre Serverkonfiguration nicht gut ist, erreicht die Anzahl der TCP-TIME_WAIT-Sockets 20.000 oder 30.000, und der Server kann leicht zu Tode gezogen werden. Durch Änderung der Linux-Kernel-Parameter kann die Anzahl der TIME_WAIT Sockets auf dem Server reduziert werden.

    TIME_WAIT kann mit folgendem Befehl angesehen werden:

Unter Linux, wie CentOS, kannst du das erreichen, indem du die /etc/sysctl.conf-Datei modifizierst.

    Fügen Sie folgende Zeilen hinzu:

Illustrieren:

net.ipv4.tcp_syncookies = 1 bedeutet, dass SYN-Cookies aktiviert sind, was ein BOOLEAN ist. Wenn SYN darauf wartet, dass die Warteschlange überläuft, aktivieren Sie Cookies zur Bearbeitung, was eine kleine Anzahl von SYN-Angriffen verhindern kann, und standardmäßig ist 0, was bedeutet, dass sie geschlossen ist.
net.ipv4.tcp_tw_reuse = 1 bedeutet, dass Wiederverwendung aktiviert ist, was ein BOOLEAN ist. Erlaubt die Wiederverwendung von TIME-WAIT-Sockets für neue TCP-Verbindungen, standardmäßig auf 0, was auf Schließung hinweist;
net.ipv4.tcp_tw_recycle = 1 bedeutet, das schnelle Recycling von TIME-WAIT-Sockets in TCP-Verbindungen zu ermöglichen, was ein Boolean ist, und standardmäßig ist 0, was bedeutet, dass es geschlossen ist.
net.ipv4.tcp_fin_timeout = 30 bedeutet, dass, wenn der Socket durch eine lokale Anfrage geschlossen wird, dieser Parameter bestimmt, wie lange er im FIN-WAIT-2-Zustand bleibt. Die Einheit ist Sekunden.
net.ipv4.tcp_keepalive_time = 1200 gibt an, wie oft TCP Keepalive-Nachrichten sendet, wenn Keepalive verwendet wird. Standardwert sind 2 Stunden, geändert auf 20 Minuten. Die Einheit ist Sekunden.
net.ipv4.ip_local_port_range = 1024 65000 gibt den Bereich der für externe Verbindungen verwendeten Anschlüsse an. Der Standardfall ist klein: 32768 bis 61000, geändert zu 1024 zu 65000.
net.ipv4.tcp_max_syn_backlog = 8192 zeigt die Länge der SYN-Warteschlange an, die standardmäßig 1024 beträgt, und die Länge der erhöhten Warteschlange beträgt 8192, um mehr wartende Netzwerkverbindungen zu ermöglichen.
net.ipv4.tcp_max_tw_buckets = 5000 gibt die maximale Anzahl der Sockeln an, die das System zur gleichen Zeit TIME_WAIT, und wenn diese Zahl überschritten wird, werden TIME_WAIT Sockel sofort gelöscht und eine Warnmeldung ausgegeben. Standardmäßig ist es 180000, geändert auf 5000. Bei Servern wie Apache und Nginx können die Parameter der vorherigen Reihen die Anzahl der Sockets TIME_WAIT deutlich reduzieren, aber bei Squid ist der Effekt nicht besonders gut. Dieser Parameter steuert die maximale Anzahl TIME_WAIT Sockets, um zu verhindern, dass der Squid-Server von einer großen Anzahl TIME_WAIT Sockets herausgezogen wird.
net.ipv4.tcp_synack_retries und net.ipv4.tcp_syn_retries definieren die Anzahl der SYN-Wiederholungen.

Führen Sie folgenden Befehl aus, um die Konfiguration in Kraft zu setzen:

Wenn du /etc/sysctl.conf nicht ändern möchtest, kannst du auch den Befehl dafür verwenden:

Viertens, eingerichtet unter FreeBSD

    yayus persönliche Lernsichtweise: Die Verteidigung gegen Syns in FreeBSD ist möglicherweise nicht dieselbe wie unter Linux, die konfigurierten Parameter sind nicht exakt gleich, und die relevante Konfiguration und das Verständnis sind möglicherweise nicht korrekt :)

    Es gibt eine im TCP-LinkMSL (maximale Segmentlebensdauer)Das Konzept vonMaximale ErzeugungszeitDer MSL-Wert wird in allgemeinen Implementierungen für 30 Sekunden verwendet, und einige Implementierungen dauern 2 Minuten. "Passive Abschaltung" in der TCP-Zustandsmaschine: Von CLOSE_WAIT bis LAST_ACK gibt es folgende Regel: Wenn TCP eine aktive Abschaltung durchführt und das letzte ACK zurücksendet, muss die Verbindung doppelt so lange im TIME_WAIT-Zustand bleiben wie die MSL. Dadurch kann TCP das letzte ACK erneut senden, falls es verloren geht (das andere Ende läuft ab und die letzte FIN wird neu gesendet).

    Das Vorhandensein dieser Regel hat zur Folge, dass die Verbindung (Client-Adresse, Port und serverseitige Adresse, Port) auf dieser Adresse während dieser 2*MSL-Zeit nicht verwendet werden kann. Wenn wir zum Beispiel einen Link nach der Erstellung schließen und dann schnell neu starten, ist der Port nicht mehr verfügbar.

    TIME_WAIT Zeit ist 2*MSL. Du kannst also TIME_WAIT Zeit reduzieren, indem du net.inet.tcp.msl anpasst. Für den Webserver kann dieser Wert auf 7500 oder 2000 eingestellt werden (Zugriff auf ein Web, die Seite darf nicht länger als 4~15 Sekunden geflasht werden, du kannst in Erwägung ziehen, auf -_- zu verzichten)

    Parametereinstellungsreferenz:

Auf FreeBSD sah Yayu keinen Befehl wie "/sbin/sysctl -p", der den Inhalt von /etc/sysctl.conf effektiv machen konnte, also benutzte er einfach den Befehl: