Les attaques SSH drainent 4 Go en 10 heures. Possible?

J'ai été averti que mon serveur avait dépassé sa limite de transfert. Je pensais que mon nœud Tor était devenu populaire, alors j'ai choisi de le désactiver ce mois-ci (pas le meilleur choix pour la communauté mais je dois descendre). Ensuite, j'ai remarqué que le serveur a transféré environ 4 Go cette nuit. J'ai vérifié les journaux Apache avec Awstats, aucun trafic pertinent (et je n'y héberge pas de sites aussi populaires). J'ai vérifié les journaux de messagerie, personne n'a essayé d'envoyer des ordures. J'ai vérifié les messagesjournaux et en ai trouvé des tonnes

Apr 29 10:17:53 marcus sshd[9281]: Did not receive identification string from 85.170.189.156
Apr 29 10:18:07 marcus sshd[9283]: Did not receive identification string from 86.208.123.132
Apr 29 10:18:24 marcus sshd[9298]: Did not receive identification string from 85.170.189.156
Apr 29 10:18:39 marcus sshd[9303]: Did not receive identification string from 86.208.123.132
Apr 29 10:18:56 marcus sshd[9306]: Did not receive identification string from 85.170.189.156
Apr 29 10:19:11 marcus sshd[9309]: Did not receive identification string from 86.208.123.132
Apr 29 10:19:18 marcus sshd[9312]: Did not receive identification string from 101.98.178.92
Apr 29 10:19:27 marcus sshd[9314]: Did not receive identification string from 85.170.189.156
Apr 29 10:19:41 marcus sshd[9317]: Did not receive identification string from 86.208.123.132
Apr 29 10:20:01 marcus sshd[9321]: Did not receive identification string from 85.170.189.156
Apr 29 10:20:13 marcus sshd[9324]: Did not receive identification string from 86.208.123.132
Apr 29 10:20:32 marcus sshd[9327]: Did not receive identification string from 85.170.189.156
Apr 29 10:20:48 marcus sshd[9331]: Did not receive identification string from 86.208.123.132
Apr 29 10:21:07 marcus sshd[9336]: Did not receive identification string from 85.170.189.156
Apr 29 10:21:20 marcus sshd[9338]: Did not receive identification string from 86.208.123.132
Apr 29 10:21:35 marcus sshd[9341]: Did not receive identification string from 85.170.189.156
Apr 29 10:21:51 marcus sshd[9344]: Did not receive identification string from 86.208.123.132
Apr 29 10:22:06 marcus sshd[9349]: Did not receive identification string from 85.170.189.156
Apr 29 10:22:23 marcus sshd[9353]: Did not receive identification string from 86.208.123.132
Apr 29 10:22:39 marcus sshd[9359]: Did not receive identification string from 85.170.189.156
Apr 29 10:22:54 marcus sshd[9361]: Did not receive identification string from 86.208.123.132
Apr 29 10:23:10 marcus sshd[9367]: Did not receive identification string from 85.170.189.156
Apr 29 10:23:29 marcus sshd[9369]: Did not receive identification string from 86.208.123.132
Apr 29 10:23:45 marcus sshd[9375]: Did not receive identification string from 85.170.189.156
Apr 29 10:24:10 marcus sshd[9387]: Did not receive identification string from 86.208.123.132
Apr 29 10:24:16 marcus sshd[9388]: Did not receive identification string from 85.170.189.156

Toutes les quelques secondes, un bot essaie de pirater mon SSH, ce qui est impossible car j'ai besoin d'une authentification par clé publique. Ma question est: ce trafic, à cette fréquence, peut-il consommer 4 Go (disons 3,5) en 10 heures d'attaque continue?

J'ai changé de port SSH et arrêté ces attaques, mais je ne suis pas sûr de la consommation de mon réseau. Je n'ai pas de services hors de contrôle en cours d'exécution - mon pare-feu est un peu restrictif -, ou je partage le serveur avec quelqu'un qui fait abusivement du P2P ou autre chose. Ma préoccupation est de descendre en dessous de 400 Go / mois.

Des conseils?

linux bandwidth-control usr-local-ΕΨΗΕΛΩΝ
la source

Réponses:

4 Go est possible, mais très peu probable compte tenu du taux d'attaque. Je suggère d'installer OSSEC, il détecte les tentatives d'interruption et bloque automatiquement l'IP pendant un certain temps.

Lucas Kauffman
la source

J'ai déjà fail2ban, il a réussi à bloquer les mauvaises connexions mais semble ignorer ces messages. Je vais peut-être le mettre au point.

usr-local-ΕΨΗΕΛΩΝ

Accepté. Fail2ban avait besoin d'un ajustement pour accepter ces messages de journal comme tentatives d'effraction. +1 à @lain aussi parce que je ne peux pas accepter 2 réponses

usr-local-ΕΨΗΕΛΩΝ

@djechelon: Veuillez nous le faire savoir si cela résout le problème. D'une manière ou d'une autre, je doute que ce sera le cas lorsque les paquets seront abandonnés après être arrivés sur votre système.

user9517

@Iain la plupart des attaquants abandonnent lorsqu'ils sont lâchés.

Lucas Kauffman

@LucasKaufman: 4 Go / 10 heures = ~ 120 Ko / sec. Je ne vois pas qu'il y ait autant de débit des tentatives infructueuses et l'extrait ci-dessus montre un taux d'attaque beaucoup plus faible (26 en ~ 7 minutes).

user9517

Si ce sont les causes de l'utilisation de la bande passante, la bande passante est déjà consommée au moment où vous les traitez sur votre système. Vous pouvez utiliser un outil comme iptraf pour vous donner une ventilation de ce qui se passe sur chaque interface / port, puis vous pouvez prendre les mesures appropriées en fonction des faits.

user9517
la source

Évidemment, je peux mettre mes efforts sur la prévention de la consommation future de bande passante, à partir du mois à venir

usr-local-ΕΨΗΕΛΩΝ

Et ... réponse très utile, mais iptraf ne fonctionne pas avec OpenVZ (référence webhostingtalk.com/showthread.php?t=924814 ) et je ne l'ai pas mentionné :)

usr-local-ΕΨΗΕΛΩΝ

L'idée de base reste la même. Trouvez quelque chose qui vous dira où est l'utilisation, puis résolvez le problème. Tout le reste est une conjecture.

user9517

Non, ces tentatives de connexion une fois par seconde ne vont pas ajouter jusqu'à 4 Go en dix heures. Pensez-vous que vous pourriez télécharger un fichier de 4 Go en 10 heures en obtenant un petit paquet une fois par seconde? Il y a 3 600 secondes en une heure, donc si vous obtenez un kilo-octet par seconde pendant 10 heures, ce serait 36 000 Ko, ou 36 mégaoctets.

Votre bande passante est mesurée en fonction de ce qui descend de la conduite de votre fournisseur à votre routeur externe, et non de ce qui atteint votre serveur. Vous devez regarder la merde qui n'atteint pas votre serveur, que la plupart des équipements externes rejettent.

En ce qui concerne ce qui arrive à votre serveur, vous ne pouvez pas vous fier aux journaux des applications. Même les paquets qui sont supprimés en silence par le pare-feu local sont de la bande passante. Les statistiques de l'interface (indiquées par ifconfig) vous indiqueront les octets Tx / Rx.

Kaz
la source

Pas certain. De mon point de vue, les messages de journal montrent que les clients ont ouvert un socket sur le port 22 mais ont été rejetés car "ce qu'ils ont transmis" n'était pas reconnu comme une poignée de main SSH appropriée. Je ne voulais pas mettre le port 22 sur écoute pour voir la charge utile réelle envoyée par les scanners, mais en théorie, ils pouvaient envoyer des tonnes de déchets jusqu'à ce que SSH tombe. La question est: quand openSSH abandonne une poignée de main invalide? Deuxièmement, j'ai passé une nuit avec Tor désactivé et le trafic a toujours augmenté (Apache n'a pas montré de trafic significatif), lorsque le trafic fail2ban reconfiguré a presque cessé

usr-local-ΕΨΗΕΛΩΝ

Permettez-moi de reformuler un peu, juste au cas où. Si je voulais drainer 4 Go de bande passante d'un serveur, je pourrais créer un botnet qui ouvre des connexions HTTP et envoie des charges utiles POST illimitées pour chaque demande. Les journaux montreront que les demandes ayant échoué se produisent avec des taux bas, mais chacune est extrêmement lourde. Mais cela commence à perdre son sens. Je connais bien les scans SSH ("échec d'authentification pour root, admin ...") car leur objectif est de prendre le contrôle du nœud. Pourquoi un attaquant voudrait vider la bande passante via SSH? Ça n'a pas de sens. À moins que quelqu'un déteste les nœuds Tor ...

usr-local-ΕΨΗΕΛΩΝ