TL; DR Der Angreifer ersetzt die Quell-IP durch die Adresse Ihres Servers und löst automatische Missbräuche aus. Infolgedessen wird der Client auf dem Hosting für böswillige Aktivitäten gesperrt, die nicht vorhanden waren.Kommentar von vdsina.ru :
Dieser Artikel wurde von unserem Kunden verfasst, der nach einem DDoS-Angriff von einem großen Hoster zu uns kam und sich freundlicherweise bereit erklärte, diese Geschichte zu teilen.
Ich erzähle Ihnen von einer überraschend heimtückischen Art von DDoS-Angriffen, die ich bisher noch nicht erlebt habe. Das Schleichende ist, dass kein Angriff auf den Server des Opfers selbst erfolgt. Stattdessen provoziert der Angreifer den Betrieb von Angriffserkennungssystemen von Drittanbietern und zwingt Ihren Server dazu, vollständig echte Beschwerden (bei gewöhnlichen Personen "Missbräuche") zu generieren.
Auf Seiten des Hosters sieht es so aus, als ob Sie in böswillige Aktivitäten verwickelt sind, obwohl dies in der Tat nicht zutrifft. Es stellte sich heraus, dass viele große Hosting-Anbieter nicht bereit sind, die Ursachen des Problems zu verstehen, und es vorziehen, Sie einfach wegen Verstoßes gegen die Regeln zu verbieten.
Dieser Artikel beschreibt diese Art von Angriff in einem realen Fall.
Zeitleiste
Ich habe mehrere persönliche Projekte auf VPS-Servern bei einem bekannten Host geführt. Einmal erhielt ich einen Brief von ihm:
# 9042382: ToS-Verstoß - Böswillige Aktivitäten
Hallo
Wir haben eine Meldung über böswillige Aktivitäten von Ihrem Server XXXX erhalten. Wir bitten Sie, diese Angelegenheit so bald wie möglich zu untersuchen. Wenn Sie Ihre Untersuchung abgeschlossen haben, antworten Sie bitte auf dieses Ticket mit den Antworten auf die folgenden Fragen:
...
Reported-From: abuse-out@checkdomain.de Category: info Report-Type: info Service: different services Version: 0.1 User-Agent: Checkdomain Express 0.19 Date: Fri, 26 May 2018 19:25:19 +0200 Source-Type: ipv4 Source: my-server-ip-xx-xxx Port: dif. Report-ID: dih3cefnp@checkdomain.de Schema-URL: http://www.blocklist.de/downloads/schema/info_0.1.1.json Attachment: text/plain DETAILS ZU DEN ATTACKEN/STÖRUNGEN | DETAILS OF THE ATTACKS (letzten 60 Tage / max. 100 St.) | (last 60 days / max. 100 hits) portflood: syn | | standby.checkdomain.de | VORHERIGE SPERREN DER IP-NUMMER | BANNED HISTORY OF THIS IP-NUMBER my-server-ip-xxx-xxx-xxx: this ip-number was never banned before AUZUG AUS SERVERLOGDATEI | EXCERPT FROM SERVER LOGFILE tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:41667 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:46208 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:13000 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:39104 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:55348 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:37266 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:60684 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:63878 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:50445 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:56215 SYNRECV -
Wobei
my-server-ip-xx-xxx die Server-IP-Adresse ist.
Darin sendet mir der Hoster eine Beschwerde, die er über seine abuse @ mailbox erhalten hat, und bittet dringend, die böswillige Aktivität zu beenden, da ich sonst blockiert werde. Das angehängte Protokoll zeigt eine Liste der TCP-Verbindungen zum 80 (HTTP) -Port im Status SYN RECEIVED. Das heißt, von meinem Server aus gibt es eine SYN-Flut auf den Webserver von jemandem.
Mein erster Gedanke ist, dass sie mich gehackt haben und die SYN-Flut von meinem Server kommt. Unter Linux gibt es Einschränkungen bei der Verwaltung von Sockets mit normalen Benutzerrechten, und Sie können nur SYN-Pakete (ohne Herstellung einer vollständigen TCP-Verbindung) mit Root-Rechten senden. Und das bedeutet, dass sie vollständig geknackt haben.
In einer Panik renne ich zum Server, um nach einem böswilligen Prozess zu suchen. Ich überprüfe oben, ss, lsof und sehe nichts Verdächtiges. Die Hauptschlussfolgerung: "
Horror, sie haben wahrscheinlich ein so cooles Rootkit geflutet, dass das Virus auf Kernel-Ebene vor allen Systemdienstprogrammen verborgen ist! ". Im Zuge der Recherche hat sich herausgestellt, dass sich die Auslastung des Servers nicht geändert hat. Gemäß den Grafiken im Hostpanel bleibt der Datenverkehr auf der Schnittstelle unverändert.
Davor habe ich
tcpdump mit Filtern gestartet, die den ausgehenden Datenverkehr
anzeigen , und nichts Verdächtiges festgestellt. Verzweifelt entscheide ich mich, den gesamten Verkehr zum Server zu sehen. Ich finde seltene RST-Pakete von fremden Servern im Strom des legitimen Verkehrs.
Es sieht ungefähr so aus, wobei
mein-server-ip-xx-xxx die Adresse meines Servers ist:
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
Es war offensichtlich, dass dies eine Anomalie war, da es keinen Austausch mehr mit diesen Servern gab und es mir nicht klar war, warum sie ein Paket gesendet haben, um die Verbindung zu schließen.
An diesem Punkt würden erfahrene Administratoren sofort alles verstehen, aber wir werden alles an unseren Fingern aussortieren
Wie funktioniert das?
Eingehende RST-Pakete sind Antworten auf Versuche, eine TCP-Verbindung zu einem privaten Port herzustellen. Gleichzeitig gibt es keinen ausgehenden Datenverkehr von meinem Server zu den Servern, die RST senden. Dies bedeutet, dass der Angreifer die ausgehende Adresse durch meine ersetzt und einen Verkehr erzeugt, der einem DDoS-Angriff ähnelt. Da ein Angreifer jedoch nur ein ausgehendes Paket senden kann, gehen alle Antworten von den Servern zu meinem Server.
Nur Antworten auf gefälschte Anfragen erreichen den Server des OpfersIn der Regel werden solche Angriffe zur DNS-Verstärkung verwendet , wenn der Angreifer eine kleine Anfrage im Namen des Opfers sendet und das Opfer eine große Antwort erhält, die er nicht angefordert hat. Dies ist ein klassischer Angriffsmechanismus gegen Kanalerschöpfung.
In meinem Fall wollte der Angreifer den Kanal des Opferservers nicht ausschöpfen. Seine Aktivität war in den Verbrauchsgrafiken des Senders völlig unsichtbar. Ihr Hauptziel war es, Systeme zur automatischen Benachrichtigung über Netzwerkangriffe zu provozieren, die einen Brief mit einer Beschwerde über die im whois-Subnetz meines Providers angegebene Missbrauchsadresse senden.
Intrusive Prevent / Detect-Systeme wie
Snort und
Suricata können dies tun .
Infolgedessen erhält der Hoster einen absolut echten Brief von seriösen Unternehmen, der eine Beschwerde über meine böswillige Tätigkeit und sogar die darin enthaltenen echten Protokolle enthält. Gleichzeitig benötigt der Angreifer keinen großen Kanal, da er die Adressen der Server, auf denen IDS / IPS-Systeme installiert sind, und die erforderliche Mindestanzahl von Paketen für die automatische Beschwerde im Voraus kennt.
Die einzige Schwierigkeit für einen Angreifer besteht darin, einen Server zu finden, auf dem ausgehende IP-Adressen in Paketen ersetzt werden können. Alle normalen Hoster blockieren solche Pakete. Es gibt nur zwei Arten von Hosting, mit denen Clients ausgehende IP-Adressen ersetzen können: entweder als Analphabet konfiguriert oder speziell für Cyber-Kriminalität entwickelt.
Überprüfen Sie die Möglichkeit von IP-Adress-Spoofing
Ich rate Ihnen, Ihren Host auf die Möglichkeit zu prüfen, ausgehende IP-Adressen zu ersetzen. Dies erfordert zwei Server, einen zum Empfangen von Datenverkehr und einen zum Senden.
Auf der Empfängerseite werden wir den eingehenden Datenverkehr protokollieren. Wir geben einen seltenen Port als Filter an, auf dem zu normalen Zeiten kein Datenverkehr stattfinden soll:
tcpdump -i any port 9912
Auf dem Server, den wir testen, erstellen wir ein Paket mit der Ersetzung der ausgehenden IP-Adresse auf
1.1.1.1 , das an Port 9912 gerichtet ist. Dazu verwenden wir das coole Dienstprogramm
nping von nmap-Entwicklern. Sie können damit alle nicht standardmäßigen Pakete auf L2- und L3-Ebene generieren.
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com
receiver-server.com - Die Adresse des Listening-Servers, auf dem tcpdump ausgeführt wird
1.1.1.1 - Ausgehende Adresse ersetzen
9912 - Remote-Port
Wenn auf der Seite von
receiver-server.com ein Paket angezeigt wird, das im Namen von 1.1.1.1 eingegangen ist, können Sie die ausgehende IP-Adresse durch Ihren Provider ersetzen. Dies ist eine Gelegenheit, ihn über Probleme beim Einrichten von Netzwerkgeräten zu informieren. Häufig wird dieses Problem von privaten Internetdienstanbietern verursacht.
Dumme technische Unterstützung
Nachdem ich die Gründe für die Beschwerden herausgefunden hatte, erklärte ich dem Hoster alles:
Hallo
Ich verstehe endlich, was passiert ist.
Sie fälschen meine IP-Adresse und zufällige DDoS-Hosts, indem sie meine Adresse als Quelladresse verwenden. So generieren Opfer automatische Missbrauchsmeldungen an meine Hosting-Provider.
Sie können im Missbrauchsprotokoll sehen, dass sich die Verbindungen nur im Status SYN_RECV befinden (keine vollständige TCP-Verbindung hergestellt), da sie nur ein Paket mit gefälschter IP senden und den TCP-Handshake nicht beenden können.
Ich kann das beweisen. Momentan kommen viele eingehende TCP-RST-Pakete von Hosts auf meinen Server, von denen ich keine Pakete gesendet habe.
Sie können dies jetzt überprüfen, indem Sie Folgendes ausführen:
tcpdump -i eth0 "tcp [tcpflags] & (tcp-rst)! = 0"
Sie werden sehen, dass viele RST-Pakete von Hosts stammen, an die ich noch keine Daten gesendet habe.
Dies zeigt, dass der Angreifer meine IP-Adresse fälscht, um mich zu kompromittieren und Missbrauch zu generieren.
Dann schien es mir, dass jeder qualifizierte Techniker die Situation verstehen würde und die Frage geschlossen würde. Stattdessen forderten sie, dass ich den Server mit Antivirensoftware überprüfe oder das Betriebssystem komplett neu installiere. Während wir mit dem technischen Support korrespondierten, kamen die Missbräuche weiter und an einem Tag wurde ich verboten.
Es war eine wilde Beleidigung, dass ich tatsächlich gerahmt wurde. Diese Situation zeigt, wie verletzlich Menschen sind, die nicht verstehen, sondern gedankenlos Skripten folgen. Seitdem zitiere ich diesen Fall oft als Beispiel, wenn die Debatte über die Auswahl eines Hostings für wichtige Projekte aufkommt. Leider können es sich viele Hosting-Anbieter einfach nicht leisten, viel Zeit für nicht standardmäßige Fälle von kleinen Kunden aufzuwenden, und es ist einfacher, Sie zu bannen, als Ihre Probleme zu lösen.
Abonnieren Sie unseren Instagram-Entwickler
