Tcpdump s'utilise la plupart du temps de la façon suivante: en ecoutant
sur une interface donnée le traffic réseau.
exemple:
tcpdump -i vlan2
12:59:36.390516 10.251.3.145.32768 > nova.epita.fr.domain: 25648+ PTR? 196.141.251.10.in-addr.arpa. (45) (DF)
12:59:37.436922 802.1Q vlan#2 P0 ids.rush.epita.fr.ssh > 192.168.10.10.51972: P 1:49(48) ack 48 win 8576 (DF) [tos 0x10]
Les lignes de sortie sont dépendantes du protocole concerné.
Explication d'une ligne de sortie pour le protocole TCP:
12:59:36.390109 gzip.epita.fr.ssh > tourni-r.lab-cisco.epita.fr.57191: P 7503248:7503344(96) ack 2238588120 win 17520 [tos 0x10]
12:59:36.390109 Heure
gzip.epita.fr.ssh Source
tourni-r.lab-cisco.epita.fr.57191 Destination
P Flags
7503248:7503344(96) Data Sequence Number
ack 2238588120 Ack
win 17520 Window
Urgent
[tos 0x10] Options
Snort
Snort est un outil de détection d'intrusions réseaux, assorti de
nombreuses extensions/utilitaires - notamment acidlab.
Snort peut fonctionner en différents modes:
le mode sniffeur
le mode enregistreur: les paquets sont enregistrés dans un fichier
compatible tcpdump.
le mode détection et alerte: une alerte est générée sur la
console, sur une socket, etc...
Il est très intéressant d'injecter les enregistrements de Snort dans
une base de donnée - mysql, postgresql et oracle sont supportées - car
il existe des outils de présentation qui synthétisent l'analyse de
données, et permettent de faire valoir l'utilisation de l'IDS auprès
de personnes non-techniques.
Nous avons donc choisis d'utiliser Snort en mode NIDS et de journaliser
les alertes dans une base MySQL.
# Quelques variables d'installation:
var HOME_NET [192.168.10.0]
var RULE_PATH /usr/local/etc/snort
var VERIFICATION_SCRIPT_DIR /usr/local/etc/snort/cve
# Desactivation de la normalisation des requêtes HTTP
#http_decode:
# Inclusion du fichier selectionnant les filtres à inclure
include /usr/local/snort/snort.rules.include
# Configuration MySQL
output database: log, mysql, user=snortusr password=snortpwd dbname=snort host=localhost
# Activation de la detection des attaques ARP
# il faut spécifier les adresses MAC des machines derrière le routeur.
preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.10.2 00:0c:6e:54:d7:99
/usr/local/etc/snort/snort.rules.include
(et les raisons de certaines desactivations):
include exploit.rules
include scan.rules
include finger.rules
include ftp.rules
include telnet.rules
include smtp.rules
include rpc.rules
include rservices.rules
include backdoor.rules
include dos.rules
include ddos.rules
include dns.rules
include netbios.rules
include web-cgi.rules
include web-coldfusion.rules
include web-frontpage.rules
include web-iis.rules
include web-misc.rules
include sql.rules
include x11.rules
include icmp.rules
# include shellcode.rules -> Tres gourmand en performances
include misc.rules
# include policy.rules -> Necessite une politique de sécurité
# bien précise.
# include info.rules -> Détecte les erreurs utilisateur
# (ftp bad login,...) pas les attaques.
# include icmp-info.rules -> Détecte les ICMP "normaux"
# include virus.rules -> On ne protège par de machines Windows
include local.rules
Utilisation
Snort est lancé comme un daemon au démarrage de la machine.
En entrée, il écoute le réseau placé derrière le routeur, en
sortie, il place ses résultats bruts sans corrélation en 2 endroits:
un fichier de log (/var/log/snort/alert).
la base mysql dans la base 'snort'.
Intérêt du patch IDS Alert Verification:
On peut aussi ajouter a Snort Ids Alert Verification. Cette rustine
repose sur les vulnerabilités connues par Nessus. Quand Snort détecte
une alerte, IAV prend la main, et vérifie que la cible est vulnérable
à l'attaque détectée grâce à un script NASL - pour Nessus Attack
Script Language. Si c'est le cas, l'attaque est marquée comme
vérifiée, sinon elle est marquée comme non verifiée et signalée comme
un faux-positif et l'alerte n'est pas générée. Enfin si aucun script
NASL ne correspond à cette attaque, elle est marquée comme non vérifiable.
Les résultats seront mis en forme après analyse des logs, notamment par
AcidLab (cf B.2).
Mysql
La base MySQL est installée pour recueillir les alertes de snort.
L'accès aux données est plus rapide qu'avec un fichier simple en cas
d'analyse heuristique ayant besoin d'un historique (corrélation).
D'autre part, la base peut être localisée ailleurs que sur l'IDS:
l'avantage vient du fait que si la machine est compromise, les logs peuvent
être effacés..
Remarque: pour le rush, même remarque que pour Apache (cf B.3), le serveur
devrait normalement être installé sur une machine a l'abri.
Concrêtement, les logs de snort ne peuvent servir que sur les
problèmes précis, or il peut être intéressant pour une entreprise de
voir par exemple sur quelles périodes se concentrent les attaques,
sur quelles plages d'adresses elles se regroupent, de quel type sont
elles majoritairement. Acidlab est une interface web en php qui permet
de synthétiser les enregistrements de Snort à travers des schémas et
des tableaux, ce qui les rends exploitables, et valorisable auprès des
non-techniciens.
On accède au site web par l'adresse: http://localhost/acidlab
les logs sont analysés et correlés, regroupés par sources, etc...
L'interface permet, en plus d'une vision plus claire et concise des
attaques (notamment en regroupant les sources, ...) de gérer les logs
d'attaque (effacement de certaines attaques, chaque ecran thématique permet
des recherches dans les logs sur plusieurs critères prédéfinis.
Page de présentation globale.
Résumé des alertes de façon chronologique.
Apache
Apache est un serveur Web Relativement bien sécurisé, actif et largement
intégré et reconnu par les entreprises.
Remarque de sécurité:
Son installation sur le serveur IDS est clairement mauvaise, mais
l'architecture réseau imposée par le Rush me permettait pas de l'installer
sur une machine distante protégée (dans un DMZ ou autre...)
Nous avons donc désactiver tous les plugins non-necessaires, rendu le port
80 uniquement accessible depuis localhost.
/etc/apache/httpd.conf:
# Activer le module php
LoadModule php4_module /usr/lib/apache/1.3/libphp4.so
#...
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
# Desactiver le module cgi
# LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
ServerName ids.rush.epita.fr
#...
AllowOverride All
Honeyd
Honeyd est un logiciel permettant de créer des machines virtuelles sur un
réseau. Il est aussi capable de simuler le comportement de routeurs, créant
ainsi des réseaux virtuels.
Dans notre configuration, une machine se trouvant sur le vlan héberge notre
pot de miel. Lorsque quelqu'un essaye de contacter une machine sur le vlan,
il va avant tout envoyer une requête arp pour obtenir son adresse physique.
Si personne ne répond dans le laps de temps imparti, un logiciel, appelé arpd,
s'occupe de répondre. Ainsi, si quelqu'un essaye de contacter une machine
n'existant pas sur le réseau, le traffic sera redirigé vers notre machine
hébergeant notre pot de miel.
Ainsi, sur le vlan de chaque cible, est présent :
le routeur permettant de sortir du réseau et contenant notre IDS
la cible avec tous les services
la machine avec l'arpd et le honeypot.
Le pot de miel simule donc le comportement de 251 machines sur le
vlan (classe C moins les 3 machines physiquement présentes).
Installation
Application: honeyd 0.8
arpd 0.2
honeyd et arp doivent être compilé à partir des sources disponibles sur le
site de honeyd. Ils ont aussi besoin de trois bibliothèques, à savoir la
libdnet, la libevent, et la libpcap.
Le site http://www.honeyd.org explique parfaitement comment installer
honeyd (Installation standard des autotools)
Utilisation
Pour arpd, il suffit de lui indiquer la plage d'ip sur laquelle il a
autorité. On le lance ainsi avec la commande :
-s : indique le fichier de log utilisé par les scripts émulant les
services
-p : indique le fichier contenant les signatures des systèmes
-u, -g : indique respectivement l'uid et le gid de l'utilisateur
lançant honeyd
-f : indique le fichier de configuration de honeyd
-i : indique l'interface où écouter
192.168.10.0/24 : la plage d'adresse ip à émuler
Ettercap
Ettercap est un kit complet pour hacker réseaux, mais aussi pour la détection
d'attaques et d'intrusions avec une interface en termcap sous unix.
Il offre deux types de mode pour le hacking sur différents protocoles:
le mode sniffeur ou intercepteur de paquets pour l'analyse du réseau
et celui de générateur ou modificateur de paquets.
Malgré que Ettercap soit destiné principalement aux hackers, il présente
plusieurs caratéristiques d'IDS parmi lesquelles:
tuer une connection illicite par un hacker
identifier le type de système d'exploitation d'un hacker
observer une connection non autorisée entre deux machines
vérifier si le réseau local est empoisonné («flooding»,...)
Ettercap permet essentiellement de lancer des attaques, mais d'un point de
vue détection d'attaques et d'intrusions, il est toujours utile de
connaître cet outil.
Pour la détection d'attaques et d'intrusions, l'utilisation d'Ettercap se
résume au mode sniffeur avec la commande suivante pour le lancement d'une
écoute de tous les paquets:
#> ettercap
L'interface utilisateur se présente sous la forme suivante:
Après qu'une méthode (IP, MAC ou ARP) d'écoute soit sélectionnée, Ettercap affiche toutes les connections entre deux machines.
La connection est :
soit active (présence de trafic de paquets)
soit silencieuse (pas de trafic)
Un autre exemple de fenêtre d'aide.
Après son lancement, Ettercap ping sur l'addresse de diffusion du réseau et
récupère tous les IP des machines. On peut par la suite écouter la connection
entre 2 machines par rapport à leurs addresses IP, MAC ou ARP
Pour détecter si la machine sur laquelle est installée Ettercap est victime
d'attaques à partir d'une machine locale, la commande suivante fournit cette
détection:
#> ettercap -Nclg
Cette commande liste toutes les machines du réseau local et indique celle(s)
qui lance(nt) ces attaques.
DSniff
dsniff est un sniffeur de mots de passe qui gère de nombreux protocoles
courants tels que FTP, POP SMB, etc...
Son interêt d'un point de vue stratégique est de voir si des mots de passe
transitent par des endroits dangereux, ou par des protocoles non sécurisés.
Il faudra, face à cette situation, soit sensibiliser l'utilisateur fautif aux
problèmes de sécurité, soit prendre des mesures de rétorsion, voir changer la
politique du réseau.
Son utilisation sur un réseau commuté nécessite de spoofer les tables arp de
la victime, et de transmettre les paquets à leur véritable destinataire,
cette utilisation peut être détectée par arpwatch.
DSniff marche un peu comme tcpdump, on lui specifie une interface sur
laquelle peuvent transitent les mots de passe.
Il renvoie ceux qu'il a pu détecter.
ex: dsniff -i vlan2
OSSIM
Ossim est né d'une constatation simple: malgré l'existence d'outil de
détection de grande qualité, il reste très - trop - difficile à un
administrateur de récupérer une image du réseau à un instant donné, et
de faire de la corrélation de données du fait du volume des données à
traiter, et surtout de la fiabilité de ces données - cf les
faux-positifs. Le but d'Ossim est donc clair, permettre cette
corrélation et une analyse facile de l'état du réseau à tout
instant. Ossim est constitué d'un panneau de contrôle, de moniteurs
de risque et d'activité, et de moniteurs de réseaux pour une
observation de bas niveau. Cette variété des niveaux d'analyse permet
aussi bien la mise en place de stratégies de détection que le
traitement des signatures des attaques par un technicien. Ossim est
une solution d'intégration reposant sur des outils bien connus - dont
certains que nous avons déja mis en place.
L'analyse du réseau se fait au moyen :
de patrons définis par des signatures ou des règles comme snort.
de détecteurs d'anomalies lorsque le comportement diffère de ce
que le détecteur considère comme normal. par exemple une nouvelle
attaque n'ayant donc pas de signature pourrait tout de meme générer
des comportements anormaux tels qu'un nombre important de
connexions.
de la centralisation des alertes dans une base de données pour
éviter notamment les problèmes d'hétérogénéité des formats.
de la prioritisation des alertes: ainsi, un Apache sur une
Debian recevant une attaque contre un MS-IIS n'est pas en danger.
de la corrélation: par exemple, si l'IDS détecte un flood, Ossim
regarde si le moniteur d'activité à enregistré une baisse de la
disponibilité. Si oui, l'attaque est confirmée.
Ossim repose sur les logiciels suivants:
Apache, PHP et ADOdb
Mysql
Snort
AcidLab
Ntop (analyseur réseau)
Mrtg (génération de pages HTML et de graphiques pour le réseau)
rrdtool (réimplementation de MRTG)
Nmap, P0f et arpwatch (scanneurs, reconnaissance des empreintes
des OS)
Malheureusement, nous n'avons pas eu le temps d'implémenter, cette solution.
