mise en place d’un système de détection d’intrusion réseau · 2017-04-11 · baptiste moine...

Baptiste MOINE Installation et configuration d’un IDS ~ 1 ~

Mise en place d’un système de détection

d’intrusion réseau

CONTEXTE ............................................................................................................. 1

TRAVAIL DEMANDE .................................................................................................. 1

CONCEPTS GENERAUX............................................................................................. 2

CAHIER DES CHARGES ............................................................................................. 8

INSTALLATION DE DEBIAN JESSIE (8.0) ...................................................................... 10

INSTALLATION DE SSH ............................................................................................ 11

CONFIGURATION DU PARE-FEU ............................................................................... 13

INSTALLATION DE APACHE ...................................................................................... 15

INSTALLATION DE MYSQL-SERVER.............................................................................. 16

INSTALLATION DE DVWA ....................................................................................... 17

INSTALLATION DE SURICATA EN MODE IPS ................................................................. 18

CONFIGURATION DE SURICATA ............................................................................... 19

INSTALLATION DE SNORBY ....................................................................................... 21

INSTALLATION DE BARNYARD2 ................................................................................ 24

GESTION DES REGLES AVEC OINKMASTER ................................................................. 25

INFORMATIONS SUPPLEMENTAIRES ............................................................................ 27

CONTEXTE

Période de formation en milieu professionnel en première année de BTS SIO (2014-2015)

au Centre des Ressources Informatiques (CRI) de l’Ecole Supérieur National de

Mécanique et d’Aéronautique (ENSMA).

TRAVAIL DEMANDE

Mettre en place une solution de détection d’intrusion (IDS) pour repérer les attaques et

intrusions qui ont réussi et celles qui ont échoué grâce aux systèmes actifs de protection

sur le réseau.


CONCEPTS GENERAUX

L’IDS

Avec la création d’un Internet basé sur l’anonymat appelé « TOR », la diffusion à grande

échelle de faille 0day mais aussi de pack d’exploitation (exploit pack), n’importe quel

initié aux nouvelles technologies et à leur aspect de sécurité est capable de procéder à

une attaque ciblée sans pour autant en connaitre le fonctionnement. Ainsi les

technologies des systèmes de détection d’intrusion ont connus un engouement

considérable de la part des sociétés à grande renommée.

Un IDS a principalement pour fonction d'analyser l'activité d'un réseau ou d'un hôte

donné en temps réel ou différé, afin de détecter toute tentative d'intrusion et d’agir face

à cette tentative, par exemple en exécutant un script préconfiguré permettant d’agir

sur le pare-feu du système distant pour rejeter les autres requêtes de l’hôte ayant

effectué ou tenter une intrusion, cependant un IDS reste moins performant qu’un IPS

(Intrusion Prevention System) lorsqu’il s’agit de rejeter les requêtes suite à la découverte

d’une intrusion, on parle alors d’action passive lors de la détection et active lors du rejet

de connexion par exemple. Un IDS peut analyser les éléments de la couche Application

(7), Transport (4) et Réseau (3) du modèle OSI. Il permet également, en fonction de la

solution adoptée, d’alerter l’administrateur par e-mail voire en utilisant des modules

« homemade », d’envoyer un SMS afin de lui permettre d’appliquer un correctif ou

encore d’entreprendre un processus judiciaire.

Cela a pour but, en repérant les activités et évènements anormaux ou suspects, d'avoir

une action de prévention sur les différents risques d'intrusion.


Les fonctionnalités d’un IDS

Un IDS possède diverses fonctionnalités permettant la détection d’anomalies tel que :

Une anomalie relative à une attaque ciblée, en règle générale un IDS permet

dans ce cas de :

Détecter les analyses réseau par découverte globale, il s’agit des prémices

d'une attaque informatique. En effet, l’attaquant va procéder à une

découverte globale de l’architecture du SI en utilisant des outils permettant

tout d’abord de lancer de manière récursive des requêtes ARP afin de mapper

l’ensemble des hôtes présent sur le réseau, l’attaquant va ensuite pouvoir

interroger par « force-brute » tous les ports de connexion TCP ou UDP et

attendre une réponse. En fonction des réponses, l’attaquant est capable de

connaître, par exemple, la version du protocole interrogé ;

Détecter le DoS (déni de services), permettant à l’attaquant en envoyant des

requêtes arbitraires, de par exemple, en diminuant le temps de réponse des

services, de pouvoir usurper ce service et dérober les données d’un client

(spoofing) ;

Détecter l’exploitation de vulnérabilité protocolaire ou applicative, par

exemple en détectant l’utilisation de « shellcode », il s’agit d’un code

assembleur permettant l’exécution d’un interpréteur de commande SHELL en

altérant le fonctionnement initial du protocole/programme ;

Détecter le résultat de l’exploitation, en récupérant par exemple la réponse du

service (par exemple, authentification réussie).

Une anomalie relative à une attaque globale du réseau, par exemple l’utilisation

d’un « ver ». Un ver est un programme malveillant capable de s’auto-répliquer sur

l’ensemble des machines en exploitant leurs vulnérabilités (rebonds). Dans ce cas

un IDS est capable de :

Cartographier ou lister l’ensemble des zones touchées par cette infection ;

Identifier si possible la source de l’infection, le cas échéant il est alors possible

d’identifier la source voire l’auteur de l’infection. En effet dû aux nombreuses

infections, il devient très compliqué de comprendre d’où vient l’infection

initiale dans la mesure où les machines infectées deviennent à leur tour les

sources de l’exploitation.

Une anomalie relative à un disfonctionnement applicatif ou protocolaire, à une

mauvaise configuration ou un délai de réponse anormal. Dans ce cas un IDS

permet de :

Proposer le remplacement de protocoles obsolètes, par exemple en détectant

l’utilisation de Telnet ;

Indiquer à l’administrateur des délais de réponse anormalement long, ce

genre d’information peut paraitre anodin mais peut par exemple révéler

l’existence d’une porte dérobé sur l’hôte distant.

En résumé un IDS permet de :

Collecter et analyser les traces et les preuves d’une intrusion, ceci permettant de

lancer un processus judiciaire ;

Alerter et journaliser de manière centralisée la découverte d’intrusion ;

Agir de manière préventive ou curative aux anomalies.


Architecture d’un IDS Un IDS est composé de plusieurs niveaux :

La source de données, en général il s’agit de captures de trames réseaux ou de

journaux de systèmes distants ;

Le senseur, il s’agit du niveau où se passe tout le procédé d’analyse et de

détection ;

Le filtre ou canal de réponse, il permet à l’administrateur de classer les résultats,

en utilisant par exemple des motifs ;

La console, elle permet à l’administrateur d’effectuer le monitoring à partir des

réponses de l’IDS.

DétectionDonnées

Canal de réponseMoteur d’analyseAlerte Réponse

Host-Based IDS

Network IDS

Router IDS

Application IDS

Détectiond’abus

Détectiond’anomalie

Détectiondes spécificités

Figure 1 - Architecture d'un IDS

Catégories d’IDS

En considèrent les différentes sources de données utilisées pour la détection d’intrusion,

une autre classification des IDS peut être utilisée en termes de type d’éléments

protégés :

Le HIDS (host based IDS), il utilise les informations d’un seul hôte (ou système) ;

Le NIDS (network based IDS), ilexploite l’audit d’un segment du réseau local.

IDS

Détéction Protection Structure Sources Action Traitement

À la volée IntervalleÉtatPaquetNNIDSHIDS NIDS Trace

Anomalie Signature Centralisé Distribué Active Passive

Agent système

Figure 2 - Catégories d'IDS


Le HIDS

Plusieurs types de HIDS peuvent être distingués :

Un système d’analyse les flux et tentatives de connexion entrantes (par

exemple : RealSecure Agent et PortSentry). Ce système examine les connexions

réseaux entrantes et sortantes basées sur un hôte. Il est spécialisé dans la

détection de tentative de connexion non autorisées à un port TCP ou UDP et

peut aussi détecter les scans de ports ;

Un système d’analyse du trafic réseau entrant d’un l’hôte. Ce système protège

l’hôte en interceptant les paquets suspectés comme malveillants ou

ressemblants à un payload ;

Un système d’analyse d’authentifications sur la couche réseau du modèle OSI

(par exemple: HostSentry). Son rôle est d’analyser les demandes

d’authentifications et dés-authentifications, détecter des activités anormales

sur le système en fonction de l’heure, de l’emplacement réseau ou d’un

nombre de connexion échouées anormalement élevé ;

Un système d’analyse des actions effectués par le super utilisateur (root), qui

possèdes les plus haut privilèges du système (par exemple :LogCheck). Son rôle

est de journaliser les actions effectués à une heure particulière ;

Un système d’analyse d’intégrité de fichiers (par exemple : Tripwire et AIDE).

Cet outil permet la détection de modification sur des fichiers critiques pour le

système ;

Un système d’analyse de la base de registre (uniquement sous Windows). Il

permet de détecter toutes modifications non autorisées de la base de registre

du système et alerter l’administrateur du système ;

Un système d’analyse d’intrusion dans le noyau du système. Ces outils sont

utilisés principalement sur des systèmes basés sur Unix (Linux, BSD, MAC, etc.)

(par exemple : LIDS et OpenWall). Cet outil analyse l’état du système

d’exploitation ainsi que les flux, ceci permet de prévenir des attaques par

débordement (Buffer, Heap, Stack Overflow), il permet également de rejeter

les communications anormales interprocessus, il est également capable de

réduire les privilèges du super-utilisateur (root) en cas de besoin.

Le HIDS est installé sur l’hôte ou système protégé et fournit en général une protection

pour cet hôte uniquement. Il est ainsi capable aisément de détecter une attaque dans

le sens où il possède une vision claire de ses ressources locales.


Le NIDS

Les systèmes de détection d’intrusion par écoute et analyse du trafic sur certains points

du réseau, appelée NIDS assurent la sécurité au niveau du réseau. Il permet d’écouter et

étudier les trames transitant sur le réseau. Il assemble et analyse tous les paquets

traversant sa carte d’interface réseau en mode promiscuité, c’est-à-dire que le système

accepte tous les paquets atteignant la carte d’interface réseau indépendamment de

leur destination. Un NIDS peut être installé sur un actif réseau de niveau 3 du modèle OSI,

par exemple un routeur.

Le système de détection d’un NIDS est basé sur deux grandes méthodes d’analyse :

La détection par signature, consiste à rechercher dans l’activité du réseau

surveillé l’empreintes d’attaques connues, en effet la plupart du temps un

attaquant ne « s’embête » pas à recréer un nouveau procédé d’exploitation et

réutilise des procédés ayant déjà apporté une preuve de leurs concept, ce

genre de procédé d’exploitation abrégé par PoC (Proof of Concept) est bien

souvent partagé et déclaré dans la base de donnée CVE (Common

Vulnerabilities and Exposures) référençant les attaques les plus connues dans le

cas contraire, on appelle cela une faille 0day car elle ne possède pour l’heure

d’aucun correctif. Un NIDS peut donc par exemple détecter ou soupçonner une

tentative d’intrusion en trouvant un shellcode dans une requête DNS (peu

probable qu’un DNS demande l’ouverture d’un SHELL nativement).

La détection par anomalie, consiste à détecter un changement ou altération de

fonctionnement d’un système, ainsi tout le trafic provenant du service est signalé

comme potentiellement malveillant. Cette méthode possède l’avantage de

pouvoir détecter une attaque 0day.

Ces deux méthodes de détection supposent que l’on soit passé par une phase de

collecte pour permettre au NIDS d’« apprendre » le fonctionnement d’un protocole ou

d’un système.

Une variante des NIDS, est le NNIDS (Network Node IDS) qui possède un agent déployé

sur chaque hôte du réseau protégé, typiquement un NIDS utilise un agent réseau pour

analyser tout le segment de réseau local. La principale raison d’utiliser ce genre de

système plutôt que le NIDS est qu’il est capable d’analyser les flux chiffrés (par exemple :

le HTTPS ou SSH).


L’IPS

Comme le dit le dicton, « Mieux vaut prévenir que guérir », un IPS a donc principalement

pour fonction de prévoir la possibilité de trouver une intrusion et de la bloquer dès que

possible. Il est en fait basé sur un IDS mais ajoute des fonctionnalités de blocage pour les

anomalies ou vulnérabilités trouvées. Lorsqu’un IDS traite activement une attaque, on

parle d’IPS.

Lors de la découverte d’une vulnérabilité, un IPS est donc en mesure de :

Rompre la connexion du service ou hôte vulnérable, pour cela il se base sur des

règles de pare-feu ;

Ralentir la connexion afin de procéder à un correctif sans pour autant

interrompre les connexions des clients (haute disponibilité), pour cela il se base sur

la QoS ;

Ajouter une source de vulnérabilité à une liste noire (blacklist), pour cela il se base

sur un procédé applicatif mandataire (« proxy »).

Il a cependant l’inconvénient de provoquer des coupures intempestives du réseau et

souvent peux déclarer des faux positifs.

Un Pot de miel

Le pot de miel ou « HoneyPot », permet de déployer un serveur non-protégé et surveillé

contenant des données pouvant attirer un attaquant prévu pour collecter les activités

malveillantes.

Afin de fonctionner comme il se doit, le HoneyPot permet de :

Emuler un service réseau vulnérable ;

Analyser les shellcodes et payloads utilisées contre lui pour en extraire sa

localisation par identification (port(s) d’écoute, adresses IP source, etc.) ;

Emuler un succès d’exploitation, par exemple en émulant un shell qui journalisera

toute les saisies effectuées par l’attaquant mais acceptera uniquement des

commandes arbitraires, cela permet de comprendre et identifier le paradigme

utilisé par l’attaquant ;

Cet outil a pour grand avantage d’identifier des vulnérabilités 0day en piégeant un

attaquant dans un système étanche à toutes interactions, dit bac à sable (« sandbox »).

En identifiant des vulnérabilités 0day, il possible d’appliquer un correctif et donc de

rendre public cette vulnérabilité. De plus, il permet de se tenir à jour des dangers

encourus lors d’une infection par un malware dû à leur sophistication (par exemple :

« rombertik » qui a été découvert depuis peu de temps suite à une analyse dans les

laboratoires de Cisco).


binaireCollecte

Analyse AV

Attaquant

Surveillance Classification

Apprentissage

rapport label

modèle

label

exploitation

Figure 3 - HoneyPot - Méthode d'analyse

CAHIER DES CHARGES

Contraintes

Un système sécurisé n’est pas nécessairement moins performant ou plus surchargé

cependant, si l’on souhaite éviter l’intrusion, il faut prendre des mesures de sécurité

permettant le filtrage des requêtes. La solution la plus adapté doit donc :

Être une solution gratuite et de préférence libre ;

Permettre la protection d’un ensemble de serveur, mais pas nécessairement de

tous les hôtes dans la mesure où le parc est composé en grande partie de clients

itinérants et qu’il serait bien trop compliqué de déployer un agent sur chaque

hôte ;

Permettre une protection active et transparente aux yeux des utilisateurs ;

Journaliser les évènements sur le serveur SYSLOG déjà existant afin de faciliter

l’archivage ;

Offrir un maximum de facilité pour la reconfiguration en cas de panne ou de

nécessité de modifications du service ;

Être fiable pour répondre aux besoins, en effet le poids financier d’une attaque

est évalué à 350 milliards d’euros par an ;

Ne pas entrer en conflit avec un autre service/serveur existant.

Ressources exploitables

Infrastructure réseau + clients (voir synoptique 1)

Machine pour l’installation du service

Nom commercial : HP Compaq Ultra-Slim Desktop dc7900

Mémoire vive : 2048Mo

Processeur : Intel Core 2 Duo E8400 3GHz

Contrôleur graphique : Intel GMA 4500MHD

Disque dur : 160 GBSATA 3

Contrôleurs de domaine, possédant divers services :

Service DNS, WINS, DHCP (+BOOTP/PXE), annuaire Active Directory

Service de déploiement WDS (Windows Deployment Service) MDT

Serveur de journalisation SYSLOG.


Comparatif des solutions

Nom Licence Coût Utilisation Journalisation

Suricata Libre Gratuit NIDS/NIPS syslog, fichier, base

de données

Cisco IDS Libre Gratuit HIDS stdout, fichier,

email, syslog

Snort Libre Gratuit NIDS/NIPS syslog, fichier, base

de données

Solution retenue

Le choix parmi les HIDS et NIDS est délicat car chacun répond à des besoins spécifiques.

Le HIDS est particulièrement efficaces pour déterminer si un hôte est contaminé quant

au NIDS, il permet de surveiller l’ensemble d’un réseau contrairement au HIDS qui est

restreint à un hôte.

Quant aux méthodes de détection, chacune présente ses avantages et inconvénients.

La méthode par signature par exemple révèle peu de faux-positifs dans la mesure où les

signatures sont révélatrices de l’utilisation exacte d’une attaque, elle permet également

un diagnostic rapide et permet l’identification précise du procédé d’attaque,

cependant elle implique que l’attaque soit connue pour être détectée et peut être

contourné dans la mesure où l’attaquant peut modifier le payload et donc la signature.

Quant à la détection par anomalie, elle permet de détecter une attaque non-connue

(0day), facilite la création de règles adaptées à ces attaques et difficile à tromper,

cependant elle révèle de nombreux faux-positifs dans la mesure où le fonctionnement

d’un protocole peut évoluer, de plus il est nécessaire de passer par une phase

d’apprentissage permettant la compréhension des fonctionnements protocolaires et

applicatifs et le diagnostic peut s’avérer long en cas d’alerte.

Suite à un entretien avec l’équipe technique, nous avons décidé d’installer Suricata à

des fins expérimentales, SNORT étant déjà en phase de test, quant à Cisco IDS il n’est

pas abordable pour une phase de test qui pourrait s’avérer non concluante.

Comparatif des systèmes d’exploitation

Nom Licence Coût Mémoire vive Espace disque Processeur

Debian Libre Gratuit 512Mo 3Go 1GHz

CentOS Libre Gratuit 512Mo 2Go 500MHz

Ubuntu Libre Gratuit 192Mo 1Go 300MHz

Windows Server Pro Gratuit 512Mo 32Go 1.4 GHz


Système d’exploitation retenue

Étant donné qu’une machine est dédiée à l’installation de ce système, nous avons

choisis parmi les solutions qui seraient les plus rapides à mettre en route en prenant donc

en compte les compétences et l’expérience générale de l’équipe, la stabilité du

système mais aussi la possibilité de pouvoir former rapidement à l’administration de ce

système. Étant donné que Linux est un système dont on peut comprendre réellement le

fonctionnement technique, nous avons opté pour ce type de système. Quant à la

distribution, étant donné qu’il s’agit d’une phase de test dont je suis le principal acteur,

j’ai donc choisis la distribution qui selon moi est la plus stable, à savoir Debian Jessie.

INSTALLATION DE DEBIAN JESSIE (8.0)

Pour installer Debian Jessy, il faut commencer par télécharger l’image d’installation

depuis le site officiel, télécharger une image au format CD, dans la mesure où seul le

système basique sera installé (sans interface graphique). Une fois téléchargé, créer un

support d’installation, soit en gravant l’image disque soit en ajoutant une partition active

à une clé USB et en y copiant les fichiers de l’image d’installation de Ubuntu

(UnetBootin). Une fois le support d’installation préparé, il suffit de démarrer la machine sur

le support d’installation en modifiant les paramètres d’amorçage du BIOS.

Lorsque le programme d’installation s’affiche, procéder à une installation simple, sans

pour autant ajouter les utilitaires usuels du système ni une interface graphique (inutile

dans cette situation).

Configuration du système post-installation

Afin de pouvoir bénéficier d’une connectivité sur notre serveur et pouvoir y installer des

services, configurer l’interface Ethernet de la machine comme ceci :

1 $ sudo su -

2 # cat >> /etc/network/interfaces << EOT

3 allow-hotplug eth0

4 iface eth0 inet dhcp

5 EOT

6 # ifdown eth0; ifup eth0

Suite à la configuration dynamique de notre adressage IPv4 par DHCP, nous obtenons

cette configuration :

IP/CIDR : 192.168.251.104/24

Bail DHCP : 288961 secondes

DNS : 192.168.251.1

DNS secondaire : 192.168.251.2

Serveur DHCP : 192.168.251.1

Passerelle par défaut : 192.168.251.1

Pour conserver cette configuration IPv4, nous allons transformer ce bail en réservation sur

le serveur DHCP. Le service DHCP étant installé sur le contrôleur 1 (sous Windows Server),

http://www.debian.org/releases/jessie/


nous allons effectuer cette configuration en utilisant l’outil de gestion d’ouverture de

session à distance. De plus nous ajouterons cette configuration en statique dans le fichier

de configuration /etc/network/interface.

INSTALLATION DE SSH

Pour respecter le cahier des charges stipulant de faciliter l’administration de ce serveur,

nous installerons un service SSH pour prendre plus facilement le contrôle du serveur à

distance. Cependant à des fins purement sécuritaires, nous changerons le port par

défaut du service SSH et n’autoriserons que le réseau CRI.LAB à accéder au serveur SSH.

Pour installer un serveur SSH, nous allons installer le paquet openssh-server :

1 # sed -i 's/$deb cdrom$/# \1/' /etc/apt/sources.list # Commente les lignes concernant les CDROM

2 # printf "\ndeb http://httpredir.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

3 # apt-get update

4 # apt-get install -fy openssh-server

A présent nous allons configurer le service SSH de manière à le sécuriser au maximum

(tous les détails sont des commentaires et peuvent donc être laissés) :

1 # /etc/init.d/ssh stop # Stop le service SSH

2 # cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak # Sauvegarde la configuration actuelle

3 # cat > /etc/ssh/sshd_config << EOT

4 #### Configuration initiale de SSH2 ####

5 Port 54365 # Écoute sur un port non standard > 1024

6 Protocol 2 # Le SSH1 est moins sécurisé

7 AddressFamily inet # Restriction à IPv4

8 X11Forwarding no # Désactive la redirection d'une session X11

9 #### Prévenir des attaques par spoofing ####

10 TCPKeepAlive no

11 ClientAliveInterval 600

12 ClientAliveCountMax 3

13 ListenAddress 192.168.251.104 # Écoute uniquement sur cette interface (eth0)

14

15 #### Clés d'authentification pour SSH2 ####

16 HostKey /etc/ssh/ssh_host_rsa_key

17 HostKey /etc/ssh/ssh_host_dsa_key


18 UsePrivilegeSeparation yes

19 #### Authentification par clés publiques ####

20 PubkeyAuthentication yes

21 AuthorizedKeysFile %h/.ssh/authorized_keys

22 PermitBlacklistedKeys no # Rejette les connexions avec une clé compromise

23 AllowUsers ids # Autorise un nombre limité d'utilisateur à se connecter

24 LoginGraceTime 60 # Laisse 1 minute à l'utilisateur pour se connecter en entrant sa passphrase (sinon timeout)

25 StrictModes yes # Vérifie les permissions et les droits sur les clés privées

26 PermitRootLogin no # Empêcher une connexion avec le compte root

27 IgnoreRhosts yes # Ignore les fichiers ~/.rhosts et ~/.shosts car rhost est obsolète

28 HostbasedAuthentication no # Désactive l'authentification basée sur l'hôte (rhosts)

29 IgnoreUserKnownHosts yes # Ignore le fichier ~/.ssh/known_hosts pour les connexions RSA

30 PermitEmptyPasswords no # Interdit les connexions sans mot de passe

31 UsePAM no # Désactive PAM

32 ChallengeResponseAuthentication no # Désactive la réponse PAM

33 PasswordAuthentication no # Désactive l'authentification par mot de passe (utilisation de passphrase)

34 UseLogin no # Désactive la fonction login()

35 #### Logging ####

36 SyslogFacility AUTH # /var/log/auth.log

37 LogLevel INFO # Verbosité à INFO

38 PrintLastLog yes # Affiche la dernière connexion de l'utilisateur

39 MaxAuthTries 2 # Maximum de tentative avant échec de l'authentification

40 MaxStartups 10:30:60 # Bloque les connexions entrantes au-delà de 10 connexion actives

41 AcceptEnv LANG LC_* # Autorise le passage de variables locales au client

42 Subsystem sftp /usr/lib/openssh/sftp-server # Active le service sftp sur SSH

43 Banner /etc/issue # Affiche une bannière d'avertissement

44 EOT


Nous avons à présent recrée un fichier de configuration pour le service SSH de manière à

garantir de manière optimale, la sécurité de l’administration du serveur à distance. A

présent il faut préparer les jeux de clés RSA et DSA nécessaires à l’authentification mais

aussi le message d’avertissement lors de la connexion :

45 # cat > /etc/issue << EOT

46 -------------------------------------------------------------------------

47 AVERTISSEMENT: L'accès à ce système est restreint aux seuls utilisateurs autorisées à s'y connecter.

48 -------------------------------------------------------------------------

49 EOT

50 # rm /etc/ssh/ssh_host_*

51 # ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa # Recréation du jeu de clé RSA

52 # ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa # Recréation du jeu de clé DSA

53 # su ids

54 $ mkdir ~/.ssh && cd ~/.ssh

55 $ ssh-keygen -t rsa -b 2048 # Création d'un jeu de clé avec un passkey

56 $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

57 $ chmod 600 ~/.ssh/id_rsa

58 $ chmod 600 ~/.ssh/authorized_keys

59 $ chmod 700 ~/.ssh

60 $ exit

61 # /etc/init.d/ssh start # Démarre le service SSH

CONFIGURATION DU PARE-FEU

Afin d’apporter une protection supplémentaire, suite à une réunion avec mon tuteur de

formation, nous avons décidés de configurer le pare-feu pour répondre à ces besoins :

Autoriser l’interrogation du service SSH uniquement par les machines du réseau

CRI.LAB ;

Autoriser l’interrogation du service HTTP par les machines du réseau CRI.LAB

uniquement ;

Bloquer toute les autres connexions sortantes ;

Autoriser toute les connexions sortantes (elles seront de toute manière filtrées

avec Suricata).


Nous avons donc créé un fichier de script permettant de s’adapter aux modifications IP

du système de manière pseudo-automatique :

1 # cat > /etc/init.d/firewall.sh << EOT # Création d'un fichier contenant nos règles de pare-feu (meilleur persistance)

2 #!/bin/sh

3 if ![ -x /sbin/iptables]; then # Quitte si iptables n'existe pas

4 exit 0

5 fi

6 #### Déclaration des variables ####

7 IP_eth0="$(ifconfig eth0 | grep 'inet adr:'| cut -d: -f2 | awk '{print$1}' | grep -Eo '([0-9]{1,3}[\.]){3}[0-9]{1,3}')" #Récupération dynamique de l'adresse IP

8 CRI_lab="192.168.251.0/24"

9

10 #### Configuration ####

11 iptables-save > /etc/iptables.backup # Sauvegarde la configuration actuelle

12 iptables -F # Vide (flush) la table de configuration du pare-feu actuellement utilisée

13

14 iptables -t nat -F # Vide les règles nat, relatives au rôle de passerelle (non installé ...)

15 iptables -t mangle -F # Vide les règles mangle, relatives à la QoS

16 iptables -P INPUT DROP # Rejet par défaut de toute les requêtes entrantes sur les cartes réseau

17 iptables -A INPUT -i lo -j ACCEPT # Accepte les paquets entrant depuis la carte de bouclage (loopback)

18 iptables -P FORWARD DROP # Rejet par défaut de toute les requêtes passant d'une carte réseau à une autre

19 iptables -P OUTPUT ACCEPT # Autorise par défaut toute les requêtes sortantes d'une des cartes réseau

20 iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT # Autorisation de paquets faisant partie d'une session ou flux déjà établie (donc autorisé)

21 iptables -A INPUT -p icmp -j ACCEPT # Autorise les requêtes ICMP entrantes

22

23 #### SSH ####

24 iptables -A INPUT -p tcp -s $CRI_lab -d $IP_eth0 --dport 54365 -m state --state NEW,ESTABLISHED -j ACCEPT # Ajoute une règle autorisant l'interrogation du service SSH depuis le réseau CRI_lab uniquement

25


26 #### HTTP ####

27 iptables -A INPUT -p tcp -s $CRI_lab -d $IP_eth0 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT # Ajoute une règle pour autoriser les interrogations HTTP à partir du réseau CRI_lab uniquement

28 iptables -A INPUT -p tcp -s $CRI_lab -d $IP_eth0 --dport 3000 -m state --state NEW,ESTABLISHED -j ACCEPT # Ajoute une règle pour autoriser l'affichage de la console de monitoring "Snorby"

29

30 #### MYSQL Server ####

31 iptables -A INPUT -p tcp -s $CRI_lab -d $IP_eth0 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT # Ajoute une règle pour autoriser l'interogation de la base de données à partir du réseau CRI_dep uniquement

32

33 #### Sauvegarde de la configuration ####

34 iptables-save > /etc/network/iptables.up.rules

35 printf "y\n" | iptables-apply –w /etc/network/iptables.up.rules >/dev/null

36 #### Désaffectation des variables ####

37 unset IP_eth0

38 unset CRI_lab

39 exit 0

40 EOT

41 # chmod +x /etc/init.d/firewall.sh

42 # ln -s /etc/init.d/firewall.sh /etc/network/if-up.d/iptables

INSTALLATION DE APACHE

Afin de pouvoir tester notre solution de protection et détection d’intrusion, nous allons

installer une application WEB dédié à l’apprentissage des vulnérabilités du WEB, ce qui

implique qu’il sera possible d’exploiter diverses failles sur cette application et donc tester

la solution.

Pour installer une application WEB, il faut bien évidemment un service de gestion de

contenu WEB à savoir un service HTTP, cependant la plupart des vulnérabilités ne sont

pas exploitables sans moteur de dynamicité de contenue, aussi nous allons également

ajouter PHP à notre système :

1 # apt-get -fy install apache2 php5 php5-common php5-mysql libapache2-mod-php5

2 # /etc/init.d/apache2 stop

3 # cp /etc/apache2/sites-enabled/000-default.conf /etc/apache2/sites-enabled/000-default.conf.bak


4 # cat > /etc/apache2/sites-enabled/000-default.conf << EOT

5 ServerName localhost

6 <VirtualHost *:80>

7 DocumentRoot /var/www/html

8 ErrorLog ${APACHE_LOG_DIR}/error.log

9 CustomLog ${APACHE_LOG_DIR}/access.log combined

10 </VirtualHost>

11 EOT

12 # apt-get -fy install git

13 # rm -rf /var/www/*

14 # mkdir –p /var/www/html

15 # cd /var/www/html

16 # /etc/init.d/apache2 start

INSTALLATION DE MYSQL-SERVER

Afin de permettre aussi bien à notre IPS/IDS de « ranger »/stocker ses informations, nous

allons installer un SGBD, pour la simplicité d’utilisation de Mysql, nous avons opté pour

cette solution, il reste cependant possible d’utiliser le SGBD PostGreSQL qui offre les

mêmes fonctionnalités :

1 # apt-get -fy install mysql-server mysql-client

2 # /etc/init.d/mysql stop

3 # mv /etc/mysql/conf.d/mysqld_safe_syslog.cnf /etc/mysql/mysqld_safe_syslog.cnf.bak

4 # cat >> /etc/mysql/my.cnf << EOT

5 [mysqld_safe]

6 log_error=/var/log/mysql/mysql-error.log

7 [mysqld]

8 log_error=/var/log/mysql/mysql_error.log

9 general_log_file=/var/log/mysql/mysql.log

10 general_log=1

11 log_slow_queries=/var/log/mysql-slow.log

12 long_query_time=2

13 log-queries-not-using-indexes

14 EOT

15 # touch /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mysql-error.log


16 # chown mysql /var/log/mysql -Rf

17 # /etc/init.d/mysql start

A présent que le service mysql est configuré, nous allons créer un utilisateur qui

possèdera tous les droits mais uniquement sur sa base de donnée (créée plus tard) :

18 # mysql -u root -p

19 CREATE USER 'dvwa'@'%' IDENTIFIED BY 'c2VjcmV0';

20 GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'%';

21 FLUSH PRIVILEGES;

22 EXIT;

INSTALLATION DE DVWA

À présent que nous possédons une infrastructure logicielle de type AMP (Apache MySQL

PHP), nous pouvons télécharger et installer DVWA.

1 # cd /var/www/html/

2 # git clone https://github.com/RandomStorm/DVWA

3 # chown -R www-data:www-data /var/www/

4 # cd /var/www/html/DVWA/

5 # nano config/config.inc.php # Editer le fichier de configuration

6 # Please use a database dedicated to DVWA.

7 $_DVWA = array();

8 $_DVWA[ 'db_server' ] = 'localhost';

9 $_DVWA[ 'db_database' ] = 'dvwa';

10 $_DVWA[ 'db_user' ] = 'dvwa';

11 $_DVWA[ 'db_password' ] = 'c2VjcmV0';

Une fois configuré, ouvrir un navigateur WEB et ouvrir la page de configuration de

DVWA, ici http://192.168.251.104/DVWA/setup.php, ensuite cliquer sur le bouton « Create

/ Reset Database » pour que le DVWA puisse écrire sa base de données puis y ajouter

ses informations tel que les identifiants (par défaut admin / password).

https://github.com/RandomStorm/DVWA

http://192.168.251.104/DVWA/setup.php


INSTALLATION DE SURICATA EN MODE IPS

A présent nous allons passer au vif du sujet en installant Suricata en mode IPS, en effet de

base Suricata est un IDS mais il est capable également de fonctionner en mode IPS.

Installation des dépendances

Avant de compiler Suricata sur le système, il est nécessaire de procéder à l'installation

des dépendances afin de satisfaire aux besoins du compilateur ainsi que des sources à

compiler :

12 # apt-get update # Mise à jour de la base de données des dépots apt

13 # apt-get -fy install libpcre3 libpcre3-dbg libpcre3-dev build-essential autoconf automake libtool libpcap-dev libnet1-dev libyaml-0-2 libyaml-dev libnetfilter-queue-dev htp subversion flex bison zlib1g zlib1g-dev libmagic-dev libcap-ng-dev libjansson-dev pkg-config magic coccinelle linux-headers-$(uname -r)

Téléchargement et compilation de Suricata

A présent nous allons passer à la compilation des sources de Suricata :

1 # cd /opt

2 # wget http://www.openinfosecfoundation.org/download/suricata-2.0.8.tar.gz

3 # tar xvzf suricata-2.0.8.tar.gz

4 # cd suricata-2.0.8

5 # ./configure --enable-nfqueue --prefix=/usr --sysconfdir=/etc --localstatedir=/var

6 # make

7 # make install

8 # ldconfig # Met à jour les bibliothèques

http://www.openinfosecfoundation.org/download/suricata-2.0.8.tar.gz

http://www.openinfosecfoundation.org/download/suricata-2.0.8.tar.gz


Préparation de l'environnement

Nous allons maintenant ajouter un compte dédié à Suricata, celui-ci permettra en cas

dans Suricata de freiner le gain de privilège.

1 # groupadd suricata # Création d'un groupe d'utilisateur « suricata »

2 # useradd -g suricata suricata -s /bin/false # Créer et ajoute un utilisateur au groupe suricata en lui attribuant un shell vide

3 # mkdir /var/log/suricata # Création d'un répertoire pour les journaux de Suricata

4 # chown suricata:suricata /var/log/suricata # Spécifie l'appartenance du répertoire de log à « suricata »

5 # mkdir -p /etc/suricata/rules # Création d'un répertoire pour le stockage des fichiers de configuration de suricata

Ajout de bases pour la configuration

6 # cp /opt/suricata-2.0.8/suricata.yaml /etc/suricata/

7 # cp /opt/suricata-2.0.8/classification.config /etc/suricata/

8 # cp /opt/suricata-2.0.8/reference.config /etc/suricata/

9 # touch /etc/suricata/threshold.config

CONFIGURATION DE SURICATA

Pour commencer à configurer Suricata, nous allons modifier le fichier de configuration

« /etc/suricata/suricata.yaml ». En premier, nous allons désactiver les règles permettant

l’envoie d’alertes au SIEM (« Security Information & Event Management System ») nommé

« Prelude », pour cela commenter les lignes comme ceci :

1 # nano /etc/suricata/suricata.yaml

2 # alert output to prelude (http://www.prelude-technologies.com/) only

3 # available if Suricata has been compiled with --enable-prelude

4 # - alert-prelude:

5 # enabled: no

6 # profile: suricata

7 # log-packet-content: no

8 # log-packet-header: yes


Modification des variables

Il faut maintenant apporter quelques modifications relatives aux variables utilisées par

Suricata pour lui permettre de fonctionner sur notre système comme il se doit :

1 # nano /etc/suricata/suricata.yaml

2 # Holds the address group vars that would be passed in a Signature.

3 # These would be retrieved during the Signature address parsing stage.

4 address-groups:

5 HOME_NET: "192.168.251.0/24"

Comme nous avons changé de port d’écoute pour le service SSH, il faut le modifier

également dans ce fichier :

6 SSH_PORTS: 54365

Nous allons également modifier la configuration pour permettre à Suricata de journaliser

les résultats dans un fichier de log :

7 # Define your logging outputs. If none are defined, or they are all

8 # disabled you will get the default - console output.

9 outputs:

10 - console:

11 enabled: yes

12 - file:

13 enabled: yes

14 filename: /var/log/suricata.log

Ajout de règles

Afin de commencer sur une base saine et pouvoir comprendre le fonctionnement de

Suricata ainsi que la syntaxe utilisée pour créer des règles, nous allons en télécharger un

pack et partir sur cette base pour pouvoir modifier si besoin est, la configuration des jeux

de règles :

1 # cd /usr/src

2 # wget http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz

3 # tar xvfz emerging.rules.tar.gz

4 # mv /usr/src/rules/*.rules /etc/suricata/rules/

5 # chown -R suricata:suricata /etc/suricata/

http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz


INSTALLATION DE SNORBY

Installation des dépendances

1 # apt-get update

2 # apt-get -fy install libpng12-dev libtiff5-dev libjasper-dev libfontconfig1-dev libopenexr-dev libwmf-dev librsvg2-dev liblzma-dev liblcms2-dev libdjvulibre-dev libssl-dev libreadline6-dev zlib1g zlib1g-dev libxml++2.6-dev libxslt1-dev libxslt-dev libxml2-dev imagemagick xorg libmysql++-dev libmagickwand-dev mysql-client libmysqlclient-dev default-jre build-essential ghostscript graphviz-dev libfftw3-dev libgv-ruby libjpeg-dev ruby ruby-dev ttf-dejavu unzip wkhtmltopdf libtool automake gcc g++ flex bison libnet1 libnet1-dev libpcre3 libpcre3-dev autoconf libcrypt-ssleay-perl libwww-perl git-core libyaml-dev openssl libcurl4-openssl-dev curl ruby1.9.3 ruby-text-format libsqlite3-dev

3 # cd /tmp

4 # wget https://libdnet.googlecode.com/files/libdnet-1.12.tgz

5 # tar zxf libdnet-1.12.tgz

6 # cd libdnet-1.12

7 # ./configure

8 # make && make install

9 # cd ..

10 # wget http://www.tcpdump.org/release/libpcap-1.6.2.tar.gz

11 # tar zxf libpcap-1.6.2.tar.gz

12 # cd libpcap-1.6.2

13 # ./configure


15 # ldconfig

16 # cd ..

Étant donné que Snorby utilise Ruby en version 1.9 nous allons installer la version 1.9.3 en

utilisant le SVN de Ruby :

17 # curl -#LO https://rvm.io/mpapis.asc

18 # gpg --import mpapis.asc

19 # curl -sSL https://get.rvm.io | bash -s stable --quiet-curl --ruby=1.9.3

20 # source /usr/local/rvm/scripts/rvm

21 # rvm requirements

22 # export PATH=$PATH:/usr/local/rvm/gems/ruby-1.9.3-p551/bin

23 # rvm use ruby-1.9.3-p551

https://libdnet.googlecode.com/files/libdnet-1.12.tgz

http://www.tcpdump.org/release/libpcap-1.6.2.tar.gz

https://rvm.io/mpapis.asc

https://get.rvm.io/


24 # wget https://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.11.0_rc1-static-amd64.tar.bz2

25 # tar xvjf wkhtmltopdf-0.11.0_rc1-static-amd64.tar.bz2

26 # cp wkhtmltopdf-amd64 /usr/bin/wkhtmltopdf

27 # wget https://aws-eu-cache01.rubygems.org/gems/text-hyphen-1.2.gem

28 # gem install --force --local text-hyphen-1.2.gem

29 # export LD_LIBRARY="/usr/lib/x86_64-linux-gnu"

30 # wget https://aws-eu-cache01.rubygems.org/gems/text-format-1.0.0.gem

31 # gem install --force text-format-1.0.0.gem

32 # mkdir -p /usr/src/PGM/BUILD/libxml/

33 # cd /usr/src/PGM/BUILD/libxml/

34 # wget ftp://xmlsoft.org/libxml2/libxml2-2.8.0.tar.gz

35 # tar xvzf libxml2-2.8.0.tar.gz

36 # cd /usr/include

37 # gem install nokogiri -v '1.5.9' -- --with-xml2-include=/usr/src/PGM/BUILD/libxml/libxml2-2.8.0/include ./INS_NOKO

38 # gem install thor i18n bundler tzinfo builder memcache-client rack rack-test erubis mail rack-mount sqlite3 rails activesupport

39 # gem install rake --version=0.9.2

40 # gem install do_mysql -v '0.10.12'

41 # gem install arel ezprint

42 # gem install dm-rails -v 1.2.1

43 # gem install bundler -v 1.2.1

Installation de Snorby

1 # cd /var/www/

2 # git clone https://github.com/Snorby/snorby.git

Passons à la configuration de Snorby pour qu’il puisse écrire dans la base de données

locale :

3 # cd /var/www/snorby/config

4 # cp database.yml.example database.yml

5 # cp snorby_config.yml.example snorby_config.yml

6 # sed -i ’s/"\/usr\/local\/bin\/wkhtmltopdf"/"\/usr\/bin\/wkhtmltopdf"/g’ snorby_config.yml

7 # mysql -u root -p

https://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.11.0_rc1-static-amd64.tar.bz2

https://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.11.0_rc1-static-amd64.tar.bz2

https://aws-eu-cache01.rubygems.org/gems/text-hyphen-1.2.gem

https://aws-eu-cache01.rubygems.org/gems/text-format-1.0.0.gem

ftp://xmlsoft.org/libxml2/libxml2-2.8.0.tar.gz


8 CREATE DATABASE snorby DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

9 CREATE USER 'snorby'@'localhost' IDENTIFIED BY 'sMKn@6jE';

10 GRANT ALL PRIVILEGES ON snorby.* TO 'snorby'@'localhost' WITH GRANT OPTION;

11 FLUSH PRIVILEGES;

12 EXIT;

13 # nano database.yml # Modification de la configuration

14 snorby: &snorby

15 adapter: mysql

16 username: snorby

17 password: "sMKn@6jE"

18 host: localhost

Nous pouvons à présent procéder à l’installation :

19 # cd /var/www/snorby/

20 # bundle update

21 # bundle install --deployment

22 # bundle exec rake snorby:setup


INSTALLATION DE BARNYARD2

Pour permettre à Suricata d’écrire ses résultats dans une base de données, il est

nécessaire d’installer un paquet qui permet de récupérer le contenu du fichier de log et

le synchroniser avec la base de données pour permettre un traitement plus simple, celui-

ci s’appelle Barnyard.

Installation des dependences

1 # apt-get -fy install apache2-dev apache2.2-common libapr1-dev libaprutil1-dev libcurl4-openssl-dev

2 # /etc/init.d/apache2 stop

3 # gem install --no-ri --no-rdoc passenger

4 # /usr/local/rvm/gems/ruby-1.9.3-p551/bin/passenger-install-apache2-module -a

5 # touch /etc/apache2/mods-available/passenger.load

6 # find / -name "*mod_passenger*"

7 # cat > /etc/apache2/mods-available/passenger.load << EOT

8 LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p551/gems/passenger-5.0.8/buildout/apache2/mod_passenger.so

9 <IfModule mod_passenger.c>

10 PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p551/gems/passenger-5.0.8

11 PassengerRuby /usr/local/rvm/rubies/ruby-1.9.3-p551/bin/ruby

12 </IfModule>

13 EOT

14 # a2enmod passenger

15 # a2enmod rewrite

16 # a2enmod ssl

17 # /etc/init.d/apache2 start

18 # find / -name libmysql*

19 # cd /tmp

20 # wget https://www.snort.org/downloads/snort/daq-2.0.5.tar.gz

21 # tar xzvf daq-2.0.5.tar.gz

22 # cd daq-2.0.5

23 # ./configure


https://www.snort.org/downloads/snort/daq-2.0.5.tar.gz


Installation de Barnyard

1 # git clone https://github.com/firnsy/barnyard2.git

2 # cd barnyard2

3 # ./autogen.sh

4 # ./configure --with-mysql-libraries=/usr/lib/i386-linux-gnu/


6 # cp /tmp/barnyard2/etc/barnyard2.conf /etc/suricata/

7 # nano /etc/suricata/barnyard2.conf # Modification du fichier de configuration

8 config reference_file: /etc/suricata/reference.config

9 config classification_file: /etc/suricata/classification.config

10 config gen_file: /etc/suricata/rules/gen-msg.map

11 config sid_file: /etc/suricata/rules/sid-msg.map

12

13 config waldo_file: /var/log/suricata/suricata.waldo

14

15 output database: log, mysql, user=snorby password="sMKn@6jE" dbname=snorby host=localhost

16 config interface: eth0

17 # mkdir /var/log/barnyard2

18 # touch /var/log/suricata/suricata.waldo

Pour lancer les services il suffit d’exécuter ces commandes :

1 # bundle exec rails server -e production -d

2 # suricata -c /etc/suricata/suricata.yaml -i eth1 -D

3 # barnyard2 -c /etc/suricata/barnyard2.conf -d /var/log/suricata -f unified2.alert -w /var/log/suricata/suricata.waldo –D

GESTION DES REGLES AVEC OINKMASTER

II lest possible de télécharger et installer des règles de filtrage pour Suricata

manuellement, mais il existe un service permettant de rendre plus facile et moins

laborieux cette tâche. Par exemple il existe « Pulled Pork » et « OinkMaster ». Étant donné

qu’OinkMaster est le plus utilisé par la communauté, il semble judicieux d’utiliser ce

dernier.

Installation de OinkMaster

Pour installer OinkMaster il n’y a pas besoin de procéder à l’installation de dépendances

supplémentaires dans la mesure où notre IDS utilise déjà certaine de ses dépendances :

https://github.com/firnsy/barnyard2.git


1 # apt-get install oinkmaster

Configuration de OinkMaster

Étant donné que nous utilisons déjà un jeu de règle pour notre configuration actuelle,

nous allons le réutiliser pour OinkMaster, à savoir

http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz. Pour cela il suffit

d’éditer cette ligne :

2 # nano /etc/oinkmaster.conf

3 url=http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz

4 # cd /etc

5 # oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules

6 # crontab -e -u oinkmaster # Ajout d’une tâche quotidienne à 0h

7 00 00 * * * oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules 2>&1 >> /dev/null 2>&1





INFORMATIONS SUPPLEMENTAIRES

Contact : [email protected]

Références :

Ask Ubuntu - http://askubuntu.com/

Super User - http://superuser.com/

Stack Overflow - http://stackoverflow.com/

Server Fault - http://serverfault.com/

Information Security - http://security.stackexchange.com/

Stack Exchange Unix and Linux - http://unix.stackexchange.com/

Ubuntu Wiki -https://wiki.ubuntu.com/

Ubuntu Documentation - https://help.ubuntu.com/

ArchWiki - https://wiki.archlinux.org/

Syslinux Wiki - http://www.syslinux.org

DigitalOcean Community - https://www.digitalocean.com/community/

IT-Connect - http://www.it-connect.fr/

mailto:[email protected]

http://askubuntu.com/

http://superuser.com/

http://stackoverflow.com/

http://serverfault.com/

http://security.stackexchange.com/

http://unix.stackexchange.com/

https://wiki.ubuntu.com/

https://help.ubuntu.com/

https://wiki.archlinux.org/

http://www.syslinux.org/

https://www.digitalocean.com/community/

http://www.it-connect.fr/

mise en place d’un système de détection d’intrusion réseau · 2017-04-11 · baptiste moine...

Documents