Sommaire
- Que l'obscurantisme retourne à l'obscurité
- L'obscurité c'est pas bien: démonstration
- Complètement toqué, ce mec-là !
- Les trois coups
- Cerbère de la porte, ou maitre des clés ?
- De l'art de frapper à la porte
- knockin on heaven's door
- Obscurité, pas obscurantisme
- Et sinon, futés ou pas ?
Que l'obscurantisme retourne à l'obscurité
La sécurité par l’obscurité, vous connaissez ? Ça se résume simplement : il faut savoir tenir sa langue. Chut, c’est un secret ! Pour s’assurer qu’un système, logiciel ou protocole de sécurité est sûr, il suffit de ne pas divulguer son fonctionnement. Pratique ! Et si on veut faire de la rétro-ingénierie ? Pareil, on chiffre le code, on fait de l’obfuscation, on rajoute volontairement des bêtises pour tromper l’ennemi, etc.
Est-ce que ça fonctionne ? Parfois oui, parfois non. Ça fonctionne jusque’à ce que quelqu’un trouve le secret ! Auquel cas la sécurité disparait totalement s’il est rendu public.
Est-ce une bonne idée ? Non, bien évidemment. C’est d’ailleurs un excellent argument pour les logiciels libres et Open Source, la disponibilité du code permettant de l’auditer. Les failles de certains protocoles réseaux, certains logiciels et certains systèmes d’exploitation, notamment Windows dans ses grandes heures, sont un exemple concret des dégâts qui peuvent être causés quand l’éditeur ou le concepteurs mentent sur le niveau de sécurité de leur produit ou pire, cachent volontairement les failles. C’est vraiment se moquer des hackers et autres experts en sécurité (coucou les redteamers !).
L'obscurité c'est pas bien: démonstration
Pour bien comprendre le principe général, imaginez que vous, Charlie, vouliez échanger des messages secrets avec votre ami Lulu (toute ressemblance avec des personnages réels ne serait que fortuite), mais via un forum ou un chat publics. Vous définissez un code secret : le A devient N, le B devient 0, et ainsi de suite. Et vous postez donc :
Yn gevohar rfg ha ercnver qr qnatrerhk rkgerzvfgrf
Votre ami connait le code, et peut le décoder. Mais les autres eux, n’y voient de du charabia. Pendant un certain temps, ça fonctionne. Un inconnu, frustré, décide de s’y attaquer. Il remarque des groupes de mots (les espaces, hein), et devine qu’un code de César (une substitution) est en place. Il essaie les combinaisons, et finit par trouver qu’il y a un décalage de 13 caractères par rapport à la position de chaque lettre dans l’alphabet. Il décode le message :
La tribune est un repaire de dangereux extremistes
Puis il évente le secret dans un message public : Hey, voici comment décoder les messages de Charlie et Lulu ! Et voila, tout le monde le sait, les messages passés et présents sont maintenant totalement lisibles. Fini la sécurité !
Complètement toqué, ce mec-là !
Et pourtant, il existe quelques méthodes sympathiques ou l’obscurité peut rendre quelques services. Vous avez tous vu, dans des films, séries, dessins animés, ou lu dans un livre ou une BD, l’utilisation de codes secrets quand on frappe à la port :
Toc toc toctoctoc toc toc !
Et on vous ouvre la porte ! Vous avez tapé une séquence, connue de vous un le gardien, et il vous ouvre la porte. Pratique ! C’est ce qu’on appelle le tocage de porte, ou port knocking.
Peut-être exposez-vous un port d’administration permettant l’accès à une machine ou à votre réseau, sur Internet. Prenons SSH. Si vous faites l’erreur d’utiliser des ports prédictives, comme tous ceux qui contiennent des séquences de 2 (22, 2222, 22022, mais un scanner de ports finira peut-être par trouver votre port) il est fort probable que vous voyez des tonnes de traces de tentatives de connexion. Bien sur, vous êtes plus malins que ça, vous avez du fail2ban, vous utilisez des clés de bonne taille, des passphrases, avec un SSH bien configuré (pas de root). N’est-ce pas ?
Les trois coups
Maintenant, imaginez que nous mettions en place un bocage de port (et non pas de porte) : on définit une séquence de ports prédéfinis , par exemple 1111, 2222 et 3333. SSH écoute comme d’habitude sur le port 22. Nous voulons que le port 22 soit accessible uniquement si on toque d’abord sur le port 1111, puis le port 2222, puis le port 3333, dans cet ordre uniquement, et dans un laps de temps donné. Alors, seulement, le port 22 sera ouvert et vous pourrez vous connecter.
Simple sur le papier, mais comment faire ? Eh bien, figurez-vous que le firewall intégré à Linux, Netfilter, le permet, sans besoin de service supplémentaire. Et voici comment faire.
On vérifiera évidemment que les ports sélectionnés ne sont ni déjà utilisés (quoi que…) ni dans dans la plage dynamique (sysctl net.ipv4.ip_local_port_range).
Je n’ai pas appris, ni compris tout seul, pour ça j’ai cherché des sources, comme tout le monde, et la plus sympa est celle de la documentation de Arch Linux, ici : https://wiki.archlinux.org/title/Port_knocking . Mais ce n’est pas simple, alors je vais essayer de vous expliquer.
Cerbère de la porte, ou maitre des clés ?
Si vous n'avez pas la référence c'est ici
Nous allons mettre nos règles dans un fichier de type iptables.rules. En premier lieu, assurons-nous d’avoir une règle qui autorise en entrée les connexions de type RELATED et ESTABLISHED. Il serait bête de se voir couper l’accès une fois le port fermé alors que la connexion est déjà établie. C’est généralement la première, ou l’une d’elles sur les tables INPUT et FORWARD. Ici c’est INPUT. On va créer une table TRAFFIC qui servira de source à INPUT et on va commencer à la remplir :
-A INPUT -j TRAFFIC
-A TRAFFIC —m state --state ESTABLISHED,RELATED -j ACCEPT
Attention ça devient plus compliqué : on autorise l’accès sur le port 22 uniquement si l’adresse IP est contenue dans une liste appelée SSH2. Notez la présence du module « recent »,
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --seconds 30 --name SSH2 -j ACCEPT
Si la même IP a été refusée (la règle précédente n’a pas matché, par exemple plus de 30 secondes), alors on dégage tout, il faut recommencer la séquence.
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH2 --remove -j DROP
Bon, maintenant comment on met l’IP en question dans SSH2 ? Et bien, c’est l’IP qui aura effectué la séquence complète 1111, 2222, 3333, donc l’IP qui sera arrivée jusqu’à 3333. On rajoute une règle pour ce dernier port. Si ça passe on saute aux actions de la table SSH-INPUTTWO, sinon, bah comme précédemment, erreur dans la séquence, on vire l’IP, et il faudra recommencer :
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 3333 -m recent --rcheck --name SSH1 -j SSH-INPUTTWO
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH1 --remove -j DROP
Il y a quoi dans SSH-INPUTTWO ? Tout simplement, on enregistre l’IP dans la liste SSH2 ! On mettra ça à la toute fin, il faudra y penser :
-A SSH-INPUTTWO -m recent --name SSH2 --set -j DROP
Comme c’est la dernière c’est qu’on est arrivé jusque là, et si on est dans les temps alors on peut ouvrir le port 22. Mais pour arriver là, il faut avoir toqué au port 2222, alors on fait pareil, en vérifiant que l’IP est dans SSH0, donc qu’on a toqué dans le port 1111:
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 7777 -m recent --rcheck --name SSH0 -j SSH-INPUT
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH0 --remove -j DROP
Vous devinez bien ce qu’il y a dans SSH-INPUT : on enregistre l’IP dans SSH1, comme ça elle pourra aller toquer sur le port 3333 :
-A SSH-INPUT -m recent --name SSH1 --set -j DROP
Il reste à toquer sur le port 1111, pour remplir SSH0, comme c’est le premier, on a pas a effacer quoi que ce soit, de toute façon qu’on fasse 1111-2222-3333 ou 1111-1111-2222-3333, la seconde contient la première séquence. Si on toque sur 1111, on enregistre l’IP dans SSH0, et donc on sera autorisé à toquer sur 2222.
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 1111 -m recent --name SSH0 --set -j DROP
Et c’est ainsi que si on toque 1111, on à notre IP dans SSH0, donc on peut toquer sur 2222 qui mettra l’IP dans SSH1, donc on peut toquer sur 3333, qui mettra l’IP dans SSH2, et si on a pas dépassé les trente secondes, on peut alors toquer le port 22, qui s’ouvrira. C’est joli !
Accessoirement, pourquoi a-t-on l’impression que les règles sont à l’envers ? Tout simplement parce que Netfilter fonctionne avec une règle de première correspondance : dès qu’il trouve une règle qui correspond (qui « matche »), il s’arrête là. Et donc, il commence par le port 22. Ça passe (IP dans SSH2) ? Non. Suivante, Port 3333, ça passe (IP dans SSH1) ? Non, Suivante, et ainsi de suite. Et donc, ça force par commencer avec 1111 (il s’arrête), puis 2222 (il s’arrête), puis 3333 (il s’arrête), puis le port 22 (il ouvre et s’arrête). Classe non ?
A final, on obtient un fichier potables comme ceci, honteusement pompé de la doc Arch Linux :
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TRAFFIC - [0:0]
:SSH-INPUT - [0:0]
:SSH-INPUTTWO - [0:0]
-A INPUT -j TRAFFIC
-A TRAFFIC -p icmp --icmp-type any -j ACCEPT
-A TRAFFIC -m state --state ESTABLISHED,RELATED -j ACCEPT
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --seconds 30 --name SSH2 -j ACCEPT
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH2 --remove -j DROP
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 3333 -m recent --rcheck --name SSH1 -j SSH-INPUTTWO
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH1 --remove -j DROP
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 2222 -m recent --rcheck --name SSH0 -j SSH-INPUT
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH0 --remove -j DROP
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 1111 -m recent --name SSH0 --set -j DROP
-A SSH-INPUT -m recent --name SSH1 --set -j DROP
-A SSH-INPUTTWO -m recent --name SSH2 --set -j DROP
-A TRAFFIC -j DROP
COMMIT
De l'art de frapper à la porte
Pour toquer, rien de plus simple, il suffit juste de tester le port, ou d’y envoyer ce qu’on veut: nmap, nc, ce que vous voulez. De toute façon les DROP vont tout dégager, et il n’y a aucun service derrière. Donc :
nc -z 192.168.56.2 1111
nc -z 192.168.56.2 2222
nc -z 192.168.56.2 3333Et hop dans la foulée :
ssh seb@192.168.56.2On peut aussi utiliser nmap :
for PORT in 1111 2222 3333 ; do nmap -Pn --host-timeout 201 --max-retries 0 -p $PORT 192.168.56.2; doneOu même le faire en shell pur :
for PORT in 1111 2222 3333 ; do export PORT=$PORT ; timeout 1 bash -c 'cat </dev/null >/dev/tcp/192.168.56.2/$PORT'; doneOn peut bien entendu mettre tout ça dans un script, ou créer des alias.
knockin on heaven's door
Travailler avec règles Netfilter directement directement, ça peut faire peur, et surtout, ce n’est pas pratique ni forcément bien adapté à certaines distributions. On peut certes coder un générateur, en quelques lignes de code, ce n’est pas très compliqué. Pourquoi ne pas utiliser un service qui gère ces règles à notre place ? On va utiliser knockd, disponible dans toutes les bonnes distributions, au hasard, Ubuntu 24.04.
Une fois installé, nous modifions le fichier /etc/knockd.conf :
[openSSH]
sequence = 1111,2222,3333
seq_timeout = 5
command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags = syn
Cinq secondes pour la séquence, puis 10 pour accéder au port 22. On modifie aussi /etc/default/knockd pour mettre la bonne interface :
KNOCKD_OPTS="-i enp0s3"
Et on démarre :
sudo systemctl restart knockdKnockd vient avec la commande knock, pour jouer la séquence. Normalement, on peut aussi utiliser nc, map, ou même bash pour toquer sur les ports, mais (j’ai eu la flemme de chercher pourquoi, en tout cas depuis mon Mac), ces andouilles envoient plus d’un SYN malgré les flags qui vont bien. Par contre, aucun souci avec knock : on teste la séquence :
knock 192.168.56.2 1111 2222 3333Et on obtient :
juin 28 20:18:46 ubuntu knockd[2144]: 192.168.56.1: openSSH: Stage 1
juin 28 20:18:46 ubuntu knockd[2144]: 192.168.56.1: openSSH: Stage 2
juin 28 20:18:46 ubuntu knockd[2144]: 192.168.56.1: openSSH: Stage 3
juin 28 20:18:46 ubuntu knockd[2144]: 192.168.56.1: openSSH: OPEN SESAME
juin 28 20:18:46 ubuntu knockd[2368]: openSSH: running command: /sbin/iptables -I INPUT -s 192.168.56.1 -p tcp --dport 22 -j ACCEPT
Et voila ! Le port est ouvert ! Mais dépêchez-vous, sinon :
juin 28 20:18:56 ubuntu knockd[2368]: 192.168.56.1: openSSH: command timeout
juin 28 20:18:56 ubuntu knockd[2368]: openSSH: running command: /sbin/iptables -D INPUT -s 192.168.56.1 -p tcp --dport 22 -j ACCEPT
Alors on peut faire ça :
$ knock 192.168.56.2 1111 2222 3333 && ssh seb@192.168.56.2
Welcome to Ubuntu 24.04 LTS (GNU/Linux 6.8.0-36-generic x86_64)La commande knock est disponible sous Linux et MacOS et on trouve des outils adéquats pour Windows aussi.
Obscurité, pas obscurantisme
Et voila. Vous avez implémenté votre méthode de sécurité par l’obscurité.
Un intrus peut-il déduire la séquence utilisée pour ouvrir le port ? S’il est malin, oui. Un sniffer permet d’intercepter le trafic réseau. Si le hacker est bien positionné, on peut imaginer que l’analyse des trames lui donne la réponse, notamment s’il remarque qu’elle aboutit systématiquement sur du trafic plus important sur le port SSH que vous aurez choisi. Cependant la plupart des bots sont heureusement stupides, ils tenteront juste de tester plusieurs ports et des paires d’identifiants et de mots de passe une fois trouvés.
Le port knocking n’est donc pas une solution de sécurité à utiliser seule. Dans l’exemple du code de la porte, le gardien aurait pu demander un mot de passe. Elle vient en complément d’autres méthodes de sécurité. On appliquera notamment le principe de Kerckhoffs : la sécurité repose sur le secret de la clé. Oui, la clé est un secret, mais ce n’est pas de la sécurité par l’obscurité : même si on dispose du code source, de l’algorithme de chiffrement, ou d’une capture des trames réseau, il est impossible, par rétro-ingénierie, de retrouver la clé, rendant impossible le décodage. Pour SSH, vous utiliserez donc le chiffrement asymétrique, avec une paire de clés publiques et privées. Ceci garantira la confidentialité des échanges et l’authenticité du correspondant. Clients et serveurs SSH négocieront ensuite l’utilisation d’un cipher, algorithme de chiffrement, cette fois symétrique, via la génération de plusieurs clés, mais c’est une autre histoire.
Et sinon, futés ou pas ?
Et en pratique, quel a été l’effet du port knocker ? Et bien comme prévu les bots ne sont pas futés. J’ai routé les ports depuis ma box vers une machine virtuelle (pontée sur l’interface de l’hyperviseur). Et j’ai attendu. Lors de mes essais, sur d’autres ports et sur plusieurs jours, il n’y a eu plus aucune tentative de connexion à part les miennes. Plus aucune trace du service ssh, sauf mes connexions, plus rien via journalctl. Evidemment, ssh est lui-même sécurisé, réduisant le risque en cas de tentative d’intrusion : port peu commun, clés, passphrases, interdiction de root, etc. Mais, à terme, j’aimerais trouver quelque chose de mieux, peut-être faudrait-il pousser le concept plus loin. On pourrait imaginer des variations dans la temporisation, ou que l’appel au dernier port fournisse une valeur qui une fois décodée représenterait le port, variable, du service à ouvrir.
Si vous voulez aller plus loin, notamment si vous exposez vraiment un service SSH sur Internet, pensez à un honeypot : exposez fièrement un serveur SSH bidon sur les ports habituels, serveur totalement déconnecté du reste, rempli de trucs qui semblent appétissants. Ca attirera les méchants comme des mouches, vous laissant le temps de les détecter et d’agir. Il existe des kits complets pour ça (faites vos recherches, je ne contracte pas). Il y a aussi ce petit outil sympa qui va volontairement casser les pieds , https://github.com/skeeto/endlessh.
# Automatiser le knock depuis ssh
Posté par rycks . Évalué à 10 (+16/-0).
Voir sur https://askubuntu.com/questions/867261/ssh-client-port-knocking-execute-command-before-connecting
il suffit d'ajouter ça dans le fichier de conf de ssh pour lancer de manière transparente le port knocking avant de se connecter en ssh, et c'est ssh qui s'occupe de lancer tout ça …
eric.linuxfr@sud-ouest.org
[^] # Re: Automatiser le knock depuis ssh
Posté par Sébastien Rohaut . Évalué à 5 (+3/-0).
Merci, c'est très pertinent, dommage que je ne puisse pas modifier le journal, je l'aurais rajouté.
# VPN vs port knocking
Posté par cg . Évalué à 6 (+4/-0).
Joli journal merci.
Comme ça je me dis : un VPN type Wireguard, c'est discret et facile.
[^] # Re: VPN vs port knocking
Posté par jseb . Évalué à 3 (+1/-0).
En quoi le VPN dispense t-il du toctoc ? Même probleme que ssh exposé en direct, n'est-ce pas ?
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: VPN vs port knocking
Posté par Colin Pitrat (site web personnel) . Évalué à 7 (+5/-0).
Sur Youtube y'a plein de vidéos qui disent qu'avec un VPN, je crains plus rien. On m'aurait menti?
[^] # Re: VPN vs port knocking
Posté par cg . Évalué à 6 (+4/-0).
Oui, tu peux mettre du port-knocking pour activer le VPN.
Mon message est ambigu, désolé. Dans le cas spécifique de Wireguard, un scan de port ne permet pas de détecter que ce dernier écoute sur un port. Il faut fournir les bons identifiants pour avoir du trafic.
Le VPN permet ensuite de masquer la nature du trafic qui passe dedans, que ce soit du ssh, du https ou autre, ce que ne fait pas le port knocking1.
Bien sûr, une fois le tunnel connecté, un attaquant sur le chemin peut voir que le tunnel existe. La différence avec du port knocking, c'est qu'en sniffant le trafic, tu peux enregistrer et reproduire le toc-toc, alors qu'avec un VPN, tu ne peux pas reproduire l'authentification clé privée/clé publique.
Bref, un VPN bien conçu comme Wireguard me semble une bonne réponse à : "une solution plus robuste" et "pousser le concept plus loin" ;).
En fait, je me dis que le port knocking est une technique qui a du apparaître à une époque à laquelle monter un VPN était un truc compliqué et coûteux en perf.
En espérant être plus clair :).
oui, on peut utiliser ssh commme un tunnel aussi, mais ce n'est pas aussi propre et simple. ↩
[^] # Re: VPN vs port knocking
Posté par jseb . Évalué à 3 (+1/-0).
Oui c'est clair, merci pour votre réponse.
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
# Confusion
Posté par Colin Pitrat (site web personnel) . Évalué à 10 (+9/-0). Dernière modification le 30 juin 2024 à 11:16.
Il semble qu'il y ait une confusion possible à la lecture du journal entre obscurité et secret. Même si il y a une petite phrase au milieu clarifiant un peu.
On peut considérer que le codage de César (ou rot 13 ou autre décalage) se repose sur l'obscurité parce qu'il n'y a que l'algorithme qui protège. Pu on peut considérer que l'algorithme est public (décaler) et que le secret est le nombre de décalages. Dans ce cas c'est juste une très mauvaise solution car il est facile d'essayer toutes les combinaisons. L'exemple est donc assez bancal à mon avis.
Dans le monde de la cryptographie, il y a de nombreux algorithmes de chiffrement/déchiffrement, qu'ils soient symmetriques ou asymétriques, qui sont publics. Mais la clef (privée si asymétrique) doit rester un secret. Ce n'est pas de la sécurité par l'obscurité. C'est le principe même.
Il en est de même des mots de passes ou des séquences de port knocking. Ce sont des secrets. Les principes/algorithmes peuvent être publics sans nuire à la sécurité.
Il reste que si un attaquant a besoin d'acquérir une certaine information avant de pouvoir concevoir une attaque (par exemple que ssh n'est pas sur le port habitué, qu'il faut faire du port knocking, que tel ou tel nom d'utilisateur est utilisé et peut se connecter) cela rend l'attaque plus difficile. Vu le nombre de tentatives de connexions que reçoit un serveur ssh connecté à internet sur le port par défaut, ce genre de technique simple réduit énormément les risques d'exploitation opportuniste. Les plus simples sont beaucoup moins efficace contre des attaques ciblées.
Mais il me semble que là encore, on est un peu à la limite de la sécurité par l'obscurité. Quand on parle de sécurité par l'obscurité, il me semble que c'est plutôt dans le contexte de garder le code source (et éventuellement les algorithmes) secrets afin d'éviter que des gens malintentionnés y trouvent des failles. Le problème c'est que ça empêche aussi des gens bien intentionnés d'y trouver des failles. Et donc les failles y restent. Elles ne sont pas impossibles à trouver cependant, et de nombreux outils peuvent aider à les trouver. Mais oa barrière est plus haute et ve sont en général les gens mal intentionnés qui ont le plus de moyens.
D'ici à conclure que l'open source est plus sûr que le closed source, il n'y a qu'un pas, que je ne franchirais personnellement pas. Autant le code de projets centraux comme Linux est très scruté car trouver une faille critique dedans est très prestigieux pour un chercheur ou ingénieur dans le domaine de la sécurité, autant le prestige diminue très vite avec la baisse de visibilité du projet et l'on se retrouve avec des failles majeures qui peuvent passer inaperçu pendant des années dans des outils pourtant largement utilisés. La récente backdoor dans xz montre même que le caractère opensource peut faciliter l'introduction de backdoor (même si un scénario semblable peut être imaginé dans un environnement closed source et serait d'autant plus difficile à détecter).
[^] # Re: Confusion
Posté par cg . Évalué à 4 (+2/-0).
Il y a une question de périmètre aussi. La sécurité par obscurité ne concerne pas que les logiciels : ne pas divulguer son archi réseau, la marque, la version et l'emplacement des firewalls, etc… C'est de la sécurité par obscurité, et ça complémente - dans une moindre mesure - la qualité des protections en place. Mettre un honeypot, par exemple, ne fonctionne que si tu caches que c'en est un ;).
Ne pas aller raconter sur ton profil LinkedIn que tu viens de décrocher une habilitation SuperAdmin à la DGSI en est aussi.
La page Wikipedia en Anglais le décrit bien mieux que celle en Français
[^] # Re: Confusion
Posté par barmic 🦦 . Évalué à 3 (+1/-0). Dernière modification le 30 juin 2024 à 19:19.
Je vois pas en quoi il réduit un risque qui n'existe virtuellement pas.
PasswordAuthentication noest plus simple et il n'y a déjà plus de probabilité que ces tentatives fonctionnent quand bien même tu en aurais des milliards par jour. Tu peux prendre toutes les clefs mécaniques qui puissent exister pour tenter d'ouvrir une porte si cette dernière s'ouvre via un badge tu n'a aucune chance qu'elle s'ouvre par hasard.Je suis pas sûr qu'un truc que tu balance en clair sur internet puisse être appelé secret. Le moindre wireshark pas trop loin (sur le réseau) de ta machine et le port knocking tombe.
Si on regarde le journal
Donc ils protègent d'un truc que SSH te protège déjà et peut être fragile quand ça devient plus sérieux…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Confusion
Posté par RoyalPanda . Évalué à 1 (+0/-0).
Hmm, déjà ça protège tes logs et ton CPU. En plus ça permet d'avoir des règles strictes pour lever des alertes sur des connexions SSH.
Sinon, en quoi ça fragilise ?
La seule manière que je vois d'introduire une défaillance par ce biais là te demande d'être root sur l'hôte, donc d'avoir déjà le contrôle.
[^] # Re: Confusion
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
L'effet sur ton CPU tu arrive à le sentir ? A minima à le mesurer ? Parce que si c'est du bon sens ça n'est pas un argument.
Ça protège tes logs de quoi ? Leur volume ? On a un paquet d'autres options pour rendre ça parfaitement indolore.
Qui a dis que ça fragilisait ? J'ai dis que le port-knoking ne peut pas faire grand chose face aux formes d'attaque auquel ssh pourrait être sensibles : des attaques ciblées.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Confusion
Posté par arnaudus . Évalué à 3 (+0/-0).
Je me suis dit exactement ça : le port knocking n'a rien à voir avec la sécurité par obscurité. C'est comme si tu avait un mot de passe avant d'accéder au port ssh, la seule "obscurité", c'est que tu ne sais pas forcément que cette couche logicielle est mise en place.
Du coup, mauvais exemple :-)
Après, je ne sais pas s'il existe des études sérieuses sur la force des sécurités par secret/obscurité en conditions réelles. Il y a une forme de sécurité par l'obscurité qui ne me semble pas dénuée d'intérêt à priori, c'est de faire tourner des logiciels inconnus. On pourrait imaginer ça pour des applications militaires, ou même industrielles. Tu ajoutes une couche "maison" avant ou après les sécurités traditionnelles, un logiciel que tu développes en interne, et qui de préférence fait un truc assez simple, mais d'une manière originale. J'ai du mal à voir comment un attaquant peux exploiter une faille dans un logiciel dont il n'a aucune idée du fonctionnement, et donc il n'a accès ni au code, ni au binaire. Même avec un accès, il va falloir qu'il comprenne son fonctionnement et l'étudie spéficiquement; ça fait énormément d'efforts à déployer. Si de tels logiciels existent, personne n'a d'intérêt à les publier.
# Secret bien gardé
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0).
L'attaquant doit donc trouver une séquence courte dans un alphabet de l'ordre de 216 ports. Un intermédiaire verra par ailleurs passer la séquence. Est-ce que ça a plus de valeur qu'un mot de passe, au final ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Secret bien gardé
Posté par Yth (Mastodon) . Évalué à 7 (+5/-0).
Encore une fois : ça s'ajoute au reste.
Ton SSH doit être sécurisé, qu'il soit en frontal sur le port 22, ou derrière un firewall avec port-knocking et autres protections.
L'intérêt majeur du port-knocking ici est de déjoué les scripts, qui vont facilement penser qu'il n'y a aucun accès ssh.
Donc ça te protège efficacement, en plus du reste, contre les attaques à large spectre qui cherchent juste à identifier des cibles à infiltrer.
Mais si c'est toi à titre personnel qui est directement visé, alors un bon attaquant saura chercher ce genre de schémas, et arrivera à déjouer cette couche là de ta protection, ce n'est pas fondamentalement difficile.
C'est un peu comme de mettre du double-vitrage contre les bruits de la rue, ça fonctionne très bien, mais si quelqu'un veut spécifiquement te faire ch…, il monte le son et ça ne sert plus à rien.
Ça ne veut absolument pas dire que c'est inutile, ou inefficace.
[^] # Re: Secret bien gardé
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Oui, la sécurité c'est des couches. Plus tu en as, plus de temps mettra le forcené à te pénétrer (parce qu'il y arrivera tôt ou tard, c'est une certitude).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Secret bien gardé
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Ça me fait penser à une propriété d'un membre de la famille (éloignée d'ailleurs). Le château s'est fait cambrioler plusieurs fois. À chaque fois, forcément, les propriétaires remontaient la protection d'un cran. Les voleurs ont fini par passer par le toit. Je ne peux pas m'empêcher de penser vu qu'à force ils cambriolaient une tirelire vide que ça servait de terrain d'entraînement aux cambrioleurs.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Secret bien gardé
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 30 juin 2024 à 21:46.
L'illustration est très bonne. J'ai un bonne porte d'entrée (l'immense majorité des cambriolages passe par la porte d'entrée), mais j'oublie pas que avec une échelle tu soulèves 3 tuiles, tu balances un grand coup de pied et t'es dans mon salon.
La différence toutefois entre nos deux histoires est l'environnement de chaque maison. J'imagine le château assez isolé par rapport à ma maison où tous les voisins vont trouver ça curieux qqu'un qui monte sur le toit et repart avec ma TV.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Secret bien gardé
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
Effectivement souvent ça passe simplement par la porte. Mon ex belle soeur a tenu la porte en bas de l'immeuble à ceux qui lui volaient sa télé, pensant qu'il s'agissait de voisins déménageant. Très polis les types. Bien sûr ils ne sont pas remontés pour fermer la porte et ils étaient déjà loin quand elle est arrivée à l'étage.
[^] # Re: Secret bien gardé
Posté par cévhé . Évalué à 7 (+6/-0).
Effectivement, voler une TV… Vu le niveau des programmes c'est une idée surprenante.
[^] # Re: Secret bien gardé
Posté par cg . Évalué à 2 (+0/-0). Dernière modification le 30 juin 2024 à 17:48.
Je sais pas pourquoi mais j'ai immédiatement pensé à cette scène de Je suis mort mais j'ai des amis :D. (avancer à 58 secondes pour le moment pertinent)
[^] # Re: Secret bien gardé
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Je pense que l'intérêt du port-knocking n'a jamais étais d'ajouter une couche à SSH. Un SSH bien configuré et facilement a des magnitudes de sécurité supérieures à ce que peu faire du port-knocking. Je pense que son succès vient de fait que ça fait peur aux gens de voir qu'ils ont des tentatives de connexions SSH. Vous avez déjà vu des tentatives par clef ? Si vous n'avez pas autorisé de connexion par mot de passe vous n'avez déjà aucune chance que ces scripts qui tentent à l'arrache passe l'authentification SSH.
Le port-knocking est intéressant pour protéger des choses moins solides qu'un ssh bien configurer. C'est à comparer à faire du port forwarding ssh, du proxy socks ssh ou un VPN.
Pendant que j'y pense en technique pour tenter de disparaitre, j'imagine que simplement passer en IPv6 doit déjà calmer tout le monde surtout si vous utilisez une IP différente pour ssh que pour le serveur web ou mail, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Secret bien gardé
Posté par Buf (Mastodon) . Évalué à 4 (+2/-0).
Le port knocking, ça aurait protégé si la tentative de backdoor via liblzma avait réussi, ou en cas de 0-day sur openssh.
C’est une sécurité supplémentaire qui ne sert probablement à rien en temps normal, parce qu’il y a en effet des protections plus efficaces, mais quand ces protections ont une faille, c’est toujours mieux d’avoir autre chose pour limiter les dégâts.
Bref, faire de la défense en profondeur, avec plusieurs éléments indépendants.
[^] # Re: Secret bien gardé
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Probablement pas pour activer la CVE-2024-3094, il faut avoir une clef particulière. Elle a était conçu et aurait donc probablement dû être utilisé pour des attaques très ciblée, exactement ce pourquoi le port-knocking ne marche pas.
En cas d'attaque pas trop ciblée oui
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Secret bien gardé
Posté par Buf (Mastodon) . Évalué à 3 (+1/-0).
C'est pas la question.
Le fait est, aucun logiciel n'est infaillible, et si on a moyen d'ajouter un niveau de protection indépendant du logiciel de base, ça permet d'éviter d'être vulnérable si un jour la défense principale tombe.
Après, il faut aussi mettre dans la balance la complexité supplémentaire et la facilité d'utilisation, et décider en fonction. C'est une question de compromis.
[^] # Re: Secret bien gardé
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
Pardon c'est toi qui y fait référence. Même sans ça, remarquer que le port-knocking ne change rien à la donne me semble entrer dans le sujet.
Comme tu le dis aucun logiciel n'est infaillible et tu n'es pas à l'abris que ce mille feuille en plus ajoute des potentielles failles (c'est un logiciel aucun logiciel n'est infaillible).
Garder les choses simples aident aussi à améliorer la sécurité. Ajouter une couche et dire que ça peut pas faire de mal, c'est pas suffisant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Secret bien gardé
Posté par octane . Évalué à 2 (+0/-0).
Je suis pas convaincu. un 0-day sur openssh, c'est comme le dahu, on en parle on en a jamais vu. S'il existait, je pense que personne ne s'amuserait à aller exploiter le serveur d'un lecteur de linuxfr. Il irait taper des vraies cibles qui lui ramèneraient de l'argent/de l'information.
Pour lzma, même chose, les cibles auraient été connues et soit c'est un service vaguement public (genre bastion d'entreprise) et là, la séquence de port knock est connue, soit c'est une cible vraiment visée et je pense que l'attaquant prend le temps d'écouter ce qu'il faut pour trouver le port knocking…
[^] # Re: Secret bien gardé
Posté par octane . Évalué à 3 (+1/-0).
eh bin certains matins je ferais mieux de me taire :(
https://www.openwall.com/lists/oss-security/2024/07/01/3
[^] # Re: Secret bien gardé
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 01 juillet 2024 à 12:22.
Ce que je trouve bizarre c'est comment a été géré la publication de la faille. Ils disent qu'ils ont contacté les distros le 20 juin mais le bug pour cette CVE n'a été créé que ce matin chez Fedora par exemple.
En regardant chez debian je n'ai pas l'impression non plus que le package soit prêt.
[^] # Re: Secret bien gardé
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
EDIT: si chez Debian c'est prêt mais seulement pour bookworm et bullseye. Testing et Sid toujours vulnérables.
[^] # Re: Secret bien gardé
Posté par octane . Évalué à 2 (+0/-0).
C'est surtout qu'auditer des journaux remplis de connexions bidons, c'est juste pénible, ça fait perdre du temps.
Avoir un vrai message d'alerte, c'est intéressant.
(bon, moi j'ai mis mon port ssh sur un port improbable, genre pas 22, ni 2222, ni 2022, etc.. et j'ai plus de logs donc je suis content aussi :) )
[^] # Re: Secret bien gardé
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
On audit pas des logs en les lisant ligne par ligne
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Et nftables ?
Posté par Lucky Seven . Évalué à 2 (+1/-0).
nftables ayant été adopté dans certaines distro, quelqu'un connaîtrait l'équivalent d'iptables ? Si c'est possible ?
Sinon ce que j'aime bien faire c'est mettre SSH sur un autre port et installer un tarpit sur le port 22. Exemple d’implémentation : https://github.com/skeeto/endlessh
# Au sujet de l'obscurité
Posté par octane . Évalué à 2 (+0/-0).
Bah imaginons un code. Tu l'obscurcis. Quelqu'un le désobscurcit. La sécurité revient au niveau initial. Donc la sécurité n'est pas nulle… Imaginons que je prenne ssh, j'en fais une version propriétaire, sans code source. Je compile et diffuse les binaires. Si tu l'analyses et tu la reverses, est-ce que la sécurité est nulle lorsque tu te rends compte que le code source est lisible?
Ce qui est surprenant, c'est que dans la suite tu dis toi même que le port knocking c'est de l'obscurité, mais que si quelqu'un le dévoile alors la sécurité est toujours présente (ssh)…
ah bah, cf libzlma, xz, Jia Tan et tout. Le code était public et c'est finalement en black box que le bug a été découvert. Au delà d'un niveau de complexité, closed source == open source. Et le kernel est incroyablement complexe.
C'est la même chose pour tous les logiciels? Une faille c'est catastrophique, et microsoft je crois pas qu'ils cachent des failles (?)
[^] # Re: Au sujet de l'obscurité
Posté par Buf (Mastodon) . Évalué à 3 (+1/-0).
C'est pas forcément cacher, mais ignorer jusqu'à ce que ça ait été exploité de façon catastrophique, ça compte ?
https://www.propublica.org/article/microsoft-solarwinds-golden-saml-data-breach-russian-hackers
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.