Est-il normal de faire des centaines de tentatives d'effraction par jour?


196

Je viens de vérifier le contenu de mon serveur /var/log/auth.loget de constater que je reçois plus de 500 notifications de tentative de mot de passe / tentative d'intrusion en échec par jour! Mon site est petit et son URL est obscure. Est-ce normal? Devrais-je prendre des mesures?


2
Jusqu'à ce que nous verrouillions tous les ports externes inutiles, je me souviens que non seulement nous avions eu beaucoup de tentatives de piratage, mais qu'un jour, c'était tellement grave que nous étions piratés de deux pays différents - en même temps! Alors oui, des centaines de tentatives d'effraction sont parfaitement normales.
Django Reinhardt

91
Nous avons des serveurs qui subissent une nouvelle "séquence" d'attaque toutes les 16 secondes. Une séquence unique est généralement un lot d'environ 100 tentatives sur différents ports. Juste pour le plaisir un jour, j'ai allumé un serveur non corrigé en dehors de notre pare-feu; il a fallu moins de 10 minutes à partir du moment où il a été allumé pour obtenir le mot de passe. Le point est l'Internet est vraiment une jungle; essayez de ne pas vous faire manger.
NotMe

2
Je peux voir que j'ai posté ma question sur le mauvais site: superuser.com/questions/200896//
Justin C

6
Bien que je sois d’accord avec d’autres, c’est normal sur les ports communs requis (80, 443). J’ai pratiquement éliminé ces tentatives contre mon port SSH en changeant simplement le port par défaut de 22 en quelque chose d’obscur tel que 6022 par exemple. Rien que cela, à lui seul, a presque éliminé 99% de ce type d’attaque.
Kilo

2
Si vous envisagez de modifier votre port SSH, des raisons de sécurité vous poussent à le maintenir sous le port 1024 (seul le compte root peut ouvrir les ports <1024 afin de vous protéger des autres utilisateurs qui détournent SSH).
Brendan Long

Réponses:


207

Malheureusement, sur Internet, c'est tout à fait normal. Des hordes de réseaux de zombies tentent de se connecter à chaque serveur trouvé sur des réseaux IP entiers. Ils utilisent généralement des attaques par dictionnaire simples sur des comptes connus (tels que les comptes root ou certains comptes d’applications).

Les cibles d'attaque ne sont pas trouvées via des entrées Google ou DNS, mais les attaquants essaient simplement toutes les adresses IP d'un sous-réseau donné (par exemple, des sociétés d'hébergement de serveurs racine connues). Donc, peu importe que votre URL (d'où l'entrée DNS) soit plutôt obscure.

C'est pourquoi il est si important de:

  • interdire la connexion root dans SSH ( howto )
  • utilisez des mots de passe forts partout (également dans vos applications Web)
  • pour SSH, utilisez si possible l’authentification à clé publique et désactivez complètement l’authentification par mot de passe ( howto )

De plus, vous pouvez installer fail2ban, qui analysera l'authlog. S'il détecte un certain nombre de tentatives de connexion infructueuses à partir d'une adresse IP, il ajoutera cette adresse IP à /etc/hosts.denyou iptables / netfilter afin de verrouiller l'attaquant pendant quelques minutes.

Outre les attaques SSH, il est également de plus en plus courant d’analyser votre serveur Web à la recherche d’applications Web vulnérables (certaines applications de blogage, CMS, phpmyadmin, etc.). Assurez-vous donc également de les garder à jour et correctement configurés!


21
Des applications telles que fail2ban peuvent beaucoup aider à empêcher "temporairement" ces robots de frapper votre serveur à des heures bêtes le matin :-) J'ai le mien mis en place pour interdire 3 tentatives incorrectes pendant 24 heures.
emtunc

46
Et déplacez le port de ssh de 22 à 222. Cela fonctionne assez bien.
Tom O'Connor

40
+1, authentification par clé publique uniquement :)
0xC0000022L

3
@STATUS_ACCESS_DENIED: les actions entreprises par fail2ban ne sont que des listes de commandes shell à exécuter. Il est donc très flexible et facile de faire fonctionner correctement toute configuration personnalisée. La meilleure référence est de le télécharger et de le regarder action.d/iptables.conf.
Mattdm

4
Bloquer de tels attaquants est une perte de temps. Si vous désactivez la connexion root, il y a de fortes chances que personne ne devine même votre nom de connexion correct, et encore moins votre mot de passe. SSH lui-même limite déjà le nombre de demandes de mot de passe, donc même s’ils connaissent votre nom d’utilisateur (les robots aléatoires ne le sauront pas), si vous avez un mot de passe correct, ils ne le devineront jamais.
Brendan Long

58

Quelques 100, c'est très bien ... Le mois dernier, j'ai découvert qu'un de mes serveurs avait échoué 40 000 fois. J'ai eu la peine de les tracer: Carte

Une fois que j'ai changé le port ssh et mis en œuvre Port Knocking, le nombre est tombé à 0 :-)


2
Belle carte. J'aimerais savoir comment faire cela!
Jftuga

9
@ jftuga J'ai d'abord toutes les adresses IP des journaux. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(supprimez le | uniq à la fin si vous voulez autoriser les doublons). Vous pouvez ensuite les placer dans un fichier CSV et le télécharger sur zeemaps.com. J'ai vu de meilleures cartes que les miennes, où ils utiliseraient le décompte pour colorer la carte (vert au rouge pour le nombre de tentatives par comté) mais je n'ai pas encore pensé qu'il en soit une
Bart De Vos

3
Que voulez-vous dire par 'mise en œuvre de port knocking'? Existe-t-il une application que je peux installer via apt-get pour le faire? Le nombre qui passe à 0 semble bien

18
La sécurité à travers l'obscurité a mal tourné. C'est parfait tant que cela fait partie de la stratégie globale plutôt que de la stratégie entière. Après tout, quoi d'autre est un mot de passe autre qu'une chaîne obscure?
Joel Coel

5
@Joel Coel, c'est une chaîne secrète , contrairement à la plupart des problèmes de sécurité liés à l'obscurité - un processus obscur, mais pas nécessairement secret.
tobyodavies

29

Pour ma part, j'utilise un "tarpit" en plus de n'autoriser que l'authentification par clé publique et d'interdire les connexions root.

Il netfilterexiste un recentmodule que vous pouvez utiliser avec ( INPUTchaîne):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Cela signifie que chaque tentative de connexion au port 22 est répertoriée par le recentmodule avec l'adresse IP et d'autres éléments sous le nom "tarpit" (si vous êtes curieux, regardez /proc/net/xt_recent/tarpit). De toute évidence, vous pouvez utiliser d'autres noms.

Pour lister ou supprimer des IP, utilisez:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Ce taux limite les tentatives à 5 en 300 secondes. Veuillez noter que les utilisateurs disposant d'une connexion existante ne sont pas gênés par cette limite, car ils disposent déjà d'une connexion établie et sont autorisés à en créer davantage (même au-delà de la limite de débit).

Ajustez les règles à votre convenance, mais assurez-vous de les ajouter dans cet ordre (c.-à-d. Pour les ajouter, utilisez-les dans cet ordre, en les insérant ensuite dans l'ordre inverse).

Cela réduit énormément le bruit. Il fournit également une sécurité réelle (contre la force brutale) contrairement à la sécurité perçue de la modification du port. Cependant, je recommanderais toujours de changer le port si cela est faisable dans votre environnement. Cela réduira également beaucoup le niveau de bruit ...

Vous pouvez toujours combiner cela avec fail2ban, bien que je me sente parfaitement bien sans lui et uniquement les règles ci-dessus.

MODIFIER:

Il est possible de le verrouiller pour pouvoir ajouter quelque chose comme ce qui suit, qui vous permet de supprimer votre interdiction en frappant sur un port particulier:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

2
J'utilise cela et je parviens à me bloquer de temps en temps, alors vous souhaitez configurer un autre port sur lequel vous pouvez "frapper" pour supprimer votre interdiction.
Benlumley

@benlumley: bon point. Le cognement de port peut être également utile pour changer le port par défaut - ou même les deux à la fois ...
0xC0000022L

@benlumley: vu votre commentaire (maintenant supprimé par Sam). Cela ne me dérange absolument pas si la réponse est modifiée / améliorée;)
0xC0000022L Le

15

Vous pouvez implémenter fail2ban ou des méthodes similaires, telles que le verrouillage de SSH sur votre IP. Malheureusement, les bots tentent de forcer brutalement l'accès tout le temps, alors c'est tout à fait normal, vous devez vous assurer que vous avez un bon mot de passe.


3
Si vous utilisez SSH, envisagez l'authentification par clé publique. C'est un peu plus sécurisé que l'authentification par mot de passe.
Piskvor

12

Oui . C'est tout à fait normal de nos jours.

Veuillez utiliser, si possible, uniquement l'authentification par clé publique à des fins administratives. Générez une clé privée sur votre poste de travail:

$ ssh-keygen -t dsa

Copiez-collez le contenu de ~ / .ssh / id_dsa.pub sur vos serveurs ~ / .ssh / registered_keys (et /root/.ssh/authorized_keys, si vous avez besoin d’une connexion directe à la racine).

Configurez vos serveurs / etc / ssh / sshd_config pour n’accepter que l’authentification par clé publique:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Si vous avez trop de serveurs, vous pouvez utiliser Puppet pour exécuter des clés publiques et des configurations.

Examinez Denyhosts et fail2ban pour bloquer les tentatives de connexion SSH répétées et consultez Snort si vous avez besoin d’un système IDS / IPS complet.


2
Je ne recommanderais pas l'utilisation de l'authentification par clé publique dans SSH pour un accès shell à votre serveur. Si votre poste de travail est compromis ou, pire encore, volé, quelqu'un dispose désormais d'un accès ouvert à vos serveurs sans qu'un mot de passe ne soit nécessaire. L'authentification par clé publique est plus adaptée aux situations dans lesquelles vous avez besoin de quelque chose comme un script ou un programme pour pouvoir accéder SSH à un autre système sans avoir besoin d'un mot de passe. Vous n'avez donc pas à insérer de mot de passe en texte brut dans votre script / programme.
Utilisateur enregistré

5
@Deleted Account: Vous pouvez définir une phrase secrète pour la clé privée SSH.
Phil Cohen

2
Le commentaire "Utilisateur enregistré" est erroné. Juste pour clarifier: toujours définir un bon mot de passe sur votre clé privée, et ne stockez pas la clé privée sur aucun serveur. Conservez la clé privée sur votre propre poste de travail. Une fois que vous avez ajouté la clé à un programme ssh-agent et que vous avez entré votre mot de passe, vous pouvez vous connecter à tous les systèmes sur lesquels la clé publique est installée, sans avoir à ressaisir votre mot de passe. Activez le transfert d’agent dans votre client ssh pour pouvoir vous connecter d’un serveur à l’autre. Obtenir votre clé privée volée est mauvais, mais avec un mot de passe décent, ce n'est pas aussi grave qu'un mot de passe volé.
Martijn Heemels

Bien, ne pensez même pas à stocker les clés privées de l'administrateur sans les chiffrer.
yrk


6

Les tentatives sont mécanisées, donc les chiffres semblent corrects (oui, ils sont élevés par rapport à certains sites et faibles par rapport à d'autres). Vous devez normalement suivre les étapes suivantes: Vous considérez vos sites comme des cibles d’attaque chaque jour, même si vous ne détectez pas d’attaque; ne pas détecter une attaque, ne signifie pas qu'elle n'existe pas .


6

Je dirais que seulement 500, c'est un peu bas.

Chez un ancien employeur, l'un des chercheurs en sécurité informatique a qualifié le flux constant de tentatives d'effraction "d'équivalent Internet du bruit cosmique ". Il a décrit cela comme un flux normal et continu de trafic malveillant cherchant des systèmes sur Internet et exploitant automatiquement les scripts pour tenter de détourner le système. Les réseaux de robots et autres systèmes malveillants analysent et analysent en permanence l’Internet à la recherche de systèmes vulnérables, à l’instar de SETI.


6

Oui,

c'est courant, mais cela ne signifie pas que vous ne devriez pas vous battre comme il se doit. Voici quelques étapes sur la manière de rendre votre serveur plus sécurisé.

Eviter les adresses IP associées au DNS

Vous pouvez réduire considérablement ce nombre dans les environnements partagés ou en colocation en désactivant l'accès SSH sur les adresses IP associées aux noms de domaine. Les adresses IP hors domaine non répertoriées recevront moins de ce type de trafic. Achetez donc une adresse IP non répertoriée et utilisez-la uniquement pour l'accès SSH.

Utiliser un VPN pour tous les accès SSH

Si vous vous trouvez dans un environnement dans lequel vous pouvez implémenter IPsec / VPN sur un réseau privé au sein de votre environnement de serveur, c'est l'idéal. Désactivez tous les accès Internet SSH, assurez-vous de disposer d’une solution d’éclairage intégrée. Configurez votre VPN et n'autorisez l'accès SSH qu'à partir de votre VPN.

Implémenter des règles d'adresse IP pour l'accès SSH

Si le VLAN n'est pas une option, configurez votre routeur ou des règles de pare-feu pour autoriser uniquement les connexions SSH à partir d'une plage d'adresses IP connue.

Si vous suivez ces étapes, vous dormirez beaucoup plus facilement la nuit en sachant que quelqu'un devra compromettre le réseau de votre société d'hébergement pour accéder au serveur via SSH.


5

Assez normal de voir des centaines de connexions SSH échouées.

Si vous avez l'option, je change simplement mon port SSH en quelque chose de non standard. Cela ne rend pas forcément votre serveur plus sécurisé, mais il nettoie certainement les journaux (et vous permet de voir quiconque tente délibérément de s’immiscer!)


5

Outre l’utilisation d’un mécanisme de verrouillage automatique tel que fail2ban, vous disposez d’une option supplémentaire: contactez l’adresse d’abus du fournisseur de services Internet de l’attaquant. Cela peut sembler complètement futile, mais dans le cas du script-kiddie, leur fournisseur de services Internet est plus que disposé à agir contre eux.

Pour trouver l'adresse d'abus, commencez par arin.net et recherchez l'adresse IP à l'aide de whois. Vous pouvez être redirigé vers un autre registre régional, mais vous pouvez éventuellement trouver le fournisseur d'accès Internet responsable du bloc IP contenant l'adresse. Recherchez l'adresse d'abus @ ou envoyez simplement un courrier au contact technique.

Envoyez-leur un message poli avec les entrées de fichier journal appropriées (assurez-vous de supprimer toute information privée) et demandez-leur de prendre des mesures contre l'hôte en cause.


4
Nous avions l'habitude de faire cela. Cependant, le temps passé par rapport aux avantages reçus était si minime que cela importait peu.
NotMe

1
Une variante de cette tactique plus efficace, mais beaucoup plus risquée, consiste à signaler le fournisseur de services Internet au nœud intermédiaire. Mais vous devez avoir la preuve de votre rapport solide. Cela a posé de graves problèmes à tout un fournisseur d'accès, car ils ignoraient leurs rapports d'abus.
staticsan

1
Une fois que j'ai fait cela, le message d'abus est parvenu au pirate au lieu d'un responsable des serveurs. Depuis lors, je ne me dérange plus, juste trop de problèmes.
wump

Cela ne va vraiment pas aider dans la plupart des cas et peut prendre beaucoup de temps
RichVel

4

Je recommanderais de ne pas utiliser fail2ban mais d'exécuter SSH (et d'autres) sur un port non standard. Je ne crois pas à la sécurité par obscurité mais je pense que c'est un excellent moyen de réduire le bruit dans vos journaux.

Les échecs de connexion sur des ports non standard seront rares et peuvent également indiquer des attaques plus ciblées.

Vous pourriez même aller plus loin en installant un pot de miel SSH tel que Kippo pour «laisser entrer» les opposants aveugles et voir ce qu'ils feraient si l'occasion se présentait.


Haha, Kippo a l'air très gentil. Je vais l'installer sur un serveur juste pour voir ce qu'ils essaient de faire.
wump

4

Oui c'est normal Ce que je dis aux clients dans votre situation avec les petits sites Web.

Soyez toujours prêt à être piraté.

Avoir une copie de votre site Web sur un serveur de développement. Cela peut être votre bureau Windows en utilisant XAMPP que vous pouvez obtenir gratuitement.

TOUJOURS apporter des modifications à votre serveur de développement, puis les télécharger sur votre site Web en direct. S'il s'agit d'un CMS tel que Wordpress, faites vos publications sur le serveur de développement, puis copiez-les et collez-les dans le serveur live.

NE JAMAIS rien télécharger de votre site Web en direct sur votre serveur de développement.

Surveillez régulièrement vos pages Web pour vous tenir au courant des modifications que vous n'avez pas apportées. Plus précisément, des liens cachés vers des médicaments ou des produits «d'amélioration». Vous pouvez trouver de nombreux ajouts de navigateur et des programmes qui le feront pour vous.

Si vous êtes compromis. Avertissez votre hôte, supprimez tout, changez tous les mots de passe et chargez votre serveur propre dev sur le serveur Web maintenant vide. Travaillez avec votre hôte pour éviter une récurrence.

Vous ne devriez pas avoir besoin d'une équipe de sécurité pour un petit site. C'est ce que votre hôte est censé fournir. S'ils ne le font pas, obtenez un autre hôte, ce qui est beaucoup plus facile à faire lorsque vous avez un serveur de développement plutôt que d'essayer de déplacer le serveur réel.

J'espère que cela t'aides.


2
+1 pour "Soyez toujours prêt à être piraté."
user78940

3

Une autre façon de l'arrêter (personnellement, je n'aime pas déplacer le port SSH): décidez si vous êtes en mesure de répertorier tous les réseaux auxquels vous souhaitez vous connecter, puis autorisez-les uniquement à accéder à votre port SSH.

Les entrées WHOIS des FAI locaux m'ont aidé à réduire les attaques à une ou deux tentatives de connexion par mois (à l'époque, c'était environ 1k / jour). J'ai détecté ceux en utilisant encore denyhosts .


3

Outre les autres excellentes suggestions que vous avez déjà reçues, j'aime également utiliser la directive AllowUsers si cela est approprié pour le serveur donné. Cela permet uniquement aux utilisateurs spécifiés de se connecter via SSH, ce qui réduit considérablement la possibilité d’obtenir l’accès via un compte invité / service / système mal configuré.

Exemple:

AllowUsers admin jsmith jdoe

L'option AllowUsers spécifie et contrôle les utilisateurs pouvant accéder aux services ssh. Plusieurs utilisateurs peuvent être spécifiés, séparés par des espaces.


3

Oui c'est normal Vous pouvez :

Fwknop est l’une des meilleures implémentations de port knock car elle n’est pas spoofable et elle s’authentifie plutôt que d’autoriser une connexion.

  • Vous pouvez changer le port utilisé par Openssh mais vous n'améliorez pas vraiment la sécurité.

  • Fortifier l'authentification SSH avec Google-Authenticator ou wikid

Cela protégera les attaques basées sur un mot de passe et la possibilité qu'un attaquant déterminé / attaque ciblée compromet votre machine admin et vole votre combinaison ssh-key & password.

Il suffit de regarder la dernière version de pwn2own pour voir à quel point il est facile pour un attaquant qualifié de compromettre votre zone d’administration entièrement corrigée.


1

Malheureusement, c'est tout à fait normal. Vous devriez envisager d'ajouter quelque chose comme fail2ban à votre système pour détecter et interdire automatiquement les attaquants. Si vous ne le faites pas déjà, vous devriez également envisager d'utiliser uniquement ssh avec des clés publiques et ne pas autoriser la connexion root sur ssh. Si vous utilisez ftp pour transférer des fichiers sur le système, utilisez plutôt scp / sftp.


1

J'ai implémenté le port knock, et ai quelques sondes par jour. Ils n'ont pas de connexion, alors ils s'en vont. Je me connecte et signale tous les accès aux ports concernés.

J'ai également lancé fail2ban avec Shorewall comme pare-feu pour mettre temporairement en liste noire les attaquants persistants.

Si vous n'avez pas besoin d'un accès Internet à SSH, désactivez-le. Si vous avez quelques adresses connues nécessitant un accès à distance, limitez l'accès à ces adresses.

Limiter l'accès aux clés autorisées peut également être utile.


0

J'avais l' pam_ablhabitude de mettre temporairement la brute forcer sur la liste noire, et cela fonctionne très bien. Je pense qu'il est préférable d'avoir une autorisation dans PAM utilisant sa propre base de données plutôt que de dépendre de hosts.denyou iptables.

Un autre avantage est que pam_ablcela ne dépend pas de l'analyse des fichiers journaux.


0

C'est complètement normal ces jours-ci.
Vous pouvez définir une limite "rafale" sur le pare-feu pour les nouvelles connexions entrantes sur le port SSH
ou installer l'un des nombreux analyseurs de journal a'la fail2ban ou modifier le port SSH;).

Le dernier est le plus facile. Sur des machines très chargées, de telles tentatives d'intrusion peuvent avoir une très grande influence sur l'ensemble du système.

-
Cordialement,
Robert


0

Oui c'est normal.

Je viens de changer le port ssh en l’éloignant de la norme 22. Mon serveur, mes règles :) éditez simplement / etc / ssh / sshd_config, modifiez le port et redémarrez le service. Le seul inconvénient est que vous devez vous rappeler d'ajouter ce port à la configuration pour chaque client ssh que vous utilisez.


0
  • Désactivez la connexion root (dans chaque système Linux, il existe un utilisateur root afin que les bots puissent facilement deviner son nom). Après vous être connecté en tant qu'utilisateur normal, vous pouvez passer à root soit par su, soit par sudo.

  • changer le port par défaut de 22

  • Autoriser l'accès ssh depuis les adresses IP connues uniquement

  • Utilisez un mot de passe alphanumérique fort pour l'utilisateur ayant un accès ssh

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.