Journal Espionnage sur le net : des nouvelles du front

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
25
9
jan.
2015

Rien de mieux qu’un espion pour expliquer ce dont les autres espions sont capables. Un article récent du Spiegel explique que la NSA peut casser la plupart de la crypto en usage sur internet : TLS, VPN, SSH, Skype… Pour se protéger des oreilles indiscrètes, il faut paramétrer ses outils avec soin (voir plus bas pour SSH).

Pire : la NSA garde une copie de ce qu’elle ne peut pas déchiffrer dans l’immédiat, au cas où une nouvelle faille lui permettrait d’accéder aux anciennes données. Par contre, il semblerait que la combinaison de plusieurs protections (ex : https dans un vpn) pose un problème pour la NSA, peut-être que ça permet de rester à l’écart de leurs outils d’analyse systématique. Bien entendu, ces informations datent d’il y a deux ans, et ils ont inévitablement progressé depuis. Et reste aussi à savoir s’ils ont la capacité de stocker tout ce qui passe pour l’analyser plus tard…

L’article du Spiegel :
http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html

Comme Gizmo le souligne, « Nous nous sommes habitués à entendre Snowden parler de la surveillance de la NSA. C’est facile d’oublier que c’est avant tout un expert en sécurité informatique ».

En l’occurrence, Snowden considère que la réponse de ceux qui sont soumis au secret professionnel est « incomplète » (patchy). Les avocats, journalistes, docteurs… devraient améliorer leur sécurité, maintenant qu’ils connaissent l’étendue des capacités des espions. Il faut changer de politique et chiffrer par défaut. On ne devrait plus passer en clair que si on a une contrainte de performance sur des données non sensibles.
http://www.theguardian.com/world/2014/jul/17/edward-snowden-professionals-encrypt-client-communications-nsa-spy

Après, il restera toujours le problème de l’interface chaise-clavier… Par exemple, à Bercy on considère encore que « les règles les plus élémentaires de sécurité sont considérées comme superflues et handicapantes, sources de coûts supplémentaires et de perte de temps ». Peut-être les mêmes zouaves qui étaient fanatiques de leur Blackberry, alors qu’on leur répétait que c’était une catastrophe en terme de sécu…
http://lexpansion.lexpress.fr/actualite-economique/espionnage-economique-bercy-est-il-une-passoire_1633989.html

J’ai vu qu’un journal précédent mentionne un article du Monde qui reprend les infos du Spiegel, mais ce journal parlait exclusivement de Tor alors que le problème est bien plus large.
https://linuxfr.org/users/pazelty/journaux/tor-et-la-nsa

Des pistes pour sécuriser ssh sous wheezy, pour pas entrer dans les détails techniques et éviter une recette (comment ça, on est pas sur fmlb ? ;-) ).
http://almin.tf/blog/2015/01/09/proteger-ssh-wheezy-jessie/

Une télé américaine, PBS, vient de rendre disponible la transcription complète d’une interview avec Snowden.
http://www.pbs.org/wgbh/nova/next/military/snowden-transcript/

  • # Étrange...

    Posté par  . Évalué à 1. Dernière modification le 09 janvier 2015 à 18:30.

    J'ai fait exactement comme indiqué dans le paragraphe « Type de clé » de l'article sur la protection de SSH sous Wheezy, pour avoir une clé à 4096 bits au lieu de celle par défaut,et j'obtiens le message d'erreur suivant.

    └─[$]> service ssh restart
    Could not load host key: /etc/ssh/ssh_host_rsa_key
    [….] Restarting OpenBSD Secure Shell server: sshdCould not load host key: /etc/ssh/ssh_host_rsa_key
    . ok

    Il s'agit pourtant d'une Wheezy fraîche d'un mois. ôO

    • [^] # Re: Étrange...

      Posté par  (site web personnel) . Évalué à 10.

      Étrange, est-ce que tu peux nous envoyer la clef pour qu'on je regarde ça ?

      • [^] # Re: Étrange...

        Posté par  . Évalué à 10.

        Oui, bien-sûr. Et le code de ma carte bleue et une copie de la puce ?

    • [^] # Re: Étrange...

      Posté par  . Évalué à 5.

      Aurais tu donné une passphrase lors de la génération de la clef?
      C'est fortement recommandé pour les clefs des utilisateurs mais pas pour celle ci ne sert qu'a identifier la machine.

      • [^] # Re: Étrange...

        Posté par  . Évalué à 1.

        Ha ben oui, c'était con. J'ai un peu honte, du coup. -_-

        • [^] # Re: Étrange...

          Posté par  . Évalué à 6.

          D'un autre coté, l'auteur de l'article aurait pu ajouter -N "" pour éviter l'erreur.

          J'avoue que j'ai été un peu surpris quand le pop-up de passphrase s'est ouvert (outre le fait que je déteste les applications shell qui ouvrent un popup X11).

          • [^] # Re: Étrange...

            Posté par  (site web personnel) . Évalué à 1.

            l'auteur de l'article aurait pu ajouter -N "" pour éviter l'erreur

            Bonne idée, ça évite effectivement que quelqu’un mette une passphrase sur la clé de l’hôte ;)

  • # Il est conseillé de changer de port

    Posté par  . Évalué à 10. Dernière modification le 09 janvier 2015 à 19:28.

    "le port 22 fait l'objet de scans systématiques".

    Autant je suis incompétent en cryptographie, autant pour la sécurité par l'obscurité, je conseillerais vraiment de ne pas faire les choses à moitié et de déplacer vos services HTTPS du port 443 vers un port aléatoire ; on pourra, pour plus de sécurité encore, recompiler ses bibliothèques et logiciels serveurs après avoir changé des mots clefs du protocole afin de vraiment passer sous le radar. Exemple pour HTTP(S) :
    GET → CACAHUETTE
    POST → COINKABOUM
    Il suffit ensuite de recompiler vos clients HTTP (ou dans le meilleur cas des bibliothèques) après y avoir apporté les mêmes modifications mineures pour qu'ils fonctionnent comme avant ; l'inconvénient d'avoir un client par site web est assez léger : on se fait très vite au fait d'ouvrir chaque lien avec un navigateur différent, croyez-moi.

    • [^] # Re: Il est conseillé de changer de port

      Posté par  . Évalué à 10.

      Amusant mais changer le port 22 reste quand même une bonne idée.
      Cela n'augmente pas vraiment la sécurité mais cela évite de poluer les logs avec des milliers ou millions d'entrées inutiles qui rendront les autres tentatives d'intrusions plus difficile à detecter.

      • [^] # Re: Il est conseillé de changer de port

        Posté par  . Évalué à 3.

        C'est vrai. D'un autre côté, le port 22 a l'avantage d'être bien moins souvent bloqué sur les réseaux d'université ou de bibliothèques qu'un autre port plus ou moins aléatoire (à moins bien sûr que la machine avec le serveur SSH n'héberge ni serveur web ni serveur courriel, auquel cas, un passage sur l'un des ports 21/80/443/993, etc peut suffire).

        Je me suis retrouvé bloqué ainsi une paire de fois, et du coup je suis revenu sur le port 22. Bon, maintenant que j'ai accès à un VPN décent, qui me permet de passer outre les bloquages, je pourrais faire marche arrière, mais c'est quand-même lourdingue.

        C'est quand-même chiant de devoir toujours peser le compromis sécurité/utilisabilité.

        • [^] # Re: Il est conseillé de changer de port

          Posté par  . Évalué à 7.

          La sécurité est toujours une affaire de compromis: La sécurité optimale consiste à garder les serveurs éteints, non connectés à Internet et dans une cage de Faraday mais bon … c'est pas super pratique.

      • [^] # Re: Il est conseillé de changer de port

        Posté par  . Évalué à 3.

        De plus, certains robots sont assez bourrins, et peuvent saturer les slots SSH disponibles (bon, comme ils sont rejetés après leur tentative, en insistant on arrive quand même à s'y connecter).

        Sinon, on peut aussi utiliser fail2ban, denyhosts ou équivalent.

        • [^] # Re: Il est conseillé de changer de port

          Posté par  . Évalué à 2.

          fail2ban est très bien mais j'hésite à l'installer.
          Je me suis déjà fait interdire de mon propre serveur (pour seulement 48H heureusement) alors que je testais une installation de svn+ssh
          On ne rigole pas! merci

          • [^] # Re: Il est conseillé de changer de port

            Posté par  (site web personnel) . Évalué à 2.

            Par défaut fail2ban ne bloque que durant 5mn, en cas d'erreur c'est quand même pas la mort… Après si tu changes le paramétrage pour tout bloquer, personne n'y peut rien !

            # "bantime" is the number of seconds that a host is banned.
bantime  = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 600
maxretry = 3

          • [^] # Re: Il est conseillé de changer de port

            Posté par  . Évalué à 4.

            Si tu as accès à une autre IP (3G, autre serveur, connexion du bureau…), c'est vite moins problématique.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Il est conseillé de changer de port

      Posté par  (site web personnel) . Évalué à 2.

      pas faire les choses à moitié et de déplacer vos services HTTPS du port 443 vers un port aléatoire

      Il y a une différence majeure entre https et ssh : le premier s’adresse à des utilisateurs qui peuvent être novices, le deuxième à des sysadmins. Un coup de ~/.ssh/config et c’est transparent dans la plupart des cas, sauf quand on est pas sur son ordi.

      Par contre, il y a deux avantages : ne pas farcir les logs avec des scans de script kiddies, et rendre le trafic ssh un peu moins évident à repérer (à la base, le journal parle des capacités de la NSA). Si on voit un flux chiffré qui passe sur le port 22, on devine tout de suite à quoi on a affaire. Mais un flux chiffré sur le port 23904, well, ça peut être n’importe quel protocole.

      Il suffit ensuite de recompiler vos clients HTTP (ou dans le meilleur cas des bibliothèques) après y avoir apporté les mêmes modifications mineures pour qu'ils fonctionnent comme avant ; l'inconvénient d'avoir un client par site web est assez léger : on se fait très vite au fait d'ouvrir chaque lien avec un navigateur différent, croyez-moi.

      Comparer un changement de port à une modification du protocole… on voit que c’était trolldi hier.

      • [^] # Re: Il est conseillé de changer de port

        Posté par  . Évalué à 2.

        Comparer un changement de port à une modification du protocole… on voit que c’était trolldi hier.
        Beaucoup plus sérieusement, je dénonce la sécurité par l'obscurité et seulement ça. Que changer le port permette d'avoir des logs plus lisible, je trouve que c'est une raison à peu près valable (quoiqu'il commence à y avoir des outils d'analyse de logs pas mal, mais ils sont plus compliqués à installer que juste changer de port.

  • # Pour les anglophone

    Posté par  . Évalué à 6.

    … je conseille de lire cette page:

    https://stribika.github.io/2015/01/04/secure-secure-shell.html

    Après, je ne garantie pas que ces informations ne sont pas un plan machiavélique de la NSA pour accéder à votre collection de film por^ H^ H^ H coquins.

    Quoi qu'il en soit, cette page a le mérite de montrer que c'est un problème complexe.

    ps: Je n'ai pas trouvé l'astuce pour faire des ^ H correct :-(

    • [^] # Re: Pour les anglophone

      Posté par  . Évalué à 2.

      En rajoutant un \ devant ^W (ce qui donne \^W)

      bépo powered

    • [^] # Re: Pour les anglophone

      Posté par  . Évalué à 7.

      Une information que je trouve très intéressante dans cette page est que

      There are basically two ways to do key exchange: Diffie-Hellman and Elliptic Curve Diffie-Hellman. Both provide forward secrecy which the NSA hates because they can’t use passive collection and key recovery later. The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number.

      En pratique, cela signifie qu'il y a une double sécurité: la clef ssh et un échange de secrets (un peu comme dans SSL).

      Même si la NSA (ou autre) enregistre vos communications ssh et casse votre magnifique clef 4096 bits d'ici quelques années, ils ne seront pas capable de décoder les enregistrement.

      Indirectement, cela implique que le décodage en temps réel n'est pas possible même si ils connaissent votre clef ssh.

      Bien sur, dans ce cas, une attaque de type man-in-the-middle reste toujours possible et ils peuvent se connecter à votre place pour installer des programmes espions sur vos serveurs.

  • # En quoi Zoho représent(e/ait) un problème majeur ?

    Posté par  . Évalué à 1.

    Bonsoir.

    Selon l’article de Spiegel :

    The presentation states that the NSA encounters "major" problems in its attempts to decrypt messages sent through heavily encrypted email service providers like Zoho […]

    En quoi Zoho représent(e/ait) un problème majeur pour la NSA ?

    Merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.