Archive

Articles taggués ‘sécurité’

Le Projet Debian offre un support étendu pour Squeeze

24/04/2014 Aucun commentaire

Le cycle de vie d’une version Debian se divise en 3 phases principales. Il y a l’étape Testing, étape durant laquelle la future version stable est enrichie en fonctionnalités, puis gelée pour chasser les bugs. Ensuite cette version passe à l’état de Stable où elle ne recevra que les mises à jour de sécurité pendant toute sa durée de vie. Dès lors que la version Testing suivante est éligible à l’état Stable, la version Stable actuelle passe en OldStable.

A ce moment là, elle continue de recevoir les mises à jour de sécurité pendant 1 an environ. Cette période de transition permet à tout un chacun de planifier sa migration vers la nouvelle Stable à son rythme.
A l’issue de cette année, plus aucun développement n’est effectué par le Projet Debian, et il devient alors inévitable pour tout système en production de migrer vers la nouvelle version Stable.

L’actuelle OldStable est la version 6 de Debian aussi connue sous le nom de code Squeeze. Alors que le support de Squeeze devait se terminer le 31 mai 2014, le Projet Debian vient d’annoncer qu’après avoir reçu des demandes de plusieurs sociétés et autres organisations, le support de Squeeze serait étendu jusqu’en février 2016. Soit 5 ans après sa sortie initiale !

En revanche ne seront supportées que les versions i386 et amd64. A noter cependant que le support (plus exactement la production de fix de sécurité puisque c’est de ça qu’il s’agit), ne sera pas fourni par l’équipe Sécurité de Debian, mais par des volontaires (sociétés ou particuliers) sélectionnés et validés par Debian.

Si vous souhaitez contribuer vous êtes d’ailleurs invités à contacter l’équipe à team@security.debian.org. Le projet précise également que cette première, servira d’essai afin de constater s’il est vraiment utile de proposer du support étendu pour l’actuelle version Stable de Debian (Debian 7 Wheezy) et l’actuelle Testing et donc future Stable (Debian 8 Jessie).

Tags: , , , , , ,

Les positions de Canonical, Red Hat et de la Linux Foundation sur le Secure Boot

06/11/2011 Aucun commentaire

Récemment ces 3 acteurs majeurs du monde du Logiciel Libre et de l’OpenSource, ont communiqué sur l’éventuelle mise en place d’une procédure de boot sécurisée par les constructeurs. Ceci afin d’être compatible avec les prérequis de Microsoft pour la commercialisation de son futur Windows 8.
Si vous avez lu les 2 précédents billets sur le sujet vous êtes désormais familier avec ce qui nous attend.

Red Hat et Canonical ont écrit un livre blanc commun sur le sujet. Ce livre peut se résumer à un ensemble de recommandations que les 2 sociétés adressent aux constructeurs. Dans le même temps la Linux Foundation a édité le même genre de document avec le même but.

Les 2 documents ont une approche beaucoup plus constructive que ce que l’on pourrait penser de prime abord. Plutôt que de stigmatiser l’UEFI et son mode de boot sécurisé, les 3 entreprises prennent en quelque sorte le parti de Microsoft dans sa quête de plus de sécurité sur le poste de l’utilisateur.
Il est juste de reconnaître de bonnes intentions à Microsoft, dans leur volonté de renforcer la sécurité du processus de lancement des systèmes d’exploitation. En revanche et je cite Canonical et Red Hat :

« Les spécifications de l’UEFI pour un boot sécurisé ne définit pas qui contrôle les restrictions lors du boot sur les plateformes UEFI, laissant la décision au constructeur de la plateforme, du schéma de sécurité à utiliser.Malheureusement,les recommandations d’implémentation de Microsoft en matière de boot sécurisé ôtent du propriétaire du matériel ( NDLR : nous en l’occurrence ) tout contrôle sur le système, et pourraient empêcher les systèmes d’exploitation open source de fonctionner. Les prérequis de Windows 8 pour le boot sécurisé vont forcer les OEMs à implémenter le boot sécurisé de cette manière. »

En résumé ils déplorent le fait que le choix ne sera pas laissé à l’utilisateur final d’activer ou non cette fonctionnalité. C’est pour cela que plutôt que de dénoncer le système dans son intégralité, la Linux Foundation et Red Hat/Canonical, proposent aux constructeurs de donner la possibilité à l’utilisateur final, d’établir lui même sur son propre système, une liste des systèmes d’exploitation qui seront autorisés à démarrer sur sa machine. Ils demandent également que l’activation du boot sécurisé soit laissé à l’appréciation de l’utilisateur.
Pour cela ils s’appuient sur le fait que les spécifications de l’UEFI ne déterminent pas qui doit être en charge de l’implémentation des clés ( OEMs, utilisateurs finaux …. ). Seul Microsoft décide derechef que cette tâche doit incomber exclusivement aux constructeurs.

Je vous propose donc de lire les documents de la Linux Foundation et de Red Hat/Canonical qui vous donneront de manière exhaustive tous les détails sur l’implémentation du boot sécurisé et comment les utilisateurs de GNU/Linux ou autre ( BSD … ) peuvent en tirer avantage. Ceci bien entendu partir du moment où leurs recommandations sont prises en compte …

Je profite également de ce billet pour vous annoncer la naissance d’un mouvement destiné à lutter contre ce nouvel abus de position dominante de Microsoft : Libraboot.
Nous sommes en pleine constitution d’une association afin de faire valoir nos droits. Un forum existe également ainsi qu’un channel irc : #libraboot sur Freenode. Nous vous attendons nombreux.

Tags: , , , ,

Une faille de sécurité dans le Kernel 64bits

19/09/2010 Aucun commentaire

Une faille de sécurité a été découverte dans le noyau Linux 64 bits. Cette faille se situe au niveau du mode de compatibilité 32 bits.
Comme beaucoup de failles celle ci offre la possibilité d’éxecuter du code malveillant et d’obtenir les droits SuperUtilisateur.
Ben Hawkes l’auteur de la découverte décrit le problème comment étant du au fait que la couche de compatibilité 32 Bits, ne vérifie pas si l’appel effectué est présent dans la table Syscall. Il existe déjà un code permettant d’exploiter cette faille.
On apprend que cette faille avait déjà été patchée en 2007, mais que lors d’une mise à jour du Kernel en 2008 le patch avait supprimé réouvrant du même coup la faille.

Malgré tout le trou a déjà été comblé par les développeurs et on devrait bientôt trouver une mise à jour de nos Kernels dans les dépôts de nos distributions préférées.

(Source : H-online)

Tags: , , , ,

Sortie de Untangle 7.3

04/06/2010 Aucun commentaire

Le projet Untangle vient de sortir la nouvelle version de son UTM, la 7.3.
Pour rappel, le projet Untangle est un firewall UTM (Unified Threat Management ou traitement de la menace unifiée) basé sur Debian et qui propose des services de sécurité tels que :

  • Firewall
  • Mailrelay avec antispam et antivirus
  • Filtrage de contenu HTTP et d’urls
  • Bloquage de la publicité sur les pages web
  • Passerelle VPN
  • IDS/IPS

Toutes ces fonctionnalités sont gratuites et livrées en standard. Untangle étant une suite modulaire, il est possible d’étendre ses possibilités en ajoutant d’autres modules qui eux sont payants, comme :

  • Un service de support
  • Le système Antispam de Commtouch
  • Un module de règles firewall étendu (username …)
  • Gestion de 2 accès Internet redondés
  • Antivirus Kaspersky

la nouvelle version propose essentiellement la possibilité de faire de la marque blanche à des buts d’OEM, des améliorations dans le GUI, une liste de compatibilité Hardware étendue, de traditionnels bugfix et une optimisation de la consommation mémoire augmentant d’autant les performances.
Rendez-vous ici pour le téléchargement.

Tags: , , , ,

50 alternatives opensource en terme de sécurité

19/05/2010 2 commentaires

Datamation publie un article énonçant 50 alternatives OpenSource aux logiciels dits de sécurité les plus connus.
Datamation les classe par catégorie :

Parmi les outils confrontés citons notamment Clamav opposé à Avast pour les antivirus, Apparmor face au WAF de Barracuda, Winscp face à CuteFTP par exemple,Endian Firewall face aux Symantec et autres Checkpoint ou encore Vyatta face à Cisco.

Notons qu’enfin loin d’être exhaustif ce petit annuaire renforce l’idée selon laquelle il est aisé aujourd’hui de trouver à chaque logiciel propriétaire une excellente alternative OpenSource. Même s’il est vrai que le domaine de la sécurité informatique fourmille de projets ce postulat peut aisément être transposé aux autres domaines de l’informatique (bureautique, graphisme ….)

Tags: , , , ,

Après IE le Cert allemand déconseille l’utilisation de Firefox 3.6

22/03/2010 3 commentaires

Après avoir déconseillé l’utilisation de Internet Explorer en janvier dû à une faille de sécurité, le Cert allemand récidive en déconseillant cette fois l’utilisation de Firefox 3.6.1 car une faille zero-day y a été découverte. La faille permet à un utilisateur mal intentionné d’exécuter du code sur une machine distante et par la même de compromettre ladite machine.

Secunia qualifie cette faille de hautement critique et précise que la version 3.6 est affectée mais que les autres pourraient l’être aussi.

Tags: , , , ,

Trucs et Astuces pour améliorer le niveau de sécurité de vos serveurs SSH

20/10/2009 3 commentaires

Cet article va vous exposer quelques trucs et astuces permettant d’améliorer le niveau de sécurité d’un serveur SSH. Ces astuces s’appuient sur l’implémentation la plus répandue du protocole SSH, OpenSSH. Ceci n’est pas un tutoriel dans le sens où toutes ces astuces ne peuvent être « activées » sur un même serveur SSH.

Les fichiers de Configuration d’OpenSSH

Pour rappel, OpenSSH possède un certain nombre de fichiers de configuration:

  • /etc/ssh/sshd_config : fichier de configuration du serveur SSH,
  • /etc/ssh/ssh_config : fichier de configuration du client SSH,
  • ~/.ssh/ : répertoire contenant la configuration ssh propre à l’utilisateur, référencé par ~,
  • ~/.ssh/authorized_keys : Liste des  clés publiques (RSA et DSA) pouvant être utilisées pour se connecter à ce compte,
  • /etc/hosts.allow et /etc/hosts.deny : la white list et la black list d’OpenSSH.

Ces fichiers seront cités dans la suite de l’article, sans faire référence à leur chemin complet.

Petit point à propos des mécanismes de chiffrement RSA et DSA.

Régulierement est posée la question de savoir qui du protocole RSA ou DSA est le plus sécurisé. La  réponse est simple. A un dimensionnement de clés raisonnable, les deux protocoles offriront un niveau de sécurité équivalent. L’ANSSI (Agence Nationale de la sécurité des systèmes d’information) recommande aujourd’hui d’utiliser des clés de 2048bits (cf. Recommandations sur le dimensionnement des clés).
Cependant, ssh-keygen, l’outil de génération de clés d’OpenSSH ne permet pas de générer des clés DSA de 2048 bits (tout du moins dans la version d’OpenSSH 5.1p1 disponible sous Ubuntu Jaunty). Vous pouvez cependant la générer avec openssl et l’utiliser avec openssh.

Génération d’un clé DSA avec OpenSSL :

Génération de la clé privée

openssl dsaparam -noout -out ~/.ssh/id_dsa -genkey 2048
openssl dsa -in ~/.ssh/id_dsa -des3 -out ~/.ssh/id_dsa

Génération de la clé publique :

openssl dsa -in ~/.ssh/id_dsa -pubout -out ~/.ssh/id_dsa.pub

Règles et recommandations :


Renforcement de l’authentification

Un précédent article dans ce blog montre que les utilisateurs, en négligeant les risques liés au choix et au dimensionnement de leurs méthodes d’authentification sont souvent le maillon faible d’un système d’information.
Afin d’endiguer ce phénomène, voici quelques règles simples qui permettront de renforcer l’authentification des utilisateurs sur des serveurs SSH. Les clés de configuration listées sont à insérer/contrôler dans le fichier sshd_config.

  1. Ne pas autoriser de mots de passe vides :
    PermitEmptyPasswords no
  2. Ne pas donner d’accès root à l’équipement :
    PermitRootLogin no  *
  3. Modifier le MOTD visualisé par les utilisateurs afin de les informer des risques encourus :
    Banner <chemin de la nouvelle bannière>
  4. Ajouter un timeout à vos connexions afin que les utilisateurs ne laissent pas des shells ouverts indéfiniment :
    ClientAliveInterval 300
    ClientAliveCountMax 0
  5. Forcer les utilisateurs à avoir des mots de passe forts **
  6. Privilégier l’authentification par clé publique et désactiver l’authentification par mot de passe :
    PasswordAuthentication No
  7. Mettre en place une authentification forte / bi-facteur.

* En règle générale, il est recommandé pour deux raisons d’éviter de donner l’accès à des comptes génériques :

  • le nom d’utilisateur est connu de tous (une information sur deux est disponible!),
  • il est impossible pour un administrateur du SI de savoir qui a fait quoi. Il est préférable de s’authentifier d’abord à l’aide d’un compte nominatif, puis de prendre les privilèges nécessaires (les logs système permettront de savoir quel utilisateur a pris quels droits à un instant T).

** Cette réflexion va bien au-delà du simple renforcement de l’authentification sur des serveurs SSH et doit être prise à un niveau global dans l’administration d’un système d’information.

Renforcement de l’accès au serveur SSH

  1. La première règle de sécurité est évidente : un démon SSH inutilisé est un démon SSH de trop.
  2. Vérifier que les serveurs SSH ne supportent que la version 2 du protocole, la première version étant désormais ancienne et faillée comme un OS de Microsoft. Pour cela, vérifier que votre sshd_config possède l’entrée suivante :
    « Protocol 2″
  3. Limiter les comptes autorisés à se connecter via SSH en utilisant les clés AllowUsers et DenyUsers.
    AllowUsers john

    n’autorisera que l’utilisateur john à se connecter à la machine

    DenyUsers mysql

    n’autorisera pas l’utilisateur mysql.
    Ceci est particulièrement utile dans le cadre de machines disposant de compte générique (base de données …)

  4. Paramétrer les firewalls pour limiter l’accès à vos services (dans un monde parfait, l’accès SSH est limité à votre LAN)
  5. Changer le port de connexion, limiter les adresses de binding
    ListenAddress 192.168.1.5
    Port 300
  6. Renforcer votre serveur SSH contre les attaques brute-force en utilisant des systèmes tels que DenyHosts ou fail2ban
  7. Désactiver l’authentification par mot de passe. Ceci vous protégera efficacement des attaques par force brute
  8. Enfin, si l’authentification par mot de passe est nécessaire, privilégier l’authentification  « keyboard-interactive ». Ceci également afin de vous protéger des attaques par force brute.
    Modifier votre sshd_config de la manière suivante:

    PasswordAuthentication no
    ChallengeResponseAuthentication yes

DenyHosts : Mettre à jour votre hosts.deny

DenyHosts est un démon, écrit en python qui scrute le /var/log/auth.log pour détecter les échecs d’authentification. Si un nombre (configurable) de tentatives échouées est atteint, l’ip source est alors blacklistée dans le hosts.deny du système. DenyHosts implémente également un mécanisme de purge. Un court article ici (en anglais) montre une configuration simple pour DenyHosts.

Authentification Bi-Facteur avec OpenSSH

Une des authentifications bi-facteur la plus simple à mettre en oeuvre est une authentification password / clé publique + OTP (one-time password).

Pour debian la marche à suivre est la suivante :

apt-get install libpam-opie opie-server

Ensuite dans /etc/pam.d/ssh, ajouter l’entrée pam_opie :

auth    required   pam_env.so envfile=/etc/default/locale
auth    required   pam_opie.so

Le fichier de configuration du serveur ssh doit avoir une authentification positionnée à :

ChallengeResponseAuthentication yes
PasswordAuthentication no

Il reste à initialiser le serveur  OTP :

opiepasswd -c

Rentrer la passphrase qui permettra de générer les OTP. Il ne reste plus qu’à déployer des calculatrices OTP sur les postes clients (paquet opie-client). La procédure d’authentification sera alors la suivante :

jack@bauer:~$ ssh login@device
otp-md5 492 ne9401 ext, Response:
Password:
...
Contribution d’Olivier Hervieu pour TechnoAddict
Tags: , , , , , , , ,

Securité et Mots de Passe

08/10/2009 2 commentaires

Un collègue m’a fait suivre une petite enquête sur une attaque au mots de passe qui a eu lieu au début de ce mois.
Par le biais d’une attaque ancestrale (envoi d’un faux email destiné à récupérer les identifiants) un anonyme a pu rapatrier les logins et mots de passe de 19440 comptes Hotmail, Gmail, Yahoo et Free.
Tuxplanet a analysé le contenu récupéré et a pu se rendre compte de la faiblesse des mots de passe choisis par quelques utilisateurs de ces webmails.
Voici une liste à titre d’exemple:
On a trouvé:

  • - 87 fois 123456
    - 25 fois 123456789
    - 16 fois 123321
    - 21 fois monkey
    - 17 fois password
    - 13 fois les mots princess, horses, tigger
  • Sans parler des milliers de mots du dictionnaire choisis.

    Voilà qui vient confirmer mon billet d’hier à savoir que c’est bien l’humain qui est responsable de 90% des intrusions informatiques et autres vols de données.

    Tags: , , ,

    Pourquoi l’humain est il la faille de votre SI?

    07/10/2009 un commentaire

    Je suis en ce moment en prestation dans une grande institution française pour mettre en place une solution de sécurité informatique.
    Comme d’habitude les exigences du client en la matière sont assez élevées et il est plutôt pointu sur les différents tests à effectuer.
    Pour lui la sécurité de son Système d’Information est quelque chose de primordial et il ne laisse rien au hasard.
    Première pierre d’achoppement à son bel enthousiasme, les mots de passe des équipements critiques sont tous imprimés. Deuxième détail lors de la pause de midi tout le monde est parti nous laissant mon collègue et moi en présence d’ordinateurs non vérouillés et surtout de la fameuse liste de mots de passe.

    Lors de la plupart de mes déplacements en clientèle, il m’a systématiquement été donné de voir des choses du même acabit voire pire.
    La conclusion est la suivante: Il va de soi qu’une bonne sécurité informatique est absolument nécessaire. Mais 90% des risques pourraient être réduits si les choses les plus élémentaires étaient respectées.
    Comme l’humain ne peut être éliminé de la boucle, il faut l’éduquer en conséquence. Et pour moi la plupart des sites spécialisés, ou des magazines traitant du sujet devraient et doivent évoquer ces choses. Car que faire avec le Firewall, le proxy ou la sonde IDS du siècle si son administrateur laisse à qui veut bien le voir les mots de passe des accès?

    Tags: , , , ,
    Categories: Securite Informatique

    Nouvelle version de Astaro Gateway

    01/10/2009 4 commentaires

    Astaro l’un des éditeurs d’UTM leaders, vient de sortir la version 7.5 de Astaro Security Gateway. Elle se présente sous la forme d’une distribution Linux installable soit sur une appliance soit en machine virtuelle.
    Parmi les nouveautés les plus marquantes on note: un monitoring en temps réel de la bande passante, un proxy HTTP transparent avec authentification par portail captif, une amélioration des systèmes IDS, un serveur DHCP revu avec la possiblilité d’assigner automatiquement des baux statiques et de configurer le temps des baux.
    Astaro annonce 50 nouvelles fonctionnalités que vous pouvez consulter dans la release note.
    Pour télécharger l’ISO c’est que ca se passe.

    Tags: , , ,