Le Script IDS a été porté pour NT. Je n'ai testé personellement aucun des scripts, vous êtes tout seuls.I have not personally tested any of the scripts, you are on your own.
James Oryszczyn
Oscar Wahlberg has dévellopé fw1_alert.pl, en PERL
Roberson Andrew a écrit alert.zip, écrit principalement en Windows Script Host 5.1
Nouvelles Fonctionalités avec la version 1.4.4:
Ajout de TOTAL SCAN LIMIT, Qui vous évitera d'être innondé
d'email. Le nombre maximum d'email que vous pouvez obtenir est 500 par jour
par défaut (peut être défini à la valeur que vous voulez).
Autres fonctionalités :
Un script d'installation qui construit, installe, et teste tout pour vous. Inclut une option qui détermine automatiquement l'administrateur de la source du scan et l'informe par email. En outre depuis FW-1 version 4.0, vous avez la possibilité de bloquer automatiquement les systèmes qui sont en train de vous scanner. Vous devriez également trouver cette version beaucoup plus facile à lire et à comprendre. Vous pouvez ajouter vos propres modules d'alerte, tels que des alertes sur pager ou des trap SNMP. Télécharger le dernière version ici.
Le Problème
Comment savez-vous si quelqu'un sonde votre réseau ? Les fichiers de logs sont bien entedu un très bon endroit pour commencer, particulièrement vos logs FW-1. Malheureusement, ces logs naturels peuvent pénibles et longs à filter (particulièrement si vous enregistrez plus de 400Mo chaque jour). Ne serait-il pas formidable s'il y avait une méthode automatisée de vous prévenir ? Bien, c'est justement ce que fait cet article.
Il y a une variété de sondes et d'attaques différentes que les pirates essayeront. Le type de sonde sur lequel nous allons nous focaliser est le "Port Scan" (NdT : balayage de ports). On parle de scan de ports lorsqu'un individu essaie de se connecter à une variété de ports pour identifier quels services sont actifs sur une machine. Les scans peuvent être utilisés sur une cible spécifique, ou pour balayer des plages d'adresses IP, souvent choisies au hasard. C'est l'une des méthodes de collecte d'informations parmis les plus populaires, utilisées par les pirates aujourd'hui car elle identifie les ports et les services ouverts. Si vous voulez en savoir plus au sujet de ces techniques, consultez Know Your Enemy (NdT : traduit en français également...).
L'objectif
Le but est de recevoir un email d'alerte dès que quelqu'un essaye de scanner ou de sonder votre réseau. Nous voulons automatiser complètement le processus, vous épargnant du temps et de l'énergie. Nous voulons également archiver cette information dans une base de données pour une utilisation future. Notre définition d'un email d'alerte resemblerait à ce qui suit :
Date: Wed,
31 Dec 1997 15:40:01 -0600 (CST)
From:
ids@example.net
To: fwadmin@example.net
Subject:
#### Firewall ALERT ####
You have received this message because someone is potentially scanning your systems. The information below is the packet that was denied and logged by the Firewall. This is email alert number 3, with a limit of 5 from evil.example.org.
----- CRITICAL INFORMATION -----
Date:
31Dec1997
Time:
15:39:59
Source:
evil.example.org
Destination: ns1
Service: domain-tcp
----- ACTUAL LOG ENTRY -----
31Dec1997 15:39:59 drop fw1 >elx0 mail proto tcp src evil.example.org dst ns1 service domain-tcp s_port 37401 len 44 rule 6
Comme vous voyez, cet email alerte le fwadmin que quelqu'un a essayé d'exécuter un transfert de zone non autorisé à partir du serveur de noms. Cependant, le firewall a refusé la tentative, l'a enregistréei, ET a alerté le fwadmin. Dans l'email d'alerte, nous avons parsé l'information critique pour en faciliter la lecture, et avons également inclus l'entrée réelle du fichier de log pour plus d'information. Vous pouvez également créer vos propres alertes, telles que des pages de textes ou des traps SNMP.
La Solution
Pour détecter et surveiller ces balayages, nous écrirons un script qui premièrement enregistre dès que quelqu'un se connecte à un port prédéterminé, et ensuite nous envoie un email d'alerte. Pour ce fairei, nous utiliserons le User Defined Alert. L'alerte sera notre script, alert.sh. A chaque fois que User Defined Alert est déclenchée, elle lancera notre script, qui analyse les données et effectue tout le travail pour nous. Nous avons installé notre base de règles firewall, comme suit. D'abord, nous identifions les ports les plus généralement balayés que nous voulons surveiller. Ensuite, nous choisissons plusieurs systèmes pour écouter sur ces ports. Quand un intrus balaye notre réseau, il frappera très probablement nos systèmes écoutant sur ces ports. Quand ces ports sont balayés, le firewall enregistre les tentatives et exécute alors la User Defined Alert.
Le resultat final est que vous recevez un email pour chaque port scanné. Si vous avez 3 systèmes, écoutant chacun sur 4 ports, alors vous pouvez avoir jusqu'à 12 email pour un seul scan. Cependant ce n'est pas le cas généralement. Si des pirates scannent un réseau entier, ils recherchent normalement une seule vulnérabilité, comme imap (port 143). Dance cas vous n'auriez reçu que trois emails, un de chaque système. Lorsqu'ils scannent cible isolée, souvent ils scannent des plages de ports, comme 1 - 1024. Dans ce cas, vous n'auriez reçu que 4 emails, un pour chaque port du système. En vous basant sur les emails que vous obtenez, vous pouvez rapidement déterminer ce qui intéresse l'intrus. De plus, le script alert.sh peut être configuré pour limiter le nombre total d'emails résultant d'un scan (la limite par défaut est 5). Tous les scans sont aussi enregistrés dans une base de données.
Pour ceux d'entre vous qui ont plus d'un firewall, le script devrait être installé sur le Management Server. Le Management Server tous les logs firewall et exécute la User Defined Alert (notre script) localement sur lui même. Donc si vous avec 5 Modules Firewall se référant à un seul Management Module, vous devrez installer le script sur le Management Module. Les 5 firewall modules peuvent utiliser le script (comme défini dans leur base de règles), cependant le script est exécuté sur le Management Module (où se trouvent les logs). Ce qui est extremement avantageux pour vous, puisque vous pouvez ainsi détecter des scans se produisant sur plusieurs firewalls.
Implémentation
Pour mettre en application cette méthodologie, nous identifions d'abord deux
à trois systèmes que chaque firewall utilise pour la surveillance. Je choisis
souvent des serveurs DNS, comme ce sont les cibles primaires, beaucoup d'outils
de scan commencent par balayer ces systèmes. Une fois que vous avez identifié
les systèmes que vous surveillerez, créez un objet workstation (Ndt : poste
de travail) dans votre GUI firewall 1 pour chacun des systèmes. Les systèmes
ne doivent pas nécessairement réellement exister. Créez un objet pour un système
non-existant, donnez-lui une IP valide que vous n'utilisez pas, et utilisez
le comme un de vos objets scannables. Une fois que vous avez créé vos objets
workstation, choisissez alors les ports le plus généralement balayés. Assurez-vous
que vos systèmes n'utilisent pas ces ports, ou chaque fois quelqu'un se relie
à l'un d'eux, vous serez alerté. Pour identifier les ports généralement balayés
les alertes du CERT sont un bon endroit où commencer, vous peut trouver
ces alertes sur : http://www.cert.org/. Quelques ports que vous
pouvez utiliser sont:
dns zone transfer
53/TCP
portmapper
111/TCP
http
80/TCP
SMB
139/TCP
imap
143/TCP
BackOrrifce 31337/UDP
--> Oui les gens scannent ENCORE à la recherche du vieux BO.
J'aime bien ces ports car les pirates (NdT : black-hats) les recherchent généralement, mais la plupart de vos systèmes ne les utiliseront pas. Assurez-vous que ces ports ne sont pas déjà bloqués par un routeur filtrant en amont. Nous placerons alors plusieurs systèmes à l'écoute sur ces ports, nous alertant dès qu'il y aura des connexions. Ci dessous un exemple d'une règle qui surveille et détecte ces scans. Notez qu'un certain nombre de ports sont surveillés pours ces sytèmes.
Comme vous pouvez le voir sur l'image ci-dessus, cette base de règle surveille un certain nombre ports. En outre, cette règle est notre règle User Defined Alert. Toutes les fois que cette règle reçoit une connexion sur un de ces ports, l'alerte définie par l'utilisateur (NdT : User Defined Alert) sera activée. Notre alerte (alert.sh) analysera alors les données pour ces connexions, nous informera par l'intermédiaire d'un email, et archivera l'information. Soyez sûr de configurer votre User Defined Alert pour pointer sur le script alert.sh. Vous faites ceci par le menu policy / property / onglet Log and Alert et indiquez le chemin complèt d'accès à alert.sh (comme /home/fwadmin/alerts/alert.sh).
Ci-dessous un autre exemple d'utilisation du script alert.sh. Votre DMZ devrait ne jamais initier de trafic vers votre réseau interne. Par conception, vous ne faites pas confiance à votre DMZ puisqu'elle est accessible par l'Internet. Aussi, j'ai créé une règle supplémentaire pour enregistrer et m'alerter toutes les fois que la DMZ essaye de lancer une connexion ver le réseau interne. Si la DMZ essaye d'atteindre votre réseau interne, cela peut vouloir dire qu'un des systèmes de la DMZ a été compromis et que les mauvais garçons essayent d'entrer. Notez que j'ai mis cette règle juste avant la dernière règle "de nettoyage" (NdT : "catch all and drop" On attrappe tout et on rejette ).
C'est tout, vous avez fini. Tout ce que que vous avez
à faire c'est télécharger
la dernière version et exécuter le script d'installation.
Si vous voulez savoir comment fonctionne le script ou le modifier, lisez ce
qui suit.
--- Ceci est purement informatif vous n'êtes pas obligé de le lire ---
Le processus d'alerte fonctionne comme suit. Tout d'abord, nous définissons la UDA (NdT : User Defined Alert : Alerte définie par l'utilisateur) (comme dans l'image ci-dessus) comme étant notre script alert.sh. La UAD produit une entrée log pour chaque connection repérée. La ligne de log ressemble à ceci :
31Dec1997 15:39:59 drop fw1 >elx0 mail proto tcp src evil.example.org dst firewall service domain-tcp s_port 37401 len 44 rule 6
Le firewall alimente notre script alert.sh avec cette ligne de log. Le script parse alors ces données et exécute diverses fonctions définies par nous. Le script alert.sh utilise les fichiers suivants pour stocker et pister les logs.
alert.uniq - Un entrée unique et permanente est ajoutée à ce fichier toutes les fois qu'un système vous scanne. Indépendamment du nombre de ports balayés, il y aura seulement une entrée par source. De cette façon vous pouvez facilement dépister qui vous a balayé et quand.
alert.log - Ce fichier enregistre temporairement chaque port balayé pour ce jour. C'est ainsi que le le script alert.sh trouve combien de fois/ports ont été balayés depuis une source unique. Chaque fois que l'UDA exécute alert.sh, la première chose que fait le script est de compter compte combien de fois la source ($src) nous a balayés pour ce jour en regardant dans alert.log. Quand le script alert.sh l'a fait, il ajoute une entrée au fichier alert.log. Ainsi, la première fois qu'une source balaye un port, alert.sh ne trouvera rien dans l'alert.log. La deuxième fois que les sources balayent un port, il trouvera une entrée, et ainsi de suite. Vous fixez une limite sur combien de ports sont balayés avant que l'alert.sh ne cesse de réagir (ceci protège contre les attaque de Déni de Service (NdT : DOS attacks) ). À la fin du jour, un cronjob (rotate.sh) effacera ce fichier et ajoutera toutes les entrées à archive.log. De cette façon si la même source vous balaye encore à une date ultérieure, alert.sh enregistrera la tentative.
alert.archive - Ce fichier archive de manière permanente chaque port balayé et loggé. C'est une base de données archive qui peut être utilisée pour des recherches. Ce fichier stocke les lignes log réelles, aussi il tend à être difficile à lire. Je trouve le fichier alert.uniq beaucoup plus facile à lire.
rotate.sh - This is a cronjob you need to run every day. It clears the file alert.log, saving all the logged entries to archive.log. This resets the counter for the alert.sh script. If the same source scans you two days in a row, this allows you to log it.
est un cronjob que vous devez exécuter chaque jour. Il efface le fichier alert.log, sauvegardant toutes les entrées enregistrées dans archive.log. Ceci remet à l'état initial le compteur pour le script alert.sh. Si la même source vous balaye pendant deux jours consécutifs, ceci vous permet de l'enregistrer.
Pour avoir une meilleure compréhension du fonctionnement de notre script alert.sh, lisez ce qui suit. Le script est décomposé en 6 parties.
1. First, we need to customize our script, which is done in the beginning of the script. This should be self explanatory.
#################################################################
#
BEGIN CUSTOMIZING SCRIPT
HERE
#
#################################################################
# INSTALL
DIRECTORY
#
Define the directory that this script is in.
# Do NOT put a slash at the
end.
# EXAMPLE:
dir=/home/fwadmin/alert
dir=
# FW ADMIN
# Define the name of who gets
the email alerts
# EXAMPLE: user=fwadmin@example.com
user=
# SCAN LIMIT
# Define maixmum number of
scans/email alerts
limit=5
# EMAIL REMOTE
SYSTEM
# Define
as "true" if you want to automatically email
# the remote admin when you reach your
scan limit.
email=false
# SAM
# Define as "true" if you want to
autotmatically block
# the source if you reach your scan limit.
sam=false
# SAM TIMEOUT
# How long do you want the
source blocked
# Default is 3600 seconds (1 hour).
timeout=3600
#################################################################
#
FINISH CUSTOMIZING SCRIPT
HERE
#
#################################################################
2. We then define our system variables. Also, we check to see if we have met our scan limit. If we have, bail now to save CPU cycles. This is where the speed optimization happens.
### Script variables
message=/tmp/.message_$$
send=/tmp/.send_$$
### Good code is secure code
umask=177
PATH=/usr/bin:/sbin:/usr/sbin:/usr/local/bin
export PATH
if test -a $message
then
rm $message
fi
if test -a $send
then
rm $send
fi
### Set trap in case of abrupt exit
trap "rm $send $message ; exit 5" 1 2 15
### Grab User Defined Alert log, pipe to $message.
cat - | tail -1 > $message
### Determine number of scans.
ip=`awk '{print $10}' $message`
number=`grep -c $ip $dir/alert.log`
scan=`expr $number + 1`
### Check number of scans. If we have reached our limit, lets bail
### now and save CPU cycles.
if [ $scan -gt $limit ];then
cat $message >> $dir/alert.log
rm $message
exit 10
fi
### Parse log file
date=`awk '{print $1}' $message`
time=`awk '{print $2}' $message`
dst=`awk '{print $12}' $message`
### Determine service (check some variables first)
#Determine if "Valid Address" is in log files for NAT
nat_check=`grep -c "(Valid Address)" $message`
#Determine if protocol is icmp
icmp_check=`grep -c " icmp " $message`
if [ "$nat_check" -eq 0 ];then
if [ "$icmp_check" -eq 0 ];then
service=`awk '{print $14}' $message`
else
service=`awk '{print $15,$16,$17,$18}' $message`
fi
else
if [ "$icmp_check" -eq 0 ];then
service=`awk '{print $16}' $message`
else
service=`awk '{print $17,$18,$19,$20}' $message`
fi
fi
3. We then define all functions / modules used in the script. The script comes with three predifined modules, you can add more of your own.
- Resolve () - If the source is an IP, resolve it to a fully qualified host name.
- Block () - Blocks any remote system that reaches its scan limit. Works on FW-1 ver 4.0 only.
4. We then build our alert emails. This is the template
used for every email alert that is generated.
cat <<EOF > $send
You have received this message
because someone is potentially
scanning your systems. The
information below is the packet
that was denied and logged by the
Firewall. This is email alert
number $scan, with a limit of $limit
from $src.
----- CRITICAL INFORMATION -----
Date: $date
Time: $time
Source: $src
Destination:
$dst
Service: $service
----- ACTUAL FW-1 LOG ENTRY -----
`cat $message`
EOF
5. Last, we reach the phases part. This is where we define what the script does (in addition to the alert emails) based on how many time the source has probed us. This is broken down into three parts, or phases. Feel free to change/modify these phases as you see fit. I've tried to make this as modular as possible for just that reason. Regardless, once we are done, we send off the email alert.
- PHASE 1: This is when we receive the very first packet. The entry is logged in the alert.uniq file.
- PHASE 2: This is when we receive the 2nd to $limit-1 packets. Currently nothing happens during phase 2
- PHASE 3: This is when we receive our $limit packets (default is 5). Here is where most of the action happens. This is where the functions Blocked(), TrackDown(), and anything else you want to add.
/usr/bin/mailx -s "#### SCAN
ALERT ####" $user < $send
cat $message >>
$dir/alert.log
6. Don't forget, at the end of the day, run the cronjob rotate.sh. The purpose of this cronjob is to take all the logged entries from alert.log and move them to the permanent archive file alert.archive. This also clears out the alert.log file, allowing it to start counting new sessions.
Thats it! I hope this does not sound complicated. Once you get it
up and running, you will see how simple it is. I hope this
helps you in your intrusion detection. While this is not the ultimate
end-all solution, it is a great and easy start to automating your intrusion
detection. If you have any recommendations or corrections, I would love to
hear from you. Please email me at mailto:lance@spitzner.net?Subject=Your
Intrusion Detection article.
Biographie de l'auteur
Lance Spitzner a plaisir à apprendre en faisant sauter ses systèmes Unix
à la maison. Avant cela, il était Officier
dans la Rapid Deployment Force,(NdT : Force de Déploiement Rapide)
où il faisait sauter des choses diffrentes. Vous pouvez le joindre à
cette adresse : lance@spitzner.net .
| Whitepapers / Publications |