Blocage des attaques SSH Brute Force sur IPv6

J'ai récemment dû travailler avec certains serveurs qui ont une connexion IPv6 et j'ai été surpris de découvrir que fail2ban ne prend pas en charge IPv6, ni les denyhosts. En recherchant sur Google, j'ai trouvé que les gens recommandent généralement:

Désactiver la connexion ssh via IPv6 (pas une solution pour moi)
utiliser uniquement l'authentification par clé privée / publique sur le serveur, sans authentification par mot de passe (fonctionne, mais de nombreuses attaques peuvent coûter beaucoup de puissance de traitement au serveur, ou le rendre même indisponible en le faisant par DDoS)
en utilisant ip6tables pour bloquer les attaques consécutives de la même IP
en utilisant sshguard qui prend en charge IPv6

D'après ce que j'ai rassemblé jusqu'à présent, interdire les adresses dans IPv6 est un peu différent de celui sur IPv4 car les FAI ne donnent pas à un utilisateur une seule adresse (/ 128), mais tout un sous-réseau (j'ai actuellement un / 48). Ainsi, interdire des adresses IPv6 uniques serait inefficace contre les attaques. J'ai cherché haut et bas sur le sujet des sous-réseaux de blocage ip6tables et sshguard sur la détection d'attaque, mais je n'ai pas réussi à trouver d'informations.

Est-ce que quelqu'un sait si sshguard interdit les sous-réseaux sur les attaques IPv6?
Est-ce que quelqu'un sait comment faire une configuration ip6tables pour interdire les sous-réseaux sur les attaques IPv6?
Ou quelqu'un connaît-il un meilleur moyen d'atténuer les attaques que ce que j'ai déjà trouvé?

PS: j'utilise CentOS 7 sur le système.

— DarthRevan13
source

Pour plus d'informations sur l'ajout de la prise en charge IPv6 par fail2ban : github.com/fail2ban/fail2ban/issues/39 . Il semble qu'ils soient confrontés à un problème avec le blocage des sous-réseaux , ce qui retarde la mise en œuvre (il semble s'éloigner de plus en plus de nous en fait ...).

— John WH Smith

Règles de limitation / interdiction des taux dans iptables. Changez votre question pour cela et un couple de rep-putain devrait répondre précisément.

Est-ce un problème hypothétique? J'ai regardé les journaux des tentatives de force brute de quelques serveurs, et chacun d'eux a été tenté sur IPv4. Et je n'ai vu aucun serveur subir trop de charges en raison de telles tentatives lorsque l'authentification par mot de passe est désactivée côté serveur.

— kasperd

@kasperd J'ai eu quelques milliers de tentatives par jour sur IPv6 donc, non, ce n'est pas un problème hypothétique. L'adresse du serveur est publique car elle héberge un site, c'est donc vraiment un vrai problème.

— DarthRevan13

@ user123418 Je vais laisser le titre de la question tel qu'il est pour l'instant, je préférerais vraiment quelque chose comme sshguard en raison du contrôle sur celui-ci par rapport à une règle dans ip6tables. Si personne ne répond dans la semaine suivante, je changerai ma question.

— DarthRevan13

Réponses:

Pour attaquer un serveur, l'attaquant doit d'abord connaître son adresse IP. Avec IPv6, vous aurez tellement d'adresses à choisir qu'il n'est pas possible de trouver la bonne adresse en scannant la plage IP.

Cela signifie que vous pouvez simplement attribuer deux adresses IPv6 différentes à l'interface. Vous laissez le nom de domaine de votre site pointer vers la même adresse IP que d'habitude, et vous laissez sshd écouter uniquement sur la nouvelle adresse IP attribuée.

Après ce changement, connaître le nom de domaine et l'adresse IP de votre site ne donnera pas à un attaquant un accès à votre sshd.

Vous aurez bien sûr besoin d'un nom d'hôte secondaire à utiliser lors de la connexion à l'aide de ssh. Ce nom d'hôte peut avoir beaucoup plus d'entropie qu'une adresse IPv6. Quelqu'un devinant le nom d'hôte de ssh est inconcevable si vous utilisez 63 caractères alphanumériques.

Si quelqu'un découvre l'adresse IPv6 utilisée pour sshd, il vous suffit de déplacer sshd vers une nouvelle adresse IPv6 et de mettre à jour l'enregistrement AAAA. Ensuite, ils doivent tout recommencer.

Si vous craignez qu'un utilisateur ssh légitime puisse divulguer le nom d'hôte et / ou les adresses IP, vous pouvez créer un nom d'hôte différent pour chaque utilisateur auquel accéder avec ssh. Au départ, je les nommerais tous avec un seul nom d'hôte de sorte qu'il n'y ait qu'un seul enregistrement AAAA à mettre à jour.

— kasperd
source

Sonne mieux que ce que j'ai actuellement, mais pas tout à fait ce que je cherchais. Merci quand même.

— DarthRevan13

La bonne nouvelle est que fail2ban a récemment pris en charge IPv6.

Pour les serveurs Debian IPv6, je recommanderais de suivre ce tutoriel .

Pour les serveurs CentOS IPv6, je recommanderais de le télécharger ici , puis d'exécuter ces commandes en remplaçant le numéro de version en conséquence:

tar xvfj fail2ban-0.11.0.tar.bz2
cd fail2ban-0.11.0
python setup.py install

Assurez-vous qu'une prison pour sshd est activée dans /etc/fail2ban/jail.local , par exemple:

[sshd]
enabled=1

— nordinateurs
source

Bien que j'admire ce que les gars de fail2ban ont fait, ce n'est toujours pas suffisant! Toutes les fonctionnalités ne sont pas prises en charge par le protocole IPv6 selon leur journal des modifications github.com/fail2ban/fail2ban/blob/0.10/ChangeLog et il n'y a toujours pas de support pour interdire les sous-réseaux github.com/fail2ban/fail2ban/issues/927, ce qui est crucial pour IPv6 car tout FAI n'offrira pas seulement une adresse IPv6 à un client, mais un sous-réseau entier. Tant que cela reste vrai, aucune machine de production ne devrait utiliser fail2ban maintenant! Veuillez modifier votre réponse pour refléter cela, car cette page est visitée par de nombreuses personnes.

— DarthRevan13