Journal Les toqueurs ont la tactique

Posté par  . Licence CC By‑SA.
41
29
juin
2024

Sommaire

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 3333

Et hop dans la foulée :

ssh seb@192.168.56.2

On 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; done

Ou 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'; done

On 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 knockd

Knockd 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 3333

Et 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  . Évalué à 10 (+20/-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 …

    Host thehost
        HostName myhost.net              
        ProxyCommand bash -c 'knock.sh %h <port1 port2 ... portX>; nc %h %p'
    

    eric.linuxfr@sud-ouest.org

  • # VPN vs port knocking

    Posté par  . Évalué à 7 (+5/-0).

    Joli journal merci.

    Mais, à terme, j’aimerais trouver quelque chose de mieux, peut-être faudrait-il pousser le concept plus loin.

    Comme ça je me dis : un VPN type Wireguard, c'est discret et facile.

    • [^] # Re: VPN vs port knocking

      Posté par  . É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  (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  . Évalué à 7 (+5/-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 :).


        1. 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  . É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  (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  . É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  . Évalué à 3 (+1/-0). Dernière modification le 30 juin 2024 à 19:19.

      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.

      Je vois pas en quoi il réduit un risque qui n'existe virtuellement pas.

      PasswordAuthentication no est 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.

      Il en est de même des mots de passes ou des séquences de port knocking. Ce sont des secrets.

      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

      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.

      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  . Évalué à 1 (+0/-0).

        Donc ils protègent d'un truc que SSH te protège déjà et peut être fragile quand ça devient plus sérieux…

        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  . Évalué à 2 (+1/-1).

          Hmm, déjà ça protège tes logs et ton CPU.

          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.

          Sinon, en quoi ça fragilise ?

          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  . Évalué à 2 (+0/-0).

            J'hésitais a me co, mais… ma foi, ce message expose exactement les arguments que j'aurai.

            J'ai beau lire, je ne vois rien d'autre que l'art d'emmerder les utilisateurs légitimes dans le concept du port knocking. C'est fun. Certes. Peut-être pour un bastion militaire etc ça peut être pertinent.

            Mais franchement, soyons honnêtes, le CPU de mon VPS ultra peu cher chez OVH qui a cramé ne montre jamais ssh avoir un gros taux d'occupation CPU. Quant aux logs… ben, logrotate, non? Je pensais que c'était la base…

            Par contre, il est certain qu'avec cette couche supplémentaire en plus du 2FA que m'offre ma clé ssh, voire 3FA pour accéder au compte root (il faut une connaissance en plus, non?) je vais plus m'emmerder qu'autre chose.
            Je doute que l'impact sur l'utilisabilité vaille le coût (et pas le coup).

            • [^] # Re: Confusion

              Posté par  (Mastodon) . Évalué à 4 (+1/-0).

              je ne vois rien d'autre que l'art d'emmerder les utilisateurs légitimes dans le concept du port knocking.

              Huh. En général ce sont les utilisateurs légitimes qui mettent en place le port knocking.

              • [^] # Re: Confusion

                Posté par  . Évalué à 2 (+0/-0).

                l'utilisateur légitime, ou l'administrateur légitime? C'est pas pareil.

                • [^] # Re: Confusion

                  Posté par  (Mastodon) . Évalué à 4 (+1/-0).

                  Le port knocking, c'est rarement utilisé par des grandes institutions mais plutôt une technique utilisée par celui qui s'autohéberge.

    • [^] # Re: Confusion

      Posté par  . É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  (site web personnel) . Évalué à 3 (+2/-1).

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

      • Yth.
      • [^] # Re: Secret bien gardé

        Posté par  (Mastodon) . Évalué à 3 (+0/-0).

        Encore une fois : ça s'ajoute au reste.

        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  (site web personnel, Mastodon) . Évalué à 7 (+4/-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  (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  (Mastodon) . Évalué à 7 (+4/-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  . Évalué à 8 (+7/-0).

              Effectivement, voler une TV… Vu le niveau des programmes c'est une idée surprenante.

            • [^] # Re: Secret bien gardé

              Posté par  . Évalué à 2 (+1/-1).

              J'ai un bonne porte d'entrée

              Un p'tit coup de meule est si vite arrivé… bon, c'est bruyant, quand même. Pas sûr que le crochetage soit encore très utilisé de nos jours, surtout en ville (badges électroniques et clés "à la con" je sais pas leur nom).

              Rien ne vaut un chien de garde bien aggressif, sauf que s'il bouffe le cambrioleur, t'as intérêt d'avoir de l'acide et une baignoire, parce que la justice va pas aimer :D

              • [^] # Re: Secret bien gardé

                Posté par  . Évalué à 1 (+0/-0).

                Rien ne vaut un chien de garde bien aggressif, sauf que s'il bouffe le cambrioleur, t'as intérêt d'avoir de l'acide et une baignoire, parce que la justice va pas aimer :D

                Oulà, surtout pas la baignoire, il faut utiliser un contenant en plastique !

                (Oui, je sais, trollodi, c’était hier…)

      • [^] # Re: Secret bien gardé

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 30 juin 2024 à 17:48.

        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.

        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  . Évalué à 4 (+2/-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  (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  . Évalué à 2 (+0/-0).

            Le port knocking, ça aurait protégé si la tentative de backdoor via liblzma avait réussi,

            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.

            ou en cas de 0-day sur openssh.

            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  (Mastodon) . Évalué à 4 (+2/-0).

              Probablement pas pour activer la CVE-2024-3094, il faut avoir une clef particulière.

              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  . Évalué à 2 (+1/-1).

                Probablement pas pour activer la CVE-2024-3094, il faut avoir une clef particulière.

                C'est pas la question.

                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.

                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.

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

                C'est une question de compromis.

                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  . Évalué à 3 (+1/-0). Dernière modification le 02 juillet 2024 à 18:40.

                  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.

                  Pire, même. Trop d'emmerdes, et les utilisateurs légitimes vont chercher, et trouver, et partager sans retenue, le moyen de contourner un maximum de "sécurités".

                  La sécurité par l’emmerdement, c'est encore pire que la la sécurité par l'obfuscation.

                  Qui n'a jamais vu des post-it avec des couples identifiant/code sous les écrans? Des utilisateurs filer leurs cartes et le code pin qui va bien au tech pour qu'il puisse bosser sans demander toutes les 5minutes?

                  • [^] # Re: Secret bien gardé

                    Posté par  (site web personnel, Mastodon) . Évalué à 4 (+1/-0).

                    J'ai vu des codes d'entrée affiché sur des panneaux d'affichage, donc à portée de ma vue d'étrangère à l'entreprise.

                    J'ai vu des stagiaires noter le mot de passe sur un post-it effectivement et mettre le post-it à portée de vue.

                    J'ai vu aussi, dans une entreprise où la DSI était paranoïaque, où toutes les applis étaient en réseau, où il fallait conserver ses fichiers sur le réseau, et où il n'y avait pas moyen de changer son fond d'écran, des logiciels téléchargés et installés sur l'ordinateur. En l'occurrence, la personne que j'avais en stage, m'avait demandé de virer ce logiciel qu'elle avait installé parce qu'elle ne savait pas comment s'en débarrasser.

                    Les failles de sécurité sont loin de n'être que techniques en effet :-)

                    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: Secret bien gardé

            Posté par  . Évalué à 3 (+1/-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.

            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  . Évalué à 3 (+1/-0).

              Je suis pas convaincu. un 0-day sur openssh, c'est comme le dahu, on en parle on en a jamais vu.

              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  (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  . Évalué à 3 (+1/-0).

          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.

          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  . Évalué à 4 (+2/-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

      • [^] # Re: Secret bien gardé

        Posté par  . Évalué à 2 (+0/-0).

        Encore une fois : ça s'ajoute au reste.

        Pour les emmerdes utilisateurs légitimes aussi.

        • [^] # Re: Secret bien gardé

          Posté par  (Mastodon) . Évalué à 2 (+0/-0).

          Non, mais, le port-knocking, tu utilises ça pour toi, chez toi.
          Tu mets pas ça en place pour d'autres utilisateurs : « Alors, il va falloir faire des commandes chelous dans le terminal pour pouvoir avoir accès au webmail. Tout est expliqué dans le mail que vous avez tous reçus la semaine dernière ! »

          Bref.

          Donc si ça t'emmerde, ne le met pas, et dans tous les cas, fais ce qu'il te plaît.

          • Yth.
          • [^] # Re: Secret bien gardé

            Posté par  . Évalué à 2 (+0/-0).

            Vu le ton du billet, j'ai clairement eu l'impression que l'auteur pense que c'est une bonne idée.

            Du coup, si c'est une bonne idée, pourquoi ne pas le faire professionnellement?

            Il est évident vu mes commentaires que j'ai toujours été interloqué par le fait que des gens mettent ça en place, mais oui, ça me regarde pas, tant qu'ils le font pas dans leur boulot (ou sans très bonnes raisons, genre accès a des sites avec des info super sensibles, dans ce cas, ralentir l'attaque, en plus d'autre outils, peut permettre un vrai gain de sécurité, mais on est loin du niveau normal de sécurité je pense)

            • [^] # Re: Secret bien gardé

              Posté par  (Mastodon) . Évalué à 2 (+0/-0).

              Il y a un foultitude de chose que je fais à titre personnel, mais que je ne ferais pas à titre professionnel.

              Par exemple j'ai laissé quelques temps une faille de sécurité dans OpenSMTPD.
              Elle est désactivée par ma configuration, c'est à dire qu'elle est présente, et détectable, mais ne permet pas en pratique son exploitation.

              Ça me permet de voir les tentatives de piratages construites, les scripts que les crackers tentent d'exécuter, et comment ils cherchent à le faire, etc.
              Ils ne peuvent pas effacer leurs traces parce qu'il n'ont en pratique aucun accès.
              C'est fun, et ça permet d'étudier un peu les méthodes pratiques pour exploiter une faille.

              Mais jamais, jamais - jamais - je ne mettrai ça en prod professionnellement.

              J'ai du code qui tourne sous bashttpd.
              C'est fun, amusant, ça remplit son office d'ailleurs.
              Mais non, non, non, jamais professionnellement !

              Jadis, quand on faisait « halt » sous Linux, la machine ne s'éteignait pas, il fallait appuyer sur le bouton pour éteindre.
              Le système se trouve donc dans un état arrêté mais pas éteint.
              Dans cet état là, le kernel est toujours actif, en particulier la configuration iptables.
              Donc tu peux démarrer ta machine, paramétrer le firewall iptables, faire halt, et laisser comme ça.
              Il est impossible de démarrer un processus sur la machine, il n'y a plus d'init, rien, mais le firewall tourne, blocages, port-forwarding, ce que tu veux, ça fonctionne.
              Côté sécurité c'est juste ultra-balaise.

              Bon, je proposerais jamais ça en milieu pro non plus hein.

              • Yth.
  • # Et nftables ?

    Posté par  . É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  . Évalué à 3 (+1/-0).

    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.

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

    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.

    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.

    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 la même chose pour tous les logiciels? Une faille c'est catastrophique, et microsoft je crois pas qu'ils cachent des failles (?)

  • # fwknop

    Posté par  (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 02 juillet 2024 à 16:29.

    Pour alert plus loin, I'll existe une alternative plus récente au toc-toc : l'authentification par paquet unique, http://www.cipherdyne.org/fwknop/

    Ça règle un certain nombre de problèmes du toc-toc, et ça en introduit dans doute un autre : le secret ne peut plus se retenir de tête.

  • # En résumé

    Posté par  (site web personnel) . Évalué à 2 (+1/-1).

    La tactique était « toc » !

    ---> [ ]

    Adhérer à l'April, ça vous tente ?

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.