Est-il normal d'avoir des centaines de tentatives d'effraction par jour?
Je viens de vérifier le /var/log/auth.log De mon serveur et j'ai constaté que plus de 500 notifications de mot de passe/tentative d'effraction ont échoué par jour! Mon site est petit et son URL est obscure. Est-ce normal? Dois-je prendre des mesures?
Sur Internet, c'est malheureusement tout à fait normal. Il y a des hordes de botnets essayant de se connecter à chaque serveur qu'ils trouvent dans des réseaux IP entiers. En règle générale, ils utilisent de simples attaques par dictionnaire sur des comptes connus (comme les comptes root ou certaines applications).
Les cibles d'attaque ne sont pas trouvées via Google ou les entrées DNS, mais les attaquants essaient simplement chaque adresse IP dans un certain sous-réseau (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 l'authentification par clé publique si possible et désactivez complètement l'authentification par mot de passe ( howto )
De plus, vous pouvez installer fail2ban qui analysera le journal automatique et s'il trouve un certain nombre de tentatives de connexion infructueuses à partir d'une IP, il ajoutera cette IP à /etc/hosts.deny ou iptables/netfilter afin de bloquer l'attaquant pendant quelques minutes.
En plus des attaques SSH, il est également courant de rechercher dans votre serveur Web des applications Web vulnérables (certaines applications de blog, CMS, phpmyadmin, etc.). Assurez-vous donc de les garder à jour et de les configurer en toute sécurité!
Quelques 100, c'est très bien ... Le mois dernier, j'ai trouvé qu'un de mes serveurs avait 40 000 tentatives infructueuses. J'ai eu la peine de les comploter: Carte
Une fois que j'ai changé le port ssh et implémenté Port Knocking, le nombre est tombé à 0 :-)
Pour ma part, j'utilise un "tarpit" en plus d'autoriser uniquement l'authentification par clé publique et d'interdire les connexions root.
Dans netfilter il y a un module recent, que vous pouvez utiliser avec (chaîne INPUT):
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 module recent avec IP et d'autres éléments sous le nom "tarpit" (si vous êtes curieux, consultez /proc/net/xt_recent/tarpit). Évidemment, vous pouvez utiliser d'autres noms.
Pour répertorier ou supprimer des adresses 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 avec une connexion existante ne sont pas gênés par cette limite, car ils ont déjà une connexion établie et sont autorisés à en créer plus (même au-dessus de la limite de taux).
Ajustez les règles à votre guise mais assurez-vous qu'elles soient ajoutées dans cet ordre (c'est-à-dire lors de l'ajout puis de les utiliser dans cet ordre, lors de l'insertion puis dans l'ordre inverse).
Cela réduit énormément le bruit. Il offre également une sécurité réelle (contre le forçage brutal) contrairement à la sécurité perçue de la modification du port. Cependant, je recommanderais toujours de changer le port si cela est possible dans votre environnement. Cela réduira également beaucoup le niveau de bruit ...
Vous pouvez toujours combiner cela avec fail2ban, bien que je fonctionne très bien sans cela et uniquement les règles ci-dessus.
ÉDITER:
Il est possible de se verrouiller en faisant cela, vous pouvez donc 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
Vous pouvez implémenter fail2ban , ou des méthodes similaires comme verrouiller SSH sur votre IP. Malheureusement, les robots tentent de forcer l'accès à tout moment, il est donc tout à fait normal, vous devez vous assurer que vous avez un bon mot de passe.
Oui . C'est tout à fait normal de nos jours.
Veuillez utiliser l'authentification par clé publique uniquement à des fins administratives si possible. 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/authorized_keys (et /root/.ssh/authorized_keys, si vous avez besoin d'une connexion root directe).
Configurez vos serveurs /etc/ssh/sshd_config pour accepter uniquement l'authentification par clé publique:
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password
Si vous avez trop de serveurs, vous pouvez utiliser Puppet pour leur exécuter des clés publiques et des configurations.
Regardez dans Denyhosts et fail2ban pour bloquer les tentatives de connexion SSH répétées et voir Snort si vous avez besoin d'un IDS/IPS complet.
utilisez http://denyhosts.sourceforge.net/
et oui, vous devez utiliser l'authentification par clé publique et désactiver l'authentification par mot de passe.
Je dirais que seulement 500, c'est un peu bas.
Chez un ancien employeur, l'un des chercheurs en sécurité informatique a appelé le flux constant de tentatives d'effraction "l'équivalent Internet de bruit cosmique ". Il l'a décrit comme un flux normal et continu de trafic malveillant qui recherchait des systèmes sur Internet et exploitait automatiquement des scripts pour tenter de détourner le système. Les réseaux de robots et autres systèmes malveillants analysaient et analysaient perpétuellement Internet à la recherche de systèmes vulnérables, tout comme SETI.
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 prendre les mesures que vous devez normalement: Vous considérez vos sites comme des cibles d'attaque tous les jours, même lorsque vous ne détectez pas d'attaque; ne détecte pas une attaque, ne signifie pas qu'elle n'existe pas .
Oui,
c'est commun, mais cela ne signifie pas que vous ne devriez pas vous battre. Voici quelques étapes sur la façon de sécuriser votre serveur.
Évitez les adresses IP associées au DNS
Vous pouvez réduire considérablement ce nombre dans les environnements partagés ou de colocation en désactivant l'accès SSH sur toutes les adresses IP associées aux noms de domaine. Les adresses IP non répertoriées hors domaine recevront moins de ce type de trafic, alors achetez une IP non répertoriée et n'utilisez cette adresse IP que pour l'accès SSH.
Utilisez un VPN pour tous les accès SSH
Si vous êtes dans un environnement dans lequel vous pouvez implémenter IPsec /VPN à un réseau privé dans votre environnement de serveur, c'est l'idéal. Désactivez tous les accès Internet SSH, assurez-vous d'avoir une solution d'extinction des lumières intégrée. Configurez votre VPN et autorisez uniquement l'accès SSH à partir de votre VPN.
Mettre en œuvre des règles d'adresse IP pour l'accès SSH
Si l'option VLAN n'est pas une option, configurez votre routeur ou les 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 hébergeur pour accéder au serveur via SSH.
En plus d'utiliser un mécanisme de verrouillage automatisé comme fail2ban, vous avez une option de plus: contactez réellement le fournisseur d'accès Internet de l'attaquant. Cela peut sembler complètement futile, mais dans le cas du script-kiddie, leur FAI est plus que disposé à prendre des mesures contre eux.
Pour trouver l'adresse abusive, commencez par arin.net et recherchez l'adresse IP en utilisant whois. Vous pouvez être redirigé vers un autre registre régional, mais vous pouvez éventuellement trouver le FAI responsable du bloc IP qui contient l'adresse. Recherchez l'adresse @ d'abus ou envoyez simplement le contact technique.
Envoyez-leur un message poli avec les entrées de fichier journal pertinentes (assurez-vous de supprimer toute information privée) et demandez-leur de prendre des mesures contre l'hôte incriminé.
Assez normal de voir des centaines de connexions SSH en échec.
Si vous avez l'option, je change simplement mon port SSH en quelque chose de non standard. Cela ne rend pas nécessairement votre serveur plus sûr, mais il nettoie les journaux (et vous permet de voir quiconque essaie délibérément de s'introduire!)
Oui, c'est normal. Ce que je dis aux clients dans votre situation avec de petits sites Web.
Soyez toujours prêt à être piraté.
Ayez 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 comme Wordpress, créez vos publications sur le serveur de développement, puis copiez-les et collez-les sur le serveur en direct.
Ne téléchargez JAMAIS quoi que ce soit de votre site Web en direct vers votre serveur de développement.
Surveillez régulièrement vos pages Web pour tout changement que vous n'avez pas fait. Plus précisément, des liens cachés vers des médicaments ou des produits de "valorisation". Vous pouvez trouver de nombreux ajouts et programmes de navigateur qui le feront pour vous.
Si vous êtes compromis. Avertissez votre hôte, supprimez tout, changez tous les mots de passe et téléchargez votre propre serveur de développement sur le serveur Web désormais 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. Si ce n'est pas le cas, 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 en direct.
J'espère que cela t'aides.
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 l'obscurité mais je pense que c'est un excellent moyen de réduire le bruit dans vos journaux.
Les échecs de connexion sur les ports non standard seront rares et peuvent également indiquer des attaques plus ciblées.
Vous pouvez même aller plus loin en installant un pot de miel SSH tel que Kippo pour `` laisser entrer '' les bruteforcers et voir ce qu'ils feraient si l'occasion leur était donnée.
En plus des autres excellentes suggestions que vous avez déjà reçues, j'aime aussi utiliser la directive AllowUsers si appropriée 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'accéder via un compte invité/service/système mal configuré.
Exemple:
AllowUsers admin jsmith jdoe
L'option AllowUsers spécifie et contrôle quels utilisateurs peuvent accéder aux services ssh. Plusieurs utilisateurs peuvent être spécifiés, séparés par des espaces.
Une autre façon de l'arrêter (car je n'aime pas personnellement déplacer le port SSH): décidez si vous êtes en mesure de répertorier tous les réseaux à partir desquels vous voudrez 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 à 1-2 tentatives de connexion par mois (à l'époque, c'était environ 1k/jour). J'ai détecté ceux-ci en utilisant toujours denyhosts .
Oui, c'est normal. Vous pouvez :
- Réduisez les possibilités d'attaque en utilisant fwknop
Fwknop est l'une des meilleures implémentations de port knock car il n'est pas usurpateur et authentifie en fait par opposition à simplement 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 en utilisant Google-authentificateur ou wikid
Cela protégera les attaques par mot de passe et la possibilité qu'un attaquant déterminé/une attaque ciblée compromette votre machine d'administration et vole votre combo clé ssh et mot de passe.
Regardez simplement la dernière --- pwn2own comp pour voir combien il est facile pour un attaquant qualifié de compromettre votre boîte d'administration entièrement corrigée.
J'ai implémenté le détournement de port 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 exécuté fail2ban avec Shorewall comme pare-feu pour mettre temporairement sur liste noire les attaquants persistants.
Si vous n'avez pas besoin d'un accès Internet pour SSH, désactivez-le. Si vous avez quelques adresses connues qui nécessitent un accès à distance, limitez l'accès à ces adresses.
Limiter l'accès aux clés autorisées peut également être utile.
Malheureusement, c'est tout à fait normal. Vous devriez envisager d'ajouter quelque chose comme fail2ban à votre système pour détecter et bannir 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 vers le système, envisagez plutôt d'utiliser scp/sftp.
Oui c'est normal.
Je viens de changer le port ssh loin de la norme 22. Mon serveur, mes règles :) éditez simplement/etc/ssh/sshd_config, changez le port et redémarrez le service. Le seul inconvénient est que vous devez vous rappeler d'ajouter ce port à la configuration à chaque client ssh que vous utilisez.
Désactiver la connexion root (dans tous les utilisateurs root du système Linux, les bots peuvent facilement deviner le nom d'utilisateur). Après vous être connecté en tant qu'utilisateur normal, vous pouvez basculer vers root soit par su soit par Sudo.
changer le port par défaut de 22
Autoriser l'accès ssh uniquement à partir des adresses IP connues
Utilisez un mot de passe alphanumérique fort pour l'utilisateur avec accès ssh
J'utilise pam_abl pour mettre temporairement sur liste noire les forceurs bruts, et cela fonctionne très bien. Je pense qu'il est préférable d'avoir une autorisation dans PAM en utilisant sa propre base de données plutôt que de dépendre de hosts.deny ou iptables.
Un autre avantage est que pam_abl ne dépend pas de l'analyse des fichiers journaux.
C'est tout à fait normal de nos jours.
Vous pouvez configurer une limite de "rafale" sur le pare-feu pour les nouvelles connexions entrantes sur le port SSH,
ou installez l'un des nombreux analyseurs de journaux a'la fail2ban ou modifiez le port SSH;).
Le dernier est le plus simple. Sur les machines lourdes, de telles tentatives d'effraction peuvent avoir une très mauvaise influence sur l'ensemble du système.
-
Cordialement,
Robert