Macabre mais j’adore 🙂
Ne reste plus qu’à savoir si ma famille appréciera…
Dans le même genre, y’a pire geek que soit même 😀
Fév
18
-
-
Articles récents
Catégories
Boutique partenaire
Fév
06
Installer SNORT (partie 1)
Principalement, nous distinguons deux catégories de systèmes de détection
d’intrusion :
Le premier type est formé par les détecteurs d’intrusion basés sur l’hôte (HIDS), ceux-ci analysent et contrôlent uniquement l’activité et les informations de l’hôte sur lequel est nstallé le HIDS et assurent ainsi seulement la sécurité de l’hôte en question.
La deuxième catégorie est formée par les détecteurs d’intrusion réseau (NIDS), ceux-ci observent et analysent le trafic réseau, cherchent des indicateurs d’attaques et envoient des alertes.
SNORT, logiciel open source se situe dans la deuxième catégorie des IDS.
La première question qui se pose lorsqu’on décide de déployer une sonde sur son réseau est son emplacement.
« Où je la mets ma sonde ??? » Et la je vous répond dans ton cul ça dépend.
En général, 3 endroits sont désignés pour cela :
- Avant le Firewall
dans cette position, la sonde occupe une place de premier choix dans la détection des attaques de sources extérieures visant votre réseau.
SNORT pourra alors analyser le trafic qui sera éventuellement bloqué par le Firewall.
Les deux inconvénients de cette position du NIDS sont:
primo, le risque engendré par un trafic très important qui pourrait entraîner une perte de fiabilité et secondo, étant situé hors du domaine de protection du firewall, le NIDS est alors exposé à d’éventuelles attaques pouvant le rendre inefficace.
- Dans la DMZ (après le firewall)
dans cette position, la sonde peut détecter tout le trafic filtré par le Firewall et qui a atteint la zone DMZ. Cette position de la sonde permet de surveiller les attaques dirigées vers les différents serveurs de votre réseau accessibles de l’extérieur.
- Dans le LAN
Là, vous détecter le trafic qui a été validé par le Firewall mais également les attaques internes (je sais, chez vous, à moins d’être schyzo, peu de chances de vous auto-attaquer.)
Personnellement, j’opte pour la première solution et je vous expliquerais comment optimiser les écritures MySQL avec un module supplémentaire.
Sur le serveur hébergeant SNORT, je dédie une carte réseau à la sonde.
Pour renifler le trafic, vous avec le choix :
- Votre réseau est relié à un HUB (erf, il y en a encore…)
Dans ce cas, pas de soucis, tout le trafic est dupliquer sur tout les ports du HUB, il suffit de brancher la sonde dessus.
- Votre réseau est relié à un SWITCH (c’est mieux)
Dans ce cas, ou vous placer un hub entre votre modem/routeur exterieur et votre Switch et sur lequel vous brancherez la sonde, ou vous utilisez un boitier TAP (voir ici) .
Entre nous, le hub vous coutera moins cher 😉
- Votre réseau est relié a un Switch CISCO (ahhh, c’est très bien 🙂 )
Sur les Catalyst (gamme de switch Cisco), vous pouvez définir un des ports en mode mirroir et lui dire quels autre ports il doit dupliquer le trafic.
Le terme CISCO est SPAN pour Switched Port Analyser.
Exemple pour passer l’interface 1 d’un switch type 2900 en mode SPAN :
Switch(config)#interface fastethernet 0/1
Switch(config-if)#port monitor fastethernet 0/2
Switch(config-if)#port monitor fastethernet 0/5
Voila, l’interface 1 écoute tout le trafic cicurlant sur les interfaces 2 et 5.
Si vous voulez écouter un VLAN entier :
Switch(config-if)#port monitor vlan 1
Magique non ?…
Pour vérifier vos configs :
Switch#show port monitor Monitor Port Port Being Monitored --------------------- --------------------- FastEthernet0/1 VLAN1 FastEthernet0/1 FastEthernet0/2 FastEthernet0/1 FastEthernet0/5 FastEthernet0/4 FastEthernet0/3 FastEthernet0/4 FastEthernet0/6
Bien, maintenant que vous savons où positionner notre sonde, préparons la carte réseau (remplacer eth4 par la votre) :
/sbin/ifconfig eth4 up /sbin/ifconfig eth4 -arp
L’option -arp demande à la carte de ne pas répondre aux requêtes ARP (j’aime assez la discrétion 🙂 )
Eviter également d’affecter une adresse IP à la carte, cela ne sert à rien.
Un petit tour chez SNORT pour télécharger la dernière version :
Récuperer également la dernière release de Barnyard , nous nous en servirons plus tard.
A suivre…
Fév
04
VMware et CARP
Si vous utilisez OpenBSD (c’est bien déjà 🙂 ) vous avez sûrement entendu parler ou jouer avec CARP
Si ce n’est pas le cas, dépêchez vous de vous y mettre, vous passez à côté d’un mécanisme de redondance très puissant.
Sans entrer dans les détails, la FAQ d’OpenBSD vous éclairera plus, CARP permet d’assigner une VIP (ip virtuelle) que se partage deux serveurs. En cas de défaillance de l’un, l’autre prend la relève dans la seconde. Si en plus je vous dis que vous pouvez synchroniser vos états de sessions Firewall PF en même temps, là je suis certain que vous êtes déjà en train d’éplucher la documentation. (oui, oui, si j’ai le temps, je ferais un petit billet sur CARP et pfsync, même si d’autres personnes ont fait d’excellents tutos la dessus).
Bref, ce n’est pas le but de ce billet mais un petit « bug » anodin que je vous propose de corriger si vous décidez d’utiliser VMware pour monter l’un ou les deux serveurs OpenBSD.
Pour être fonctionnel, CARP a besoin de passer les interfaces sur lesquelles il écoute en mode Promiscuous afin d’ « écouter » le trafic.
Sur une carte réseau normale, pas de soucis, cela se fait naturellement. Par contre, sous VMware, vous ne vous adressez pas directement au matériel mais à une couche d’émulation qui elle, s’adresse au hardware.
C’est là que les soucis arrivent…
En effet, dans le *bsd, on voit bien la carte passer dans ce mode :
Puffy:~# ifconfig sis1
sis1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
Mais la véritable carte réseau, elle ne passe pas dans ce mode.
Ceci est tout simplement un problème de droits d’accès au périphériques /dev/vmnet*
Pour remédier a cela, un simple :
vmbox:# chgrp <newgroup> /dev/vmnet0
vmbox:# chmod g+rw /dev/vmnet0
vmbox:# /etc/init.d/vmware restart
corrigera le problème.
Bien sûr, « newgroup » correspond à un groupe dans lequel fait parti l’utilisateur faisant tourner le serveur VMware.
Vous trouverez plus d’infos sur le site de VMware.
Fév
03
Configuration de Prelude (la suite…)
A relire mon précédent billet sur Prélude, je me rend compte de sa « légèreté » dans son explication.
Imaginant Argos les yeux bouffis de lectures nocturnes, saturé de café et de coca-cola pour enfin avoir une jolie mire Prewikka sur son serveur, je veux apporter quelques éléments supplémentaires et surtout remettre au point la structure des fichiers de configuration.
Pour apporter encore plus d’aide, je joint dans ce billet mes différents fichiers de configuration.
Tout d’abord, je considère que vous avez installé le Prelude-Manager, Prelude-lml et Prewikka sur la même machine.
Il faut bien faire attention aux variables INCLUDE des différents fichiers de configuration qui chargent des élements communs à tous.
Tout d’abord le /etc/prelude-manager/prelude-manager.conf
On y trouve la variable : include = /etc/prelude/default/global.conf
Ensuite le Prelude-lml, avec son prelude-lml.conf
Si on fait attention a son contenu, on y trouve un appel à include = /etc/prelude/default/idmef-client.conf qui contient juste deux include :
include = /etc/prelude/default/global.conf
include = /etc/prelude/default/client.conf
Le global.conf est plus haut, voici le client.conf :
La variable server-addr = 127.0.0.1 spécifie que le LML écoute en local (normal, le Prelude Manager est sur la même machine).
La variable server_address dont je parlais précédemment concerne un client lambda (comme prelude-pflogger par exemple).
Ensuite Prewikka et son prewikka.conf
Et le fichier vhost pour Apache :
Avec ses nouveaux éléments, j’espère vous guider un peu plus dans votre installation et garder surtout en mémoire de bien lire la structure des fichiers de configuration qui bien souvent chargent des variables d’autres fichiers.
Bon courage 🙂