Bien que je ne l'ai pas encore déployé, je connais de nombreuses personnes qui l'ont déployé. Chacun d'entre eux a noté une réduction significative de la quantité de bande passante consommée par des choses comme les attaques SSH par force brute.

Cependant, cela ne veut pas dire qu'il n'y a pas d'inconvénients. AFAIK, il n'y a pas d'implémentations de frappe de port basées sur le noyau disponibles, ce qui pour moi serait la vraie clé de l'adoption. Les démons de frappe de port reposent sur la lecture des entrées de fichier journal échouées (et filtrées / interdites) à partir d'un système de pare-feu. C'est très bien, mais que se passe-t-il si le système de fichiers est plein? Que se passe-t-il lorsque le démon est tué à cause d'un processus incontrôlable qui consomme la RAM et l'échange du système? Que se passe-t-il si quelque chose d'autre dont l'une ou l'autre de ces deux choses dépend est juste en place et cesse de fonctionner? Vous vous retrouverez probablement avec un serveur auquel vous devrez accéder physiquement. Cela pourrait s'avérer plus coûteux que ce qui est raisonnable, surtout si vous êtes à plus de quelques dizaines de kilomètres du serveur et que vous n'avez personne à appeler pour vous y rendre rapidement.

Un ce que je peux dire, c'est que ce n'est pas "la sécurité par l'obscurité". Le cliquetis de port est une forme d'authentification et, comme tout système d'authentification, il peut être aussi simple ou complexe que souhaité. Quelque chose d'aussi simple que "frapper sur le port 10 000 + realPortNumber" peut être fait, ce qui équivaudrait à une rupture triviale, ou le cliquetis de port pourrait lui-même être utilisé pour transmettre une forme d'authentification réelle (par exemple, 1 bloc de données encodées AES clé dérivée par une autre méthode). Cependant, il ne serait pas possible d'utiliser le cliquetis de port pour transmettre de grandes quantités de données, car cela prendrait beaucoup plus de temps que l'envoi d'un seul paquet, et si le paquet est sur TCP, au moins on peut savoir s'il a été reçu avec succès ou rencontré une forme d'erreur.

Une question intéressante que cela soulève, cependant, est de savoir comment gérer les fichiers journaux - les implémentations du userland nécessitent principalement les fichiers journaux afin de déterminer si oui ou non un coup a été envoyé avec succès, et que se passe-t-il si ces journaux sont fuites? Les données d'authentification deviennent connues, et ce n'est évidemment pas une très bonne chose.

Je ne peux pas vous dire si vous devez ou non utiliser le port knocking dans votre configuration. Je ne le suis pas encore, et je ne suis pas sûr à 100% de le devenir un jour. Il est plus logique pour moi d'utiliser des systèmes d'authentification forte basés sur une cryptographie forte (comme une infrastructure PKI) que de gêner les ports. De plus, ajouter un point de défaillance unique pour accéder aux infrastructures critiques, pour moi en tout cas, semble être une mauvaise idée, et bien plus difficile à prendre en charge correctement avec toute sorte de garantie. Encore une fois, cependant, cela est basé sur la notion du logiciel de frappe de port n'étant pas intégré au pare-feu au niveau du noyau du système d'exploitation; si jamais cela change, je pourrais aussi changer ce que je ressens de son utilisation.

La frappe de port n'est pas simplement un autre mot de passe en texte brut - du moins lorsqu'il est utilisé pour protéger des services qui écoutent sur un port TCP comme SSH. Le cliquetis de port implique que la découverte de service avec nmap n'est plus possible en raison de l'utilisation d'une stratégie de pare-feu par défaut. SSHD a également eu des vulnérabilités exploitables à distance, et celles-ci n'ont rien à voir avec des mots de passe faibles. Je ne veux pas que quiconque puisse lancer nmap et voir que j'écoute SSHD.

De plus, il existe une variante plus puissante du cliquetis de port appelée "Single Packet Authorization", mais c'est aussi un système d'authentification complètement passif afin de conserver les avantages de la frappe de port mais résout ses limitations (les attaques par relecture sont faciles, les attaques DoS sont faciles, etc.).

Il est facile de vérifier que tous les services connectés à Internet présentent des vulnérabilités de sécurité relativement souvent - des services tels que SSH, OpenSSL, etc. Les attaques contre ces derniers sont tentées en masse sur Internet, ciblant tous les systèmes disposant de ports ouverts appropriés.

Les attaques de port, dans mon esprit, ont pour but d'éloigner ces attaquants aléatoires d'Internet, qui recherchent des vulnérabilités génériques. Autrement dit, il n'est pas censé éloigner un attaquant dédié, ni faire partie de la sécurité réelle des services. L'avantage du port knocking devrait être qu'il serait, en fait, assez simple pour qu'il ne soit pas probable qu'il y ait des bogues exploitables, jamais.

Cette utilisation signifie que le port knocking peut être aussi aussi laxiste que possible, du moment qu’il éloigne la majorité des attaquants. Cela peut être simplement la sécurité par l'obscurité, mais une meilleure façon est de l'avoir comme une forme faible d'authentification par "mot de passe".

Le "meilleur" service de frappe de port serait donc une contre laquelle il est inconcevable d'imaginer des attaques contre, mais qui soit suffisamment triviale pour qu'un utilisateur légitime puisse l'utiliser à partir de n'importe quel type de machine client.

D'après mes commentaires ailleurs, bien qu'il existe de nombreuses implémentations qui utilisent toutes sortes d'astuces spéciales pour répondre au coup, cela peut être implémenté uniquement en utilisant iptables sur un système Linux. c'est-à-dire qu'il s'agit en fait d'une implémentation de frappe de port basée sur le noyau

Puisque le coup est visible sur le réseau, l'utilisation de séquences de plus de 3 coups donne peu d'avantages. Je recommande d'utiliser TCP - bien que ce soit plus lent, vous avez de meilleures garanties que le coup a été livré.

Cependant, bien qu'il repose sur des programmes en espace utilisateur, ma préférence est pour fail2ban car il ne nécessite aucune étape / logiciel supplémentaire pour se connecter, fonctionne de manière fiable, et s'il échouait, cela ne m'empêcherait pas d'accéder aux serveurs.

Je suis surpris qu'il y en ait si peu adoption de l'identifiant chiffré - bien que la RFC1413 mentionne simplement cela comme une approche possible utilisant le protocole plutôt que de définir comment il devrait fonctionner.

Mais bien sûr, vous devez vous assurer que vous avez restreint l'accès autant que possible indépendamment de cela (c'est-à-dire pas de connexion root, restreindre l'accès au groupe désigné, si possible, exiger des paires de clés). SSH est conçu pour être sécurisé - et historiquement, il y a eu relativement peu de vulnérabilités dans les implémentations du flux principal. La raison pour laquelle les attaques réussissent est généralement due à une combinaison de noms d'utilisateur devinables, de mots de passe simples et d'attaques par force brute ou d'ingénierie sociale. Notez que je ne vous recommande pas d'appliquer une validation de phrase de passe complexe (autre que la longueur minimale) ni que vous exigez que les utilisateurs continuent de changer leurs mots de passe, il existe de meilleures approches (par exemple à deux facteurs), mais malheureusement très peu d'implémentations.

La frappe de port n'est pas la sécurité par l'obscurité. C'est une défense en profondeur. C'est comme garer votre voiture à côté d'une voiture plus volable - cela ne fera pas grand-chose pour empêcher une attaque ciblée, mais cela pourrait simplement envoyer des opportunistes regarder dans l'autre direction.

Je n'ai pas implémenté le port knocking depuis un certain nombre d'années, cependant, je soupçonne qu'il n'a pas changé de manière significative en principe. D'autres commentaires contiennent de nombreux points valides et je ne vais pas simplement les répéter ici.

Un aspect du port knocking que j'ai toujours implémenté naturellement est de baser la séquence de knock sur un pseudo-aléatoire mais répétable valeur, telle que la date et l'heure actuelles. Cette stratégie n'élimine pas en gros le danger d'une attaque de relecture, cependant, elle limite l'exposition d'une séquence de frappe donnée. Évidemment, pour que cela réussisse, une heure synchronisée, dans mon exemple, la source serait nécessaire pour la cohérence.

Port Knocking n'est qu'un autre mot de passe en texte brut. Il peut être forcé, découvert, capturé et rejoué comme tout autre mot de passe en texte brut. Pourquoi réinventer les connexions telnet?

Vous devez faire confiance à quelque chose. Supposons donc que vous ayez confiance dans la pile réseau de votre système d'exploitation et que vous faites confiance à sshd lors de l'exécution avec une compression retardée, une séparation des privilèges et n'autorise qu'une forme raisonnable d'authentification à deux facteurs (par exemple, basée sur une clé).

Vous pouvez utiliser des services "simples" comme sshd qui invoque authpf pour protéger vos services plus complexes et vulnérables.

authpf vous permet de modifier vos ensembles de règles de pare-feu en fonction de qui s'authentifie avec succès contre sshd, donc seules les adresses IP qui parviennent à se connecter à vos passerelles ssh sont autorisées à se connecter à votre ferme de compilation / calcul / base de données.