TL; DR L'attaquant remplace l'ip source par l'adresse de votre serveur et déclenche des abus automatiques. En conséquence, le client est banni de l'hébergement pour une activité malveillante qui n'était pas là.Commentaire de vdsina.ru :
Cet article a été écrit par notre client, qui nous est venu d'un grand hébergeur après une attaque DDoS et a gentiment accepté de partager cette histoire.
Je vais vous parler d'une manière étonnamment insidieuse d'attaques DDoS, que je n'ai jamais rencontrée auparavant. Ce qui est insidieux, c'est qu'aucune attaque n'est effectuée sur le serveur de la victime elle-même. Au lieu de cela, l'attaquant provoque le fonctionnement de systèmes de détection d'attaque tiers, forçant à générer des plaintes complètement réelles (dans les "abus" des gens du commun) à votre serveur.
Du côté de l'hébergeur, il semble que vous soyez engagé dans une activité malveillante, bien qu'en fait ce ne soit pas vrai. Il s'est avéré que de nombreux grands hébergeurs ne sont pas prêts à comprendre en profondeur les causes du problème et préfèrent simplement vous bannir pour avoir enfreint les règles.
Cet article détaille ce type d'attaque dans un cas réel.
Chronologie
J'ai gardé plusieurs projets personnels sur des serveurs VPS chez un hôte bien connu. Une fois que j'ai reçu une lettre de lui:
# 9042382: Violation ToS - Activité malveillante
Bonjour
Nous avons reçu un rapport d'activité malveillante provenant de votre serveur XXXX. Nous vous demandons d'enquêter sur cette question dès que possible. Une fois votre enquête terminée, veuillez répondre à ce ticket en répondant aux questions suivantes:
...
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 -
Où
my-server-ip-xx-xxx est l'adresse IP du serveur.
Dans celui-ci, l'hébergeur m'envoie une plainte reçue sur sa boîte aux lettres abuse @ et demande instamment d'arrêter l'activité malveillante, sinon je serai bloqué. Le journal joint montre une liste des connexions TCP au port 80 (HTTP) dans l'état SYN RECEIVED. Autrement dit, de mon serveur, il y a un flux SYN vers le serveur Web de quelqu'un.
Ma première pensée est qu'ils m'ont piraté et que SYN flood vient de mon serveur. Sous Linux, il existe des restrictions sur la gestion des sockets avec des droits d'utilisateur normaux et vous ne pouvez envoyer que des paquets SYN (sans établir une connexion TCP complète) uniquement avec les privilèges root. Et cela signifie qu'ils ont complètement craqué.
Dans une panique, je cours vers le serveur pour rechercher un processus malveillant. Je vérifie en haut, ss, lsof et ne vois rien de suspect. La principale conclusion: "
horreur, ils ont probablement inondé un rootkit tellement cool qui cache le virus au niveau du noyau de tous les utilitaires système! ". En cours de recherche, il s'avère que la charge sur le serveur n'a pas changé, selon les graphiques du panneau hôte, le trafic sur l'interface reste le même.
Avant cela, j'ai commencé
tcpdump avec des filtres montrant le trafic sortant et je n'ai rien vu de suspect. Désespéré, je décide de voir tout le trafic vers le serveur. Je trouve des paquets RST rares provenant de serveurs étranges dans le flux de trafic légitime.
Cela ressemble à ceci, où
my-server-ip-xx-xxx est l' adresse de mon serveur:
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]
Il était évident que c'était une anomalie, car il n'y avait plus d'échange avec ces serveurs et pourquoi ils avaient envoyé un paquet pour fermer la connexion, ce n'était pas clair pour moi.
À ce stade, les administrateurs expérimentés comprendraient immédiatement tout, mais nous allons tout régler sur nos doigts
Comment ça marche
Les paquets RST entrants sont des réponses aux tentatives d'établissement d'une connexion TCP à un port privé. En même temps, il n'y a pas de trafic sortant de mon serveur vers les serveurs qui envoient RST. Cela signifie que l'attaquant remplace l'adresse sortante par la mienne et génère un trafic similaire à une attaque DDoS. Mais comme la seule chose qu'un attaquant peut faire est d'envoyer un paquet sortant, toutes les réponses des serveurs arrivent sur mon serveur.
Seules les réponses aux fausses demandes parviennent au serveur de la victimeEn règle générale, ces attaques sont utilisées pour l'amplification DNS , lorsque l'attaquant envoie une petite demande au nom de la victime et que la victime reçoit une réponse importante qu'il n'a pas demandée. Il s'agit d'un mécanisme d'attaque d'épuisement de canal classique.
Dans mon cas, l'attaquant n'a pas cherché à épuiser le canal du serveur victime. Son activité était totalement invisible sur les graphiques de consommation de la chaîne. Son objectif principal était de provoquer des systèmes de notification automatique pour les attaques de réseau qui enverraient une lettre se plaignant de l'adresse d'abus spécifiée dans le sous-réseau whois de mon fournisseur.
Les systèmes de prévention / détection intrusifs tels que
Snort et
Suricata peuvent le faire .
En conséquence, l'hébergeur reçoit une lettre absolument réelle de sociétés légitimes, qui contient une plainte concernant mon activité malveillante et même les vrais journaux qui s'y trouvent. Dans le même temps, l'attaquant n'a pas besoin d'un grand canal, car il connaît à l'avance les adresses des serveurs sur lesquels les systèmes IDS / IPS sont installés et le nombre minimum requis de paquets pour que la plainte automatique fonctionne.
La seule difficulté pour un attaquant est de trouver un serveur qui permette la substitution des adresses IP sortantes en paquets. Tous les hébergeurs normaux bloquent ces paquets. Il n'y a que deux types d'hébergement, permettant aux clients de remplacer l'IP sortante: soit configurée très illettrée, soit spécialement créée pour la cybercriminalité.
Vérification de la possibilité d'usurpation d'adresse IP
Je vous conseille de vérifier votre hôte pour la possibilité de remplacer l'IP sortant. Cela nécessitera deux serveurs, l'un pour la réception du trafic, l'autre pour l'envoi.
Côté serveur récepteur, nous allons commencer à enregistrer le trafic entrant. Nous allons spécifier un port rare comme filtre sur lequel il ne devrait pas y avoir de trafic en temps normal:
tcpdump -i any port 9912
Sur le serveur que nous testons, nous allons générer un package avec la substitution de l'adresse IP sortante à
1.1.1.1 , dirigée vers le port 9912. Pour cela, nous utilisons l'utilitaire cool
nping des développeurs nmap. Il vous permet de générer des packages non standard au niveau L2 et L3.
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com
receiver-server.com - l'adresse du serveur d'écoute exécutant tcpdump
1.1.1.1 - adresse sortante de remplacement
9912 - Port distant
Si du côté de
receiver-server.com vous voyez un paquet qui est venu au nom de 1.1.1.1, votre fournisseur vous permet de remplacer l'adresse IP sortante. C'est l'occasion de l'informer des problèmes de mise en place des équipements réseau. Ce problème est souvent affecté par les fournisseurs de services Internet à domicile.
Support technique stupide
Après avoir compris les raisons des plaintes, j'ai tout détaillé à l'hébergeur:
Bonjour
Je comprends enfin ce qui s'est passé.
Ils usurpent mon adresse IP et les hôtes aléatoires DDoS en utilisant mon adresse comme adresse source. Les victimes génèrent donc des rapports d'abus automatiques à mes hébergeurs.
Vous pouvez voir sur le journal des abus que les connexions sont uniquement dans l'état SYN_RECV (aucune connexion TCP complète établie) car elles ne peuvent envoyer qu'un seul paquet en utilisant une IP usurpée et ne peuvent pas terminer la négociation TCP.
Je peux le prouver. De nombreux paquets TCP RST entrants arrivent actuellement sur mon serveur à partir d'hôtes auxquels je n'ai jamais envoyé de paquets.
Vous pouvez le vérifier dès maintenant en exécutant:
tcpdump -i eth0 "tcp [tcpflags] & (tcp-rst)! = 0"
Vous verrez que de nombreux paquets RST provenaient d'hôtes auxquels je n'ai jamais envoyé de données.
Cela prouve que l'attaquant usurpe mon adresse IP pour me compromettre et générer des abus.
Il m'a alors semblé que tout ingénieur de support technique qualifié comprendrait la situation et la question serait close. Mais à la place, ils ont exigé que je vérifie le serveur avec un logiciel antivirus ou que je réinstalle complètement le système d'exploitation. Alors que nous correspondions avec le support technique, les abus ont continué d'arriver et en un jour j'ai été banni.
C'était extrêmement insultant que je sois en fait encadré. Cette situation montre à quel point les personnes sont vulnérables, qui, au lieu de comprendre, suivent sans réfléchir des scripts. Depuis lors, je cite souvent ce cas à titre d'exemple lorsque le débat sur le choix d'un hébergement pour des projets importants apparaît. Malheureusement, de nombreuses sociétés d'hébergement ne peuvent tout simplement pas se permettre de consacrer beaucoup de temps aux cas non standard de petits clients et il est plus facile de vous interdire que de régler vos problèmes.
Abonnez-vous à notre développeur Instagram
