Catégorie : Sécurité

Détection d’intrusion machine avec OSSEC

Antoine 3 commentaires

Ça fait un petit bout de temps que je n’ai pas posté sur mon petit blog car j’ai été très occupé avec mon déménagement. Ça commence désormais à se calmer. Cet article fait suite aux deux précédents articles : la présentation globale de la détection d’intrusion et la présentation illustrée de la détection d’intrusion.

Tout d’abord, je vais replacer la détection d’intrusion machine dans son contexte. Nous avons vu dans le billet précédent qu’il existait différents types de sondes de détection d’intrusion. Un de ces types de sonde de détection d’intrusion sont les HIDS pour Host Intrusion Detection System. L’objectif va donc être de faire des remontées d’information et de l’analyse primaire des ces remontées d’information. La spécificité d’une sonde HIDS est le lieu de son application, à savoir, les systèmes.

Un système peut être un système d’exploitation « classique » tel que Linux, Windows, Solaris, … mais aussi un système d’exploitation de routeur, firewall ou autre équipement réseau. Nous allons donc essayer de mettre en place une sonde HIDS.

ossec_logo

J’ai choisi de vous présenter la sonde HIDS OSSEC. J’ai choisi cette sonde parcqu’elle est particulièrement simple à utiliser et qu’il s’agit d’un logiciel libre. Elle est disponible pour Linux/Unix mais aussi Windows ce qui en fait une solution compatible sur une grande majorité de systèmes. Elle est capable de faire de la remontée d’information et de l’analyse sur des fichiers de logs standard mais aussi de détecter des intrusions type rootkit. Dans l’idéal, il est nécessaire d’installer un agent sur chaque machine que l’on souhaite monitorer mais il est également possible de faire sans agent (via SSH).

Installation

L’installation se fait très simplement en téléchargeant les binaires présents sur le site d’OSSEC. On exécute ensuite le binaire d’installation et on se laisse guider par les étapes.

# wget http://www.ossec.net/files/ossec-hids-2.1.1.tar.gz

# tar zxvf ossec-hids-2.1.1.tar.gz

# cd ossec-hids-2.1.1/

# ./install.sh
** For installation in English, choose [en].
** Para instalar en Español , eliga [es].
** Pour une installation en français, choisissez [fr]
(en/br/cn/de/el/es/fr/it/jp/nl/pl/ru/sr/tr) [en]: en

Désolé pour les erreurs d’accents…  On arrive ensuite sur l’invite de paramétrage de l’installation.

OSSEC HIDS v2.1 Installation Script – http://www.ossec.net

You are about to start the installation process of the OSSEC HIDS.
You must have a C compiler pre-installed in your system.
If you have any questions or comments, please send an e-mail
to dcid@ossec.net (or daniel.cid@gmail.com).

– System: Linux courbevoie.benkemoun.com 2.6.27.10-grsec-xxxx-grs-ipv4-32
– User: root
– Host: courbevoie.benkemoun.com

— Press ENTER to continue or Ctrl-C to abort. —

1- What kind of installation do you want (server, agent, local or help)?

Comme vous le voyez, OSSEC vous donne la possibilité de le paramétrer en tant qu’agent ou serveur. En effet, OSSEC peut également jouer le rôle de SIM ou plutôt d’agrégateur d’information. Dans ce cas, une machine servira d’agrégateur de logs OSSEC. Vu qu’on installe OSSEC pour une seule machine, on la mettra en serveur.

Il défile ensuite un certain nombre de questions qui vous permettront de configurer OSSEC comme vous le souhaitez. Vous avez donc installé OSSEC, simple non ? Vous pouvez ensuite configurer les options et les fichiers de log que vous souhaitez analyser. La documentation sur le site d’OSSEC est particulièrement claire.

Si vous souhaitez visionner les remontées d’information d’OSSEC, je vous conseille fortement l’interface web OSSEC qui est sommaire mais efficace. L’installation est très simple à effectuer. Je vous dirige vers le tutoriel sur le wiki d’OSSEC qui explique tout ce qu’il y a à expliquer.

ossewui

Au final, OSSEC est une solution très simple à mettre en place pour avoir une détection d’intrusion simple et basique.  OSSEC remplace aisément un syslog tout en rajoutant des fonctionnalités d’analyse et de classement des incidents.

La détection d’intrusion illustrée

Antoine 5 commentaires

network-security-fingerSuite à mon précédent article sur la détection d’intrusion, je n’ai pas eu l’impression d’avoir été particulièrement clair et limpide. Je pense que le manque de clareté vient surtout du fait qu’il s’agissait d’un article plutôt théorique. Pour ce nouvel article, je vais donc essayer de me concentrer sur l’illustration pratique de la détection d’intrusion.

Fonctionnement global

Comme je l’ai expliqué précédemment, la détection d’intrusion a pour objectif de détecter les activités anormales sur les divers équipements informatiques. Elle permet donc une visibilité élargie sur les incidents de sécurité du réseau. Cette visibilité élargie provient de deux élements : la corrélation et l’analyse. La corrélation est la technique qui met en relation les remontées d’information de plusieurs équipements afin de trouver de similitudes. L’analyse est ce qui permet d’interpréter des remontées d’informations afin d’en tirer une conclusion intelligible. Ceci fera l’objet du second schéma. Ce premier schéma a pour objectif d’illustrer le fonctionnement global.

DetectionIntrusion

Sur ce schéma, on voit tout d’abord notre réseau « de base » symbolisé par la grande barre bleue. Sur ce réseau, nous avons nos serveurs / postes de travail connectés. En sortie de réseau, nous avons un firewall avec une patte vers Internet et une patte dans notre réseau. On va ensuite distinguer deux types de détection d’intrusion : la détection d’intrusion machine (HIDS pour Host Intrusion Detection System) et la détection d’intrusion réseau (NDIS pour Network Intrusion Detection System).

Afin de mettre en place la détection d’intrusion machine, il va être nécessaire d’installer une sonde sur chaque serveur ou équipement réseau que l’on souhaite inclure dans le système de détection d’intrusion. Ces sondes rempliront différentes fonctionnalités de récolte d’information et d’analyse primaire. Je ferais un article couvrant plus spécifiquement ce type de détection d’intrusion. On parlera donc de sonde HIDS. Les sondes peuvent être de différents types en fonction de ce que l’on souhaite faire et en fonction du SIM. Des exemples de sonde HIDS sont OSSEC, Samhain ou Tripwire.

Ensuite, afin de mettre en place la détection d’intrusion réseau, il va être nécessaire d’installer une sonde sur le réseau. Le raccordement de cette sonde diffère d’un système standard car par défaut elle ne recevrait que le trafic qui lui est destiné. Ainsi, elle n’aurait qu’une vue très réduite du réseau. Pour qu’une sonde NIDS soit efficace, il faut qu’elle reçoive la totalité du trafic du réseau. Cette fonctionnalité peut s’appeller « Port Mirroring » ou « Port monitoring ». La sonde effectuera une analyse primaire de tous les paquets qu’elle va recevoir. Un exemple de sonde NIDS est Snort.

Le résultat de l’analyse primaire effectuée par ces sondes sera ensuite envoyé au SIM (Security Information Management). Le SIM est l’élément qui va recevoir toutes les remontées d’informations des différentes sondes NIDS et HIDS. Il fera ensuite entrer en jeu la corrélation afin de pouvoir interpréter de manière plus globale ces informations ainsi que l’analyse de la globalité des informations. Il stockera ces informations en base de données afin de pouvoir créer un historique des événements réseau et de pouvoir retracer des incidents.

Analyse des remontées d’information

Je pense que le schéma de fonctionnement global a du clarifier le fonctionnement d’un système de détection d’intrusion d’un point de vue architectural. Je vais ensuite détailler le cheminement de l’analyse d’un événement de sécurité. Le schéma suivant prend pour exemple une tentative (certes légère) de bruteforce d’un serveur SSH.

DetectionIntrusionAnalyse

Les cylindres du bas représentent les différents fichiers de log qui peuvent se trouver sur une machine physique ou bien sur un équipement réseau.

On voit sur ce schéma que les fichiers de logs vont remonter des informations brutes qui correspondent à l’utilité qui est faite de l’application. Iptables va remonter un nombre de sessions TCP, auth va remonter une erreur dans un mot de passse et SSHD va remonter une erreur d’authentification. Le HIDS va récolter ces informations à travers la lecture continue des ces fichiers de logs et envoyer les informations au SIM. Le SIM va ensuite interpréter ces informations et en tirer une conclusion bien plus concrète que les messages de logs précédents.

En pratique, des remontées d’information aussi basiques seront interprétés directement par l’HIDS qui transmettra son interprétation au SIM. Le SIM a plus un rôle de corrélation de différentes sources et d’analyse d’événements conjoints qui mis bout à bout peuvent avoir une signification plus intéressante.

Au final, j’espère que cet article permettra de clarifier un peu plus les choses.

Définition et principe de la détection d’intrusion

Antoine 3 commentaires

network-security-fingerJe vais entamer une petite série d’articles sur la détection d’intrusion. Le but est de faire un tour d’horizon de cette technique et de présenter un début de mise oeuvre. Par la suite, je m’attarderais plus sur la détection d’intrusion machine (HIDS) car il s’agit du type que je connais le mieux.

Qu’est ce que la détection d’intrusion  ?

Tout d’abord, il est nécessaire d’éclaircir le principe de la détection d’intrusion avec de pouvoir s’attarder sur son intérêt. Voici la définition que propose Wikipedia de la détection d’intrusion :

Un système de détection d’intrusion (ou IDS : Intrusion Detection System) est un mécanisme destiné à repérer des activités anormales ou suspectes sur la cible analysée (un réseau ou un hôte). Il permet ainsi d’avoir une connaissance sur les tentatives réussies comme échouées des intrusions.

Cette définition est assez claire. La détection d’intrusion est donc un mécanisme actif qui se définit par l’objectif à atteindre. Les techniques de détection d’intrusion visent donc à atteindre cet objectif de détection des tentatives d’intrusion. Il existe une quantité indénombrable de techniques et de solutions de détection d’intrusion. Cependant, la détection d’intrusion n’est pas juste un phénomène de mode marketing mais répond à un besoin de visibilité sur les incidents de sécurité.

Qu’apporte la détection d’intrusion ?

Les équipements de sécurité et méthodes de sécurisation traditionnelles se limitaient à la simple remontée d’information et à un blocage selon des critères simplistes. Au niveau du réseau, cela se résume à l’ouverture et à la fermeture de ports de niveau 4 suivies d’une remontée sous forme de lignes de journalisation (lire log pour les anglophiles). Au niveau de chaque machine, cela se limitait à la remontée d’informations en local via un « syslog » (journal d’incident d’un système d’exploitation).

Ces mesures permettent d’avoir un minimum d’informations quant au comportement basique d’un système ou d’un réseau. Cela ne suffit cependant plus dans le monde informatique d’aujourd’hui. Croire que cela suffit semble être une erreur assez monumentale et l’actualité ne cesse de le démontrer … Le hack de twitter ou bien l’attaque DoS sur Twitter/Facebook n’auraient pas pu être empêché par du filtrage de niveau 4 ou bien un syslog local d’une machine.

La détection d’intrusion se définit souvent comme l’ensemble des techniques qui vont permettre d’aller au delà de ces moyens traditionnels de sécurisation.

La détection d’intrusion va s’attarder sur l’analyse des événements et la mise en perspective par rapport à une base de connaissances sur des attaques/menaces de sécurité connues. Au lieu de faire une simple remontée d’information, la détection d’intrusion va analyser les informations remontées afin de pouvoir émettre une suggestion sur le problème de sécurité rencontré au lieu de ne s’attacher qu’aux simples constatations. Cette composante pourrait se résumer en tant qu’analyse approfondie et interprétation des informations remontées.

La détection d’intrusion va également rassembler plusieurs sources d’informations pour pouvoir établir une corrélation. Un système de détection d’intrusion va rassembler les informations de nombreuses sources afin de pouvoir détecter des événements globaux. Par exemple, une attaque peut être détectée au niveau du réseau mais être cataloguée inefficace car elle n’a pas atteint les systèmes.

Au final, la détection d’intrusion est un terme assez générique pour désigner les méthodes modernes de remontée de d’analyse des informations relatives aux attaques/menaces de sécurité.

Le prochain article s’attardera sur la détection d’intrusion au niveau des machines et je parlerais surement d’OSSEC dans la foulée.

Suite : La détection d’intrusion illustrée

Un client OpenVPN pour Mac OS : Viscosity

Antoine 8 commentaires

Je suis heureux possesseur d’un MacBook depuis Octobre dernier. Avant cet achat, j’avais toujours été un utilisateur de PC en tous genres sous Windows puis sous Linux. Le passage à Mac fait un certain changement. Je ne parlerais pas d’un gros changement car en tant qu’utilisateur de Linux, on retrouve assez vite des repères.

Qui dit PC portable, dit mobilité. Qui dit mobilité, dit hotspot wifi non sécurisés. Un portable est donc une machine particulièrement sensible en terme de confidentialité des données et des échanges avec Internet. Utiliser Internet sur un hotspot public est particulièrement peu sécurisé surtout dans les grands lieux publiques tels que les gares SNCF. Il est possible de récupérer tous types de données transmises en clair très simplement. De plus, lorsqu’on se retrouve sur un réseau convenablement protégé de nombreux ports sont bloqués et il peut s’appliquer un filtrage web.

L’utilisation d’OpenVPN s’impose donc. Je sais qu’il existe de nombreuses alternatives payantes telles que Cisco VPN ou autres mais pour une utilisation personnelle, c’est plutôt superflu. Lorsque mon PC portable était sous Ubuntu, l’utilisation d’OpenVPN était tout à fait simple. Il suffisait de refaire le fichier de configuration en se calquant sur le serveur et le tour était joué. Au passage, pour installer OpenVPN, je vous conseille de consulter le tutoriel de Smurf disponible sur le site de Gayux.

Pour les utilisateurs de MacOS, je vous recommande donc chaleureusement l’application Viscosity.

L’installation se fait de manière tout à fait simple. Il suffit d’ouvrir le .dmg et de cliquer sur l’installeur. Il vous demandera plusieurs fois votre mot de passe root afin de pouvoir installer les différents modules nécessaires à son bon fonctionnement.

La configuration se fait de manière très simple. L’intitulé des champs à renseigner ressemble beaucoup aux différentes directives du fichier de configuration d’OpenVPN. Vous avez également la possibilité de visionner le log de la connexion à votre serveur VPN afin de pouvoir détecter de potentielles erreurs.

gui1

Cette application vous permet également de visionner quelques statistiques d’utilisation de votre liaison VPN. C’est pas super utile mais non moins joli.

detailswin

Une petite icône présente sur la barre du haut de votre écran vous permet à tout moment d’avoir un aperçu de l’état de votre connexion et de passer d’un VPN à un autre.

screenshot1_small

Au final, Viscosity est une application très efficace qui fait ce qu’on lui demande de faire. En plus, elle est plutôt jolie. Vous pouvez l’essayer gratuitement pendant 30 jours et puis ensuite vous pourrez l’acheter pour la modique somme de 9 USD.

Sécuriser un serveur Apache avec PHP : suPHP

Antoine 3 commentaires

suphp_logoCe billet fait suite aux précédents billets sur le sujet de la sécurisation d’Apache avec PHP à savoir la problématique et un premier élément de réponse. Pour résumer rapidement, nous avons vu les problèmes que posait une installation par défaut d’Apache supportant le PHP dans le cas d’un serveur web mutualisé tel qu’on pourrait le trouver chez un hébergeur. Nous avons ensuite vu comment la configuration PHP pouvait influer sur la sécurité de l’installation.  Dans ce billet, nous allons voir la configuration et l’utilisation de suPHP.

Objectif

J’avais parlé de la problématique des droits avec lesquels s’exécutent les scripts PHP ainsi que du fait qu’il n’y ait qu’un seul fichier de configuration PHP pour tous les sites présents sur une même machine. Le module Apache dénommé suPHP va permettre de répondre à ces deux problématiques et de rajouter même quelques fonctionnalités supplémentaires. Si on va sur leur site, on se rend bien compte que l’objectif de suPHP est d’exécuter les scripts PHP avec les droits du propriétaire du script. Ceci va nous permettre d’attribuer un utilisateur par site et donc d’obtenir un meilleur cloisonnement. Nous verrons par la suite plus en détail la configuration et les possibilités offertes par suPHP.

Installation de suPHP

Sur une distribution de type Debian, l’installation se fait via le gestionnaire de paquet traditionnel apt-get.

# apt-get install libapache2-mod-suphp

# a2enmod suphp

Sur les autres distributions, vous pourrez soit passer par le gestionnaire de paquet soit par la compilation à la main. Comme pour tous les modules Apache, la compilation à la main est très simple et efficace. Il ne faut juste pas oublier de déclarer le module dans le fichier de configuration d’Apache.

Configuration de suPHP

Une fois que vous avez installé suPHP, vous n’avez finalement pas rajouté beaucoup de sécurité dans votre installation. Il va falloir s’atteler à la configuration. La première étape de la configuration est de s’assurer que chaque site ait son propre utilisateur. Sans cette mesure, suPHP est largement moins efficace. On va ensuite étudier le fichier de configuration de suPHP qui se trouve dans /etc/suphp/suphp.conf.

;Path all scripts have to be in
docroot=/data/www

Cette directive vous permet de configurer le répertoire dans lequel suPHP aura le droit d’exécuter des scripts PHP. Les scripts en dehors de ce répertoire ne seront pas exécutés et le serveur web affichera une erreur 500 (Internal Server Error).

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

Ce jeu de directives va vous permettre d’autoriser ou non vos utilisateurs à mettre des droits très élargis à leur fichiers. Par exemple, si vous activez la première directive, suPHP refusera d’exécuter les scripts PHP qui permettent l’écriture par le groupe du propriétaire du fichier. A vous de voir si vous voulez implémenter ce type de restrictions. Je ne trouve pas ca très utile si vous avez bien réglé la directive PHP open_basedir.

; Minimum UID
min_uid=100
; Minimum GID
min_gid=100

Ce jeu de directives vous permet de paramétrer l’UID et le GID minimal avec lequel peuvent être exécutés des scripts PHP.  Ceci va vous permettre d’éviter que des scripts soient exécutés avec l’utilisateur www-data voire root. Il existe d’autres lignes de configuration que je n’ai pas explicitées ici. Je vous invite à consulter la documentation pour en savoir plus.

Configuration du VirtualHost

Une fois que nous avons correctement configuré suPHP, il n’est toujours pas actif. Il va falloir l’activer au cas par cas en fonction du VirtualHost. Ceci permet d’avoir une meilleur finesse de réglage quant à l’activation de ce module. Rien de plus simple pour l’activer il suffit de rajouter la ligne suivante dans le VirtualHost.

suPHP_Engine On

On va pouvoir ensuite rajouter plusieurs réglages fournis par suPHP afin d’implémenter plus de sécurité et de flexibilité. Comme je vous en avais parlé précédemment, il va être possible d’attribuer un fichier php.ini par VirtualHost. Il est essentiel que vos clients ne puissent pas modifier ce php.ini directement. Si cela est possible, il sera possible à n’importe qui de modifier la directive open_basedir supprimant ainsi un niveau de sécurité. On va donc rajouter la directive suivante :

 suPHP_ConfigPath /data/www/********.com/priv/php.ini

Au final, à travers ces trois billets nous avons pu faire un tour d’horizon permettant la sécurisation d’un serveur Apache doté de PHP. Je pense que l’implémentation des fonctionnalités présentées à travers ces trois billets permet d’atteindre un niveau de sécurité correct sur un serveur web mutualisé. Il n’existe bien sûr par de sécurité parfaite. Il faut surtout adopter une hygiène de configuration et de paramétrage en association avec la configuration correcte des modules associés.

Sécuriser SSH, c’est pas bien compliqué

Antoine 6 commentaires

doc_openssh_logo_2Vous le savez peut être déjà, une faille semble avoir été trouvé dans SSH. Pour ceux qui n’ont jamais fait d’administration système, le protocole SSH est le protocole utilisé pour administrer les serveurs Linux/BSD ainsi que de très nombreux équipements réseau. Qui dit faille SSH dit accès total aux machines disposant de ce service. Pour vous rassurer, la faille semble ne toucher que les versions les plus vieilles d’OpenSSH. Vous qui disposez d’une Debian, vous êtes à l’aise car vous savez que Debian a un cycle de release assez rapide. Vous qui croyiez être à l’aise sur votre RHEL (Red Hat Entreprise Linux) ou CentOS et la stabilité qu’un cycle de release lent, vous devez être plus stressé et vous avez bien raison ! Cependant, elle semble peu crédible et basée sur de très nombreuses hallucinations suppositions.

Constat

Tout le monde le sait, le SSH est probablement le protocole le plus sensible sur une machine ou un équipement voire sur Internet. Il semble cependant régner un climat de confiance excessive autour de ce protocole. Dans le même temps, d’autres protocoles sont ultra surveillés comme c’est le cas pour HTTP ou DNS alors qu’ils sont moins sensibles. Je pense que dire que SSH est le protocole le plus sensible n’est pas une exagération trop importante. Certes le protocole DNS est ultra critique, mais une faille sur le protocole SSH permettra la modification des zones DNS présentes sur la machine. Une faille SSH permettra de prendre la main sur les routeurs et de modifier les informations BGP et ainsi de suite.

Bloquer les accès

La plus simple des parades à toutes les failles éventuelles sur SSH est de bloquer l’accès à ce dernier. Bien sur, si vous bloquez l’accès complètement, vous ne pourrez plus administrer vos machines mais il y a tout de même des solutions. Il est indispensable de ne pas autoriser la terre entière à accéder à votre serveur SSH. On ne peut pas considérer le service SSH sécurisé si il est accessible par la terre entière. Vous pouvez mettre une règle de filtrage permettant de n’autoriser que l’IP de votre connexion Internet. Si vous avez une connexion avec IP dynamique, vous pouvez utiliser OpenVPN pour accéder à votre zone de serveurs et n’autorisez la connexion qu’à partir du serveur VPN. Si vous êtes une société avec un minimum de moyens, mettez en place un tunnel MPLS jusqu’à votre datacentre.

L’accès en root, c’est mal…

Il est également peu raisonnable d’autoriser les accès SSH directement en root. Si vous donnez le mot de passe root à tous les utilisateurs de la machine, il sera plus difficile de leur en interdire l’accès par la suite. Ceci est d’autant plus grave si votre serveur SSH est accessible par tout le monde. De plus, un accès avec un compte utilisateur permet d’éviter que tout le monde puisse faire rm -Rf / par erreur. Une exception existe à cette règle, si votre filtrage au niveau du réseau est suffisament efficace et que vous avez la possibilité de supprimer l’accès en supprimant l’accès au VPN, il est possible d’accéder directement en root aux serveurs.