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

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?

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!

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 :-)

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

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.

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.

utilisez http://denyhosts.sourceforge.net/

et oui, vous devez utiliser l'authentification par clé publique et désactiver l'authentification par mot de passe.

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 .

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.

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.

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!)

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.

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.

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.

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 .

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.

Oui c'est normal Vous pouvez :

• Réduisez les risques d' attaque en utilisant fwknop

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.

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.

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.

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.

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

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.

• 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