Forum général.général [OpenSSL/Syslog-ng] encryption de flux en temps réel (vers un fichier)

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
9
avr.
2013

Bonjour,
Dans le cadre de la mise en place d'un proxy SQUID ä des fin "légales" le trafic web est loggé vers un serveur syslog-ng.

Actuellement toute les nuits les fichiers de logs sont "rotatés" et pour des questions de confidentialité encryptés avec OpenSSL et une clé publique. (la clé privée étant conservé par la direction)

via les commandes suivantes:

openssl smime -binary -encrypt -aes256 -in $ARCHIVES/${DATEF}-proxy.log -out $ARCHIVES/${DATEF}-proxy.enc $CERTIFICATE

Malgré tout il reste un problème pour cette solution, c'est le fichier de logs courant qui lui n est pas crypté et est donc lisible par les personnes ayant accés au système (tout un service IT)…

J'aimerai savoir si il etait possible avec OpenSSL d'encrypter le flux de logs en temps réel, en effet on peut utiliser syslog-ng pour que celui-ci "pipe" le flux reçu vers un programme.

Je pense que c'est possible puisque finallement c'est un peu ce que fait SSH… (basé sur un modèle de clé pub/priv)

Donc plusieurs questions:

  • Est ce possible ?

  • Pourrais je continuer à utiliser mon certificat actuel pour crypter le flux en temps réel ?

Par avance merci de vos réponses.

Bien cordialement,

  • # transit en clair sur le réseau ?

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

    De toute manière si tu as accès au système,ça va pas changer grand chose…

    Système - Réseau - Sécurité Open Source

  • # heu si quand meme

    Posté par  . Évalué à 0.

    En ayant acces au systeme je pourrai effectivement bypasser le programme.
    Mais la n est pas la question.

    On peut toujours arriver ä faire que…

    Mais je veux savoir si c est possible ou non d encrypter des stream en temps réel vers un fichier

  • # transit en clair -> non

    Posté par  . Évalué à 0.

    Les logs ne transitent pas en clair :) j ai montö un tunnel openvpn et je fais passer le traffic par l interface tun (crypté)

  • # Vocabulaire

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

    Encrypter, encryption, ce n'est pas du français. Crypter mon plus. On chiffre, et ça s'appelle du chiffrement.

    • [^] # Re: Vocabulaire

      Posté par  . Évalué à -2. Dernière modification le 09 avril 2013 à 14:50.

      arf c'est fou le nombre de commentaire non constructif, je pose une question technique un peu poussé tout de suite c'est des réflexions sur le vocabulaire, sur comment je pourrais ne pas solutionner mon problème mais aucunne réponse technique…

      Alors Mr Tanguy hormis cette expertise hors du commun sur le vocabulaire, des compétences en "chiffrement" ?

      • [^] # Re: Vocabulaire

        Posté par  . Évalué à -1.

        Si tu abla not the correct langue, komment estimes-you been comprened ?
        Libre ha toua d'aikrire dent zune langue qi naixiste pas, libre ho zotr de dirr qe sah lait en merde.

        • [^] # Re: Vocabulaire

          Posté par  . Évalué à 3. Dernière modification le 10 avril 2013 à 00:10.

          À partir du moment où il a utilisé "malgré" et mis des majuscules en début de phrase, on peut tout de même lui donner la moyenne… Faut pas pousser mémère!

          edit : en fait, non.

      • [^] # Re: Vocabulaire

        Posté par  . Évalué à 1.

        Pour compléter Tanguy Ortelo,

        Dictionnaire de l'Académie française, 9ᵉ édition.

        Chiffrement → Voir chiffrage (2).
        Chiffrage (2) → Action de chiffrer un texte pour en assurer le secret ; résultat de cette action.
        Chiffrer (3) → Transcrire un texte en langage conventionnel pour en assurer le secret.
        Déchiffrer (1) → Lire ce qui est écrit en chiffre, selon un code convenu et secret ; traduire en clair.
        Décrypter → Traduire, mettre en clair un texte chiffré dont on ne possède pas la clef ou le code.
        Crypter → ∅.

        En gros décrypter correspond à déchiffrer sans avoir la clef. C'est bien le sens qu'on a du mot dans le language courant. Si on voudrait donner un sens cohérent à crypter, ce serrait chiffrer sans avoir la clef, ce qui est assez étrange.

        une question technique un peu poussé

        Euh… non. Comme cela a déjà été précisé par une autre participant, la réponse traine sur le web. Mais je vais surement compléter la dessus (afin notemment de séparer le commentaire de fond et de forme). Mais tu ne poses pas la bonne question. Voir point suivant.

        Mr Tanguy

        En français Monsieur est noté M. Quand je lis Mr je le lis à l'anglaise Mister, et il y a un truc qui me gène. Alors soit tu voulais écrire Monsieur et j'ai lu Mister (en première lecture, après je me reprends généralement) car tu avais écris fautivement ; soit tu voulais écrire Mister, dans ce cas je respecte ton choix même si la sonorité me gène.

        des compétences en "chiffrement"

        Ce n'est pas des compétences en chiffrement que tu demandes. D'ailleurs tu a écris tout seul la commande openssl necessaire. La partie chiffrement tu y a répondu et ce n'était pas la plus simple, maintenant c'est la partie enchainement de syslog avec un programme tiers qui te manques.

        • [^] # Re: Vocabulaire

          Posté par  . Évalué à 2.

          ce serrait chiffrer sans avoir la clef, ce qui est assez étrange.

          Non ça l'est pas. Et quand on y arrive, ça fait autant de bruit qu'une faille de sécurité classique, parce que c'est tout aussi dangereux.

  • # lmgtfy

    Posté par  . Évalué à 3.

    http://lmgtfy.com/?q=remote+syslog+and+pipe

    premier ou 3e lien : utiliser les pipes avec syslog
    pour eventuellement chiffrer à l'arrivée sur le serveur de log
    http://www.linode.com/wiki/index.php/Syslog_Howto
    http://www.softpanorama.info/Logs/Syslog/pipes_in_syslog.shtml

    6e lien pour syslog-ng chez Archlinux :
    creer un serveur qui sera l'hote des logs avec syslog-ng
    et plus particulierement
    https://wiki.archlinux.org/index.php/Syslog-ng#Move_log_to_another_file

    et plus bas dans la documentation on retrouve les pipes en source (prendre une info dans une commande et la logguer) ou en destination pour donner l'info à un pipe.

    j'imagine donc que tu peux configurer une sortie du serveur central de log vers un pipe qui chiffrerait chaque ligne.

    attention alors, il faudra dechiffrer chaque ligne à la lecture, et non plus seulement le fichier tel que tu le fais actuellement.

    • [^] # Re: lmgtfy

      Posté par  . Évalué à -2.

      Bonjour,
      Merci pour ta réponse en faite au cas ou ce ne serait pas clair je n ai absolument aucun probleme avec la mise en place de syslog-ng ou la gestion de spipe avec celui-ci :)
      Je cherche juste a savoir comment je peux encrypter un flux en temps réel vers un fichier…

      "j'imagine donc que tu peux configurer une sortie du serveur central de log vers un pipe qui chiffrerait chaque ligne."

      C'est exactement ce que je veux faire (voir ma question d origine)

      merci!

      • [^] # Re: lmgtfy

        Posté par  . Évalué à 3.

        Pourquoi ne pas juste définir une destination adaptée ?

        Genre la destination program dans la doc 

        destination d_prg { program("/usr/bin/openssl […] -in /dev/stdin […]"); };

        Ça me semble le plus simple. La difficulté c'est juste de se manger les options d'openssl, mais tu as déjà fais le boulot.

      • [^] # Re: lmgtfy

        Posté par  . Évalué à 4.

        ta question :

        Je cherche juste a savoir comment je peux encrypter un flux en temps réel vers un fichier …

        ma reponse :

        "[…]tu peux configurer une sortie du serveur central de log vers un pipe qui chiffrerait chaque ligne."

        d'ou ma reponse et mon renvoi vers la documentation de syslog qui explique ca tout bien.

        syslog-ng te permet d'envoyer tes logs vers un fichier (classique), vers serveur distant (tu connais), vers un pipe ou vers un programme

        pourquoi ne pas alors lui demander d'envoyer le contenu du log dans un pipe avec openssl
        ca ferait donc le chiffrement.

        tu peux le faire au depart (sur le serveur d'origine du log) ou à destination (sur le serveur central de log)

        avec ma remarque precedente :
        attention toutefois, ca va chiffrer ligne par ligne ton fichier de log, là où actuellement tu chiffres le fichier dans son integralité.

        il faudra alors changer l'algorithme de dechiffrage pour dechiffre ligne par ligne aussi

        • [^] # Re: lmgtfy

          Posté par  . Évalué à -1. Dernière modification le 10 avril 2013 à 12:13.

          Salut,

          Merci pour ces réponses.

          L'idée du stdin dans la ligne de commande openssl aurait pu être bonne :)
          Mais il n en est rien… avant de configurer le | openssl dans syslog j ai fais le test suivant:

          cat | openssl blabla -out fichier-sortie (dans un premier terminal)

          et dans un autre terminal

          tail -f fichier-sortie

          Je constate qu OpenSSL ne chiffre qu une fois le Ctrl+D envoyé ce qui signifie (dites moi si je me trompe) qu il stocke en mémoire avant de chiffrer -> donc pas de chiffrement en temps réel… et un risque de saturer la mémoire.

          Ma question est donc toujours ouverte:

          Comment chiffrer un flux de data en temps réel vers un fichier avec OpenSSL (en utilisant un certificat) ?

          Merci de votre aide

          • [^] # Re: lmgtfy

            Posté par  . Évalué à 3.

            Alors avec un certificat je n'ai pas essayé, mais avec d'autres modes de chiffrement il chiffre par morceaux.

            Par exemple en lui donnant lentement des données avec pv,

            pv -L 1k /dev/urandom | openssl enc -aes-256-cbc -k bonjour -out /tmp/machin

            je constate qu'il chiffre par morceaux de 8 KiB.

            Aucun risque de saturer la mémoire.

          • [^] # Re: lmgtfy

            Posté par  . Évalué à 3.

            ca merite quand meme un test, car syslog en remote est souvent en udp
            il n'y a donc pas de notion de connection, donc la fin de la ligne doit etre similaire au Ctrl+D

Suivre le flux des commentaires

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