Question:
Port Knocking est-ce une bonne idée?
Mark Davidson
2010-12-16 23:22:33 UTC
view on stackexchange narkive permalink

Normalement, pour un serveur, j'aime verrouiller SSH et d'autres services non publics pour qu'ils ne soient accessibles que par certaines adresses IP. Cependant, ce n'est pas toujours pratique si l'entreprise ne dispose pas d'adresses IP statiques ou si des développeurs extérieurs ont besoin d'y accéder.

J'ai entendu parler de Port Knocking il y a quelque temps et j'ai enfin eu la chance de l'examiner comme une solution au problème ci-dessus. En conséquence, j'ai une foule de questions sur lesquelles j'espère que les gens pourront m'aider.

  • Quelqu'un l'a-t-il déployé au sein de son entreprise / organisation et peut-il offrir des conseils?
  • Quel est le meilleur démon de frappe à exécuter sous Linux?
  • Quels sont les meilleurs clients pour Linux, Windows et OSX?
  • Quelle est la longueur recommandée pour la séquence de cliquetis et est-il préférable d'utiliser TCP, UDP ou les deux?
  • Quels sont les inconvénients et problèmes associés à son utilisation?
  • S'agit-il simplement de la sécurité par l'obscurité?
  • Existe-t-il des alternatives à l'approche de frappe au port?
La sécurité par l'obscurité?Ce n'est guère un fait.Plus comme la sécurité grâce à la politique.
Sept réponses:
#1
+35
Michael Trausch
2010-12-17 02:53:46 UTC
view on stackexchange narkive permalink

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.

+1, très belle réponse - et m'a donné au moins une meilleure idée de la frappe au port.
Si vous êtes suffisamment préoccupé par la sécurité pour envisager le cliquetis de port, pourquoi ne pas simplement opter pour une véritable authentification à deux facteurs au lieu d'ajouter une autre couche d'authentification en texte brut?
Je suis absolument d'accord. Parmi les options que j'envisage pour le déploiement dans ma configuration réseau, il y a les jetons cryptographiques et les tampons uniques.
S'il s'agit d'un système basé sur Linux (j'imagine que l'approche serait portable pour la plupart des pare-feu de filtrage de paquets avec état), vous pouvez implémenter une solution complète dans iptables - ce qui élimine une grande partie des problèmes de complexité / fiabilité d'un programme en espace utilisateur ou d'un module de noyau personnalisé . Avoir google.
quelque chose comme ça - [en utilisant uniquement iptables] (https://www.digitalocean.com/community/tutorials/how-to-configure-port-knocking-using-only-iptables-on-an-ubuntu-vps) ** ??? **
Le deuxième paragraphe est déroutant, comme d'autres l'ont souligné, seules des solutions noyau existent pour Linux, et vous ne devriez pas avoir à vous soucier du remplissage des journaux car la plupart des logiciels de frappe de port ne nécessitent que 10 minutes de journaux maximum, si votre démon est tué, sshd estva mourir aussi, alors pourquoi est-ce le principal problème?aucune quantité de "pilote du noyau" ne va aider lorsque le système ne répond pas du tout.tout administrateur système à moitié décent peut configurer des limites raisonnables pour les journaux et modifier les politiques de suppression des applications.
#2
+14
Michael Rash
2010-12-17 09:42:11 UTC
view on stackexchange narkive permalink

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

#3
+9
Nakedible
2010-12-18 00:21:13 UTC
view on stackexchange narkive permalink

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.

#4
+8
symcbean
2010-12-17 16:15:37 UTC
view on stackexchange narkive permalink

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.

#5
+8
jl6
2014-05-15 01:56:12 UTC
view on stackexchange narkive permalink

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.

C'est correct ... bien que cela ne réponde pas à la question, il répond que tous les autres commentaires jusqu'à présent prétendent que le knocking est un mécanisme d'authentification qu'il remplace un autre mécanisme.Ce n'est pas le cas: c'est simplement un moyen d'exécuter une commande à partir d'une séquence pw semi-secrète.En règle générale, la commande consiste à autoriser la connexion d'un port à ... l'une ou toutes les autres couches d'authentification restent intactes.La question n'impliquait pas qu'elle serait utilisée comme mécanisme d'authentification unique.
#6
+4
Tok
2010-12-17 20:14:51 UTC
view on stackexchange narkive permalink

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.

Cela a changé cependant.
#7
+2
Alex Holst
2010-12-17 03:53:01 UTC
view on stackexchange narkive permalink

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.

Pour être honnête, les frappes de port sont placées sur SSH, donc ce n'est pas la même chose que telnet. De plus, même s'il s'agit de texte brut, votre attaquant doit maintenant capturer ce mot de passe, puis essayer le SSH brut. Les personnes qui forcent brutalement les comptes SSH ne sont généralement pas les mêmes que celles qui ont des moyens de renifler votre trafic.
La frappe de port n'est pas un mot de passe en texte brut.
Je soumets la section 4 de rfp2k03.txt comme preuve que le port cogné n'est qu'un autre mot de passe. S'il n'y a pas de cryptage, c'est même du texte brut. http://www.wiretrip.net/rfp/txt/rfp2k03.txt
Le lien dans le commentaire ci-dessus est apparu mort, voici une alternative - https://packetstormsecurity.com/files/17647/RFP2K03.txt.html.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...