Securite

Dans l’article précédent, j’ai présenté pi-secured-setup — une extension pi qui ajoute des Guards, des Scanners et un audit trail à votre agent de code IA. Elle est livrée avec des defaults pertinents : application de frontière, globbing de chemins protégés, classification de commandes bash, rédaction de secrets, vérification de skills.

Mais chaque projet a des risques uniques. Un shop Terraform n’a pas les mêmes règles qu’un monorepo Node.js. Une équipe avec des exigences de conformité strictes n’a pas la même granularité d’audit qu’un développeur solo.

Il y a quelques jours, je présentais Greywall — un sandbox kernel-level qui contient pi grâce à une approche deny-by-default. C’est votre mur extérieur. Mais qu’en est-il des menaces à l’intérieur de la frontière ? L’agent qui écrit accidentellement dans le mauvais projet, le fichier .env qui se retrouve dans le contexte LLM, le skill dont le SKILL.md a été silencieusement modifié. C’est un problème différent, qui nécessite un outil différent.

Les agents de code IA comme pi sont devenus des compagnons indispensables au quotidien. Mais par défaut, pi fonctionne en mode YOLO : accès complet au filesystem, exécution de n’importe quelle commande, aucune restriction. C’est un choix délibéré de son créateur, mais cette liberté a un coût réel. Aujourd’hui, je vous propose de découvrir Greywall, un outil qui permet de sandboxer pi grâce à une approche deny-by-default au niveau kernel.

Quelques jours après la version 1.2.2, l’équipe d’AstLinux sort une nouvelle version corrigeant plusieurs failles de sécurité (35 !) touchant de nombreux paquets. Voici la liste :

• CVE-2015-3331 : patch linux
  

• CVE-2014-8964, CVE-2015-2325, CVE-2015-2326 : pcre
  

• CVE-2014-9680 : sudo
  

• CVE-2015-1572 : e2fsprogs
  

• CVE-2014-8128 : tiff
  

• CVE-2015-0286, CVE-2015-0287, CVE-2015-0289, CVE-2015-0292, CVE-2015-0293, CVE-2015-0209, CVE-2015-0288, CVE-2015-4000, CVE-2015-1788, CVE-2015-1789, CVE-2015-1790, CVE-2015-1792, CVE-2015-1791 : OpenSSL (version 1.0.1o)
  

• CVE-2015-2059 : prosody
  

• CVE-2014-9297, CVE-2014-9298, CVE-2015-1798, CVE-2015-1799 : ntpd/sntp
  

• CVE-2014-2285 : netsnmp
  

• CVE-2015-1419 : vsftpd
  

• CVE-2015-3294 : dnsmasq
  

• CVE-2015-3144, CVE-2015-3145, CVE-2015-3148, CVE-2015-3143, CVE-2015-3153, CVE-2015-3236, CVE-2015-3237 : libcurl
  

Un renforcement de la sécurité a été opéré par la création d’un certificat auto-généré unique. Les versions d’Asterisk ont aussi été mis à jour :

Comme convenu lors de mes voeux, voici mon premier article technique de 2012 touchant la sécurité informatique et plus précisément comment sécuriser le SIP d’un serveur asterisk.

Je ne vais pas vous rappeler l’intérêt (quand on touche au portefeuille, on comprend de suite beaucoup plus vite) de bien sécuriser son serveur de téléphonie.

Asterisk est de plus en plus déployé en entreprise, apportant une flexibilité et des fonctionnalités pour un coût incomparable. Asterisk sait gérer plusieurs protocoles de communications dont le SIP. Nous allons voir dans cet article comment sécuriser le SIP.