Snort:Contre mesure:Execution Guardian

From aldeid
Jump to navigation Jump to search

Exécution de Guardian

Vérifications préalables

  • Variables d’environnement

Vous devez au préalable vérifier que le chemin /usr/local/bin, dans lequel vous avez copié les scripts, est contenu dans la variable d’environnement $PATH :

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • Création des fichiers guardian.target et guardian.ignore

Assurez-vous d’avoir créé le fichier /etc/guardian.ignore, puis créez deux fichiers vides guardian.target et guardian.log :

# touch /etc/guardian.target
# touch /var/log/guardian.log
  • Permissions correctes des scripts
# chmod 777 /usr/bin/guardian_*.sh

Lancement de Guardian

Pour exécuter Guardian, utilisez la commande suivante :

# cd /usr/local/bin
# guardian.pl –c /etc/guardian.conf
Note
  • Il est possible de lancer Guardian en mode de débogage, en l’appelant avec le paramètre –d.
  • Si le chemin d’accès au fichier de configuration est /etc/guardian.conf (chemin par défaut), le paramètre –c est optionnel.

Tests

Pré-requis

Le serveur étant virtualisé sous VMWare en mode de réseau NAT (Network Address Translation), l’adresse IP du serveur est sur la même passerelle que le PC « attaquant ».
C’est pourquoi nous allons devoir modifier le fichier guardian.pl pour lui faire accepter les blocages sur la même passerelle .
Pour ce faire, éditez le fichier /usr/local/bin/guardian.pl :

# vim /usr/local/bin/guardian.pl

Puis, dans la fonction checkem, commentez les lignes 122 à 128 dans l’extrait de code suivant :

Mise en œuvre des tests

En mode debug

Vérifiez que Snort est actif (ps aux | grep snort) puis lancez le script Perl Guardian en mode debug :

# /usr/local/bin/guardian.pl -d
OS shows Linux
My ip address and interface are: 192.168.182.133 eth0
Loaded 2 addresses from /etc/guardian.ignore
Loaded 0 addresses from /etc/guardian.target
Running in debug mode..
Note
Le mode debug va nous permettre de voir les événements directement sur la sortie standard. Dans la mesure où nous effectuons des tests, ce mode est idéal.

Parallèlement, sur le PC, lancez un NMAP qui pointe sur le serveur :

# nmap -T Aggressive -v 192.168.182.133

Si Guardian fonctionne, il doit générer sur la sortie standard les lignes suivantes :

[**] [122:1:0] (portscan) TCP Portscan [**]
[Priority: 3]
04/18-05:56:32.833781 192.168.182.1 -> 192.168.182.132
PROTO:255 TTL:0 TOS:0x8 ID:0 IpLen:20 DgmLen:168 DF

[**] [116:59:1] (snort_decoder): Tcp Window Scale Option found with length > 14
[**]
Fri Apr 18 05:56:43 2008:
Running '/usr/bin/guardian_block.sh  eth0'
Bad argument `DROP'
Try `iptables -h' or 'iptables --help' for more information.
[Priority: 3]
04/18-05:56:43.147870 192.168.182.1:46509 -> 192.168.182.132:20
Fri Apr 18 05:56:43 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Running '/usr/bin/guardian_block.sh 192.168.182.1 eth0'
TCP TTL:39 TOS:0x0 ID:21709 IpLen:20 DgmLen:60
**U*P**F Seq: 0x39B86A80  Ack: 0x33A9756C  Win: 0xFFFF  TcpLen: 40  UrgPtr: 0x0

Si guardian fonctionne correctement, le scan ne doit pas pouvoir être effectué jusqu’au bout et la console SSH de prise de contrôle à distance doit se terminer avec l’apparition du message suivant :

Read from remote host 192.168.182.132: Connection reset by peer
Connection to 192.168.182.132 closed.

Pour débloquer le PC, entrez directement la commande suivante sur le serveur (où vous remplacerez l’adresse 192.168.182.1 par celle du PC bloqué) :

# /usr/bin/guardian_unblock.sh 192.168.182.1 eth0

En mode daemon

En mode daemon, les logs ne sont plus affichés sur la sortie standard mais sont inscrits dans le fichier /var/log/guardian.log.
Exécutez le script guardian.pl sans paramètre, afin de le lancer en mode daemon :

# /usr/local/bin/guardian.pl
OS shows Linux
My ip address and interface are: 192.168.182.132 eth0
Loaded 2 addresses from /etc/guardian.ignore
Loaded 0 addresses from /etc/guardian.target
Becoming a daemon..

Recommencez les tests : à partir d’une console SSH sur un poste client, exécutez la commande :

# nmap –T Aggressive –A –v 192.168.182.132

Le même comportement doit être observé (blocage de la console puis message de fermeture de la connection SSH).
Réitérez alors le déblocage sur le serveur directement, comme vu précédemment puis analysez les fichiers de logs :

# vim /var/log/guardian.log

Vous devez alors retrouver dans les traces l’appel du script guardian_block avec, comme paramètres, l’adresse IP (192.168.182.1) et l’interface (eth0) :

Guardian process id 2787
Fri Apr 18 06:11:13 2008:
Running '/usr/bin/guardian_block.sh  eth0'
Fri Apr 18 06:11:13 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Running '/usr/bin/guardian_block.sh 192.168.182.1 eth0'
Fri Apr 18 06:11:13 2008:
Fri Apr 18 06:11:13 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Fri Apr 18 06:11:13 2008:
Fri Apr 18 06:11:13 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Fri Apr 18 06:11:13 2008:
Fri Apr 18 06:11:13 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Fri Apr 18 06:11:15 2008:
Fri Apr 18 06:11:15 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Fri Apr 18 06:11:16 2008:
Fri Apr 18 06:11:16 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Fri Apr 18 06:11:17 2008:
Fri Apr 18 06:11:17 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan
Fri Apr 18 06:11:17 2008:
Fri Apr 18 06:11:17 2008: 192.168.182.1 [122:1:0] (portscan) TCP Portscan




Partie contre-mesure
[Sommaire]
Partie automatisation