sécurité

Fiche logiciel validé
  • Création ou MAJ importante : 30/03/13
  • Correction mineure : 30/03/13
Mots-clés
Pour aller plus loin

Fail2ban : détecte les attaques en "force brute" et stoppe les adresses IP des attaquants

Description
Fonctionnalités générales

Fail2ban est un outil de sécurité informatique qui permet, à partir de l'exploitation des fichiers journaux ("logs"), de protéger un serveur en bloquant temporairement ou définitivement des adresses IP de machines à partir desquelles des attaques réseau ont été remarquées. De façon générale, fail2ban peut exploiter n'importe quel fichier de log, pour détecter par exemple de multiples tentatives de connexion, des soumissions d'url malveillante, etc ...

Lors de la détection d'une attaque ou d'une action malveillante, fail2ban est capable de mettre à jour dynamiquement les règles du pare-feu local du serveur pour bloquer pendant un temps donné les flux en provenance de l'adresse IP d'où provient l'attaque, mais il peut aussi exécuter, si nécessaire, n'importe quelle autre action.

La version 0.8.7 introduit la possibilité de traiter différemment les adresses IP qui se sont déjà faites bannir plusieurs fois.

Autres fonctionnalités

Fail2ban est très flexible et permet de surveiller un grand nombre de services système différents comme par exemple ssh, ftp, mail, web, ... Il suffit de disposer d'un fichier de log à analyser et de définir un "filtre" qui indique quelles sont les lignes qui correspondent a priori à une activité malveillante. Fail2ban est fourni par défaut avec de nombreux filtres prédéfinis pour repérer les attaques les plus fréquentes, notamment, sur des services standards.

Il est également très flexible par rapport à la conduite à tenir, qui est définie dans des fichiers "actions". Au delà d'un seuil configuré pour chaque service à surveiller, une action est exécutée. Fail2ban peut bloquer l'adresse IP de l'attaquant au moyen d'une configuration appropriée dans iptables, ou par les fichiers hosts.deny ou encore envoyer un mail ou remonter l'information à un système centralisé, etc.

Un certain nombre d'actions de base sont disponibles par défaut.

Contexte d'utilisation dans mon laboratoire/service

Fail2ban est utilisé sur la machine "sas" d'entrée du campus de Luminy. La plupart des services du campus ne sont autorisés de l'extérieur que depuis les machines sas. En rajoutant fail2ban, ces machines "sas" sont un peu plus sécurisées de manière, notamment, à éviter les attaques en force brute.

Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré
  • Fail2ban est disponible de base, entre autres, dans les dépôts Debian, Ubuntu, Fedora, Mandriva, OpenSUSE, FreeBSD. * Disponible via dépôt additionnel dans la plupart des autres distributions.
Plates-formes

Toute plateforme disposant du langage Python.

Logiciels connexes

Pour arrêter les tentatives d'intrusion en force brute, fail2ban utilise des logiciels de filtrage d'adresse IP comme :
- iptables
- netfilter

Autres logiciels aux fonctionnalités équivalentes

Denyhosts, dernière version en 2009

Environnement de développement
Type de structure associée au développement

Trois développeurs, plus de multiples contributeurs pour le maintien des paquetages.

Eléments de pérennité

Le projet est assez actif avec une nouvelle version tous les ans à peu près (non seulement des corrections de bugs, mais aussi de nouvelles fonctionnalités)

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur
Divers (astuces, actualités, sécurité)

Par défaut, l'action d'exclusion des adresses IP effectue une configuration des iptables. Dans le cas de machines virtuelles notamment sous openvz, iptables n'est utilisable que sur l'hôte. Si l'on souhaite gérer les exclusions dans les machines virtuelles, il faut utiliser l'action hostsdeny de fail2ban qui se base sur le fichier /etc/hosts.deny

Contributions
Fiche logiciel à valider
  • Création ou MAJ importante : 05/12/11
  • Correction mineure : 08/03/13
Mots-clés

Chimithèque : Gestion de stock de produits chimiques

Ce logiciel est en cours d'évaluation par la communauté PLUME. Si vous utilisez ce logiciel en production dans notre communauté, merci de déposer un commentaire.
Description
Fonctionnalités générales

Chimithèque est une application qui a été conçue de manière générique, c'est à dire qu'elle essaie de répondre aux besoins de l'ENS, Ecole Normale Supérieure de Lyon, mais aussi d'autres établissements. Elle a été pensée de manière générale par des chimistes et biologiste pour être utilisée par d'autres chimistes et biologistes dans et hors ENS.

Ce logiciel est composé de Fiches Produit et de Fiches de Stockage.

  • une fiche produit contient des informations générales relatives au produit : nom, synonymes, N° CAS, formule brute, formule linéaire, lien vers la FDS (fichier enregistré ou lien internet), pictogrammes de danger et phrase de danger et de prudence (nouvelle et ancienne législation)...
  • une fiche stockage contient des informations concernant un flacon présent dans l'établissement : lieu de stockage, conditionnement, date d'entrée, code barre généré automatiquement, nom du fournisseur, référence du fournisseur.

Il est possible de faire des recherches par nom, formule brute, numéro CAS ou par localisation mais aussi selon leur dansgerosité (tous les inflammable ou tous les CMR, ...)

C'est un outil important pour les services hygiène et sécurité puisqu'il permet de faire des recherches par rapport aux dangers physiques et aux dangers pour la santé.

L'accès aux données enregistrées dans Chimithèque peut être restreint pour certains utilisateurs grâce à un système de droit assez fin : par défaut, tous les utilisateurs ont la possibilité de voir les fiches produit. Ensuite pour chaque utilisateur on peut choisir de lui donner le droit de voir, modifier, créer et/ou supprimer les fiches produit, fiches de stockage, utilisateurs, entrepôts, ... Un utilisateur pouvant créer des utilisateurs ne peut évidemment pas donner plus de droits qu'il n'en a.
Les administrateurs de l'entité ont tous les droits et appartiennent automatiquement à toutes les entités.

Autres fonctionnalités

Chaque utilisateur appartient à une ou plusieurs entité (correspondant à des labos ou équipes de recherche). On définit une ou plusieurs personne(s)  "manager" pour chacune des entité, qui sera/seront la/les personne(s) à contacter.

Dans chaque entité, on peut avoir plusieurs entrepôts dans lesquels on va stocker les produits (fiches de stockage liées à une fiche produit et à un entrepôt)

Pour toute personne ayant les droits correspondants :

  • chaque fiche produit peut être modifiée (création d'un historique), clonée (permettant la création rapide d'une fiche pour un produit ayant seulement une spécificité différente) ou supprimée si elle est orphenile (c'est à dire si aucune fiche de stockage lui est liée).
  • chaque fiche de stockage peut être modifiée (historique), clonée, supprimée (création de fiches de stockage archivées), marquée pour destruction ou empruntée.

 

Interopérabilité

Possibilité d'export CSV (ou HTML) des résultats d'une recherche.

Contexte d'utilisation dans mon laboratoire/service

Actuellement, 150 personnes environ utilisent cette application au sein de l'ENS. Ces utilisateurs sont des biologistes, chimistes, personnels hygiène et sécurité, géologues.
Un peu plus de 4000 fiches produits ont été saisies et environ 2800 fiches produits ont des fiches de stockage associées.
Les retours que nous avons eu sont positifs : assez simple d'utilisation, pas de soucis particulier.

Limitations, difficultés, fonctionnalités importantes non couvertes

Ce que Chimithèque n'est pas :

  1. une base de données de tous les produits chimiques existants dans le monde: l'application est fournie avec X fiches produit (pour X voir sur la page principale) et ces fiches peuvent être échangées grâce à une fonctionnalité d'import/export
  2.  une application immédiatement connectable a des appareils comme de scanners à code barre ou d'autres applications
Environnement du logiciel
Plates-formes

Linux

Environnement de développement
Références d'utilisateurs institutionnels

Actuellement, nous savons que l'application est utilisée à :

  • l'École Nationale supérieure de chimie de Clermont-Ferrand
  • Université de Montpellier
  • IUT de Besançon-Vesoul

Certainement prochainement :

  • Université de St Etienne
Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur
Divers (astuces, actualités, sécurité)

Possibilité de s'inscrire à la liste de diffusion destinée aux établissements extérieurs à l'ENS (infos de mises à jours) : https://listes.cru.fr/sympa/info/chimitheque

Tableau de bord SSI

DEVA : Nom du logiciel: 
tableau-de-bord-ssi
DEVA : Licence du logiciel: 
Pas de licence
DEVA : Commentaires sur la licence: 

Ce logiciel utilise des composants libres et il est développé en interne, nous allons étudier le mode le plus approprié

DEVA : Identifiant PLUME de l'auteur de la soumission (ne pas modifier): 
Philippe Tourron
DEVA : Prénom de l'auteur de la soumission: 
Philippe
DEVA : Nom de l'auteur de la soumission: 
Tourron
DEVA : Email de l'auteur de la soumission: 

philippe [dot] tourron [at] univmed [dot] fr

DEVA : Laboratoire ou service de l'auteur de la soumission: 

Centre Informatique de Gestion et Réseau

DEVA : Tutelles labo/service auteur soumission: 

Faculté de Médecine de Marseille, Université de la Méditerranée

DEVA : Autres informations sur l'auteur de la soumission: 

L'ensemble de l'équipe CIGR a contribué à l'analyse de ce projet. Le développement est actuellement réalisé principalement en collaboration avec un membre de l'équipe informatique : Emmanuel Lestrelin et un stagiaire : Jean-marc Pelle.

DEVA : Description courte du logiciel: 
Gestion, présentation et synthèse d'indicateurs sur la sécurité d’un système d'information
DEVA : Fonctionnalités générales du logiciel: 

Le tableau de bord est un outil de présentation et de synthèse fournissant des indicateurs sur la sécurité d’un système d'information : SI (un laboratoire, une UFR, une Université, ...). Les indicateurs classés par thème ou objectif de sécurité permettent de vérifier l'application de la politique de sécurité sur trois niveaux : Au niveau opérationnel, le tableau de bord permet de contrôler l'état du réseau et des moyens (alarmes) sous une vue synthétique et colorée (rouge, orange, vert selon l’état). Au niveau pilotage, l'utilisateur pourra vérifier la réalisation des objectifs de sécurité et améliorer la qualité de service. Enfin, au niveau stratégique, l'utilisateur aura un outil d'aide à la décision et pourra contrôler la réalisation des objectifs ainsi que l'efficacité des investissements effectués et actions menées.

DEVA : Autres fonctionnalités du logiciel: 

Le tableau de bord utilise un ensemble d'outils afin d'auditer les moyens du réseau et collecter ainsi les informations nécessaires à l'élaboration des indicateurs. On contrôle donc d'une part, la disponibilité des moyens grâce à un outil de monitoring (snmp et agents spécifiques avec zabbix) et d'autre part les vulnérabilités du réseau (avec NESSUS), un anti-virus, un outil d'analyse des logs, un IDS… Tous ces outils de collecte sont personnalisables et l'on peut très bien modifier l'application afin qu'elle intègre d'autres outils.
Le tableau de bord permet également de construire des indicateurs offrant une vue sur divers thèmes tels la gestion des incidents, les activités effectuées, les budgets ou les PRA, ils pourront être saisis via un formulaire.

DEVA : Contexte d'utilisation du logiciel: 

La motivation initiale du projet de développement du tableau de bord SSI fait suite à une étude de risque SSI menée avec la méthode EBIOS (DCSSI). Le premier objectif était de disposer d'un outil générique qui proposerait une vue synthétique de l'état du réseau et des moyens connectés au niveau opérationnel pour boucler une partie de notre système de gestion de la sécurité avec un retour des actions menées et une meilleure évaluation de l'évolution de nos vulnérabilités. L'objectif a été atteint avec la réalisation et la mise en production du premier tableau de bord en juin 2007. Le projet actuel vise à disposer d'un outil plus évolutif mais aussi d'étoffer les indicateurs aux niveaux pilotage et stratégique, notamment en les mettant en corrélation avec les vulnérabilités et fonctions essentielles mises en évidence par l'analyse EBIOS. Le nouveau tableau de bord prévoit aussi la possibilité de gérer plusieurs systèmes d'information.

DEVA : Logiciels similaires: 

Au niveau opérationnel, des plateformes de monitoring tels Zabbix permettent de contrôler l'état d'un réseau grâce à un système de manager et d'agents snmp ou spécifiques à l'application.
D'autres outils permettent de tester les vulnérabilités du réseau comme NESSUS et fournissent un rapport à la fin de leur scan.
Ce type de logiciel couvrant les 3 niveaux fait souvent l'objet de développement spécifique ou de paramétrage lourd et couteux d'applications dédiées à la SSI.

DEVA : Besoins non couverts par logiciels similaires: 

Aucun d'entre eux ne regroupe l'ensemble des informations dans un tableau de bord offrant une vue synthétique du SI au travers d'indicateurs répondant à des objectifs élaborés à partir de la politique de sécurité.

DEVA : Raisons du développement: 

Aucun outil déjà développé ne répond à nos attentes ni à nos budgets et nous voulons améliorer le tableau de bord SSI dont nous disposons déjà en le rendant plus évolutif et générique. Notre projet est de développer une application qui sera capable de gérer plusieurs SI et de pouvoir s'adapter à n'importe quel SI. C'est pourquoi le module de présentation et de gestion du tableau de bord sera clairement séparé du module de collecte des données qui alimentera les indicateurs. En effet, le module Tableau de bord doit pouvoir intégrer des indicateurs provenant de diverses sources dans un souci de réutilisabilité, d'évolutivité et d'adaptation à tout type de SI. Le module de collecte des données sera lui beaucoup plus dépendant des outils utilisés et du système à auditer. Nous voulons également améliorer le code PHP de nos scripts en favorisant la réutilisabilité et en facilitant la maintenance de l'application (modules distincts comprenant des bibliothèques de fonctions/procédures et des définitions de classes d'objets, utilisation de CSS).

DEVA : Etat de la documentation: 

Une documentation complète de la première version du tableau de bord que nous avons développée a été réalisée. Concernant le projet de notre seconde version nous avons déjà effectué la phase d'analyse. Nous disposons donc des documents qui nous ont permis d'analyser les besoins, du modèle de données, du dictionnaire de la base de données ainsi que du script de génération de la base de données.

DEVA : Inter-opérabilité du logiciel: 

L'application est divisée en deux modules distincts :
Le premier comprend tous les scripts de collectes avec les différents outils utilisés afin d'alimenter le tableau de bord. Ce module dépend fortement des choix effectués au sein du SI que ce soit au niveau des outils utilisés ou bien au niveau des indicateurs retenus. Néanmoins, des outils libres ayant été utilisés tels que NESSUS, la gestion syslog (syslog-ng et logcheck) ou encore ZABBIX, une partie des scripts peut être facilement reprise afin de servir pour un autre SI.
Le second module est constitué par la base de données (sous MySQL) du tableau de bord ainsi que par les scripts PHP de l'application.
Le tableau de bord est installé sur un serveur Linux Debian, le SGBD utilisé est MySQL et les scripts de collecte, de traitement et de présentation sont écrits en PHP. L'application peut donc s'intégrer à différentes structures.

DEVA : Briques libres utilisées: 

Zabbix, syslog-ng, logcheck, NESSUS, Apache, Mysql, Php.

DEVA : Architecture du logiciel: 

L'application est installée sur un serveur sous Linux Debian sur lequel nous avons installé trois vservers.
Sur le premier, nous avons le serveur apache ainsi que les scripts PHP de l'application qui iront lire et alimenter la base de données du tableau de bord. Ces scripts permettront aussi la saisie et la gestion d'indicateurs non collectés et l'IHM.
Sur le second vserver, seule la base de données Mysql du tableau de bord est installée.
Sur le troisième vserver sont installés tous les outils ainsi que les scripts de collecte PHP. On y trouve donc Zabbix et sa base de données MySQL, un serveur apache, NESSUS, logcheck, syslog-ng ainsi que tous les scripts qui assureront un traitement des données prélevées sur des sources propriétaires telles que notre IDS ou notre antivirus.

DEVA : Langages de programmation du logiciel: 

Le tableau de bord est une application WEB écrite en PHP.

DEVA : Volume du logiciel: 

en cours d'évaluation

DEVA : Qualité du logiciel: 

Cette version 2 de notre TDB met l'accent sur la réutilisabilité et l'extensibilité. L'analyse des données selon la méthode MERISE a été effectuée dans un souci constant de créer un modèle respectant ces deux critères. Au final l'application pourra s'intégrer dans n'importe quel SI et différentes briques pourront lui être ajoutées afin de créer de nouveaux indicateurs. La création d'indicateurs saisis "manuellement" garantira aussi un usage simple pour des suivi SSI du type : budgets ssi/budget globaux, interventions ssi/toutes interventions, nombre de plaintes, nombre de déclartion à la Cnil, ...
L'utilisation de composants génériques libres permet aussi d'assurer une compatibilité avec les environnement d'implantation.

DEVA : Version actuelle du développement: 

2

DEVA : Début du développement: 

Avril 2007

DEVA : Nombre de versions précédentes du développement: 

1

DEVA : Temps développement effectué: 
4 h/mois
DEVA : Utilisation actuelle du logiciel: 

le niveau opérationel du tableau de bord est en production la cartographie colorée des entités est en permanence visible dans le service et permet de réagir très vite aux évolutions et facilite les diagnostics. Au niveau pilotage le suivi des indicateurs de charge et de budget sont utilisés.

DEVA : Fonctionnalités... à ajouter: 

Modification du modèle de données, Paramétrage de ZABBIX (nouvelle version) afin d'auditer les nouveaux moyens et alimenter les nouveaux indicateurs définis. Refonte des scripts de collecte de la version 1. Développement des scripts PHP, des pages html et CSS de l'application.

DEVA : Besoins nécessaires pour finaliser: 

Financement du stagiaire participant au projet sur 2 mois à la suite de son stage

DEVA : Evolutions envisagée à long terme: 

Rapprochement avec les projets en cours au sein du pôle sécurité des rectorats (niveaux pilotage et stratégiques)
intégration de l'outil au niveau de la boîte à outil SSI en cours de réalisation au Ministère (MESR)

DEVA : Autres informations données: 

La définition des indicateurs a été guidée par l'usage de la méthode TDBSSI de la DCSSI

DEVA : MOTS CLES de la fiche: 
.
Syndiquer le contenu