fév 19

Le RAID simplifié

Décidément, c’est la semaine humour…

Ils nous arrivent fréquemment de devoir expliquer à des non-initiés, ce qu’est le RAID et les exemples sont peu nombreux.

Heureusement, mon ami « Poupinade » a trouvé une explication limpide (qui coule de source ?… (ok je sors ->[] )

raid

Classé dans geekerie | 4 Commentaires
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 :

http://www.snort.org/dl/

Récuperer également la dernière release de Barnyard , nous nous en servirons plus tard.

A suivre…

Classé dans linux, réseau, sécurité | Commentaires fermés
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.

Classé dans OpenBSD | 2 Commentaires