Pour mémoire, 'Roesch' est prononcé comme 'fresh' sans le 'f'. De plus, 'Ruiu' est prononcé comme 'screw you' sans le 'sc'. Et le nom de Jed est comme "pick-el", non pas "pickle". :)
Non. fyodor@insecure.org est l'auteur de nmap, et il utilise le même pseudonyme que l'autre Fyodor de snort dont c'est son vrai nom de famille. Oui, cela met en désordre ma boite à lettre aussi, mais je pense qu'il est trop tard pour changer l'un ou l'autre :-).
Exécutez snort en mode sniffer (snort -dvi eth0) et soyez sûr qu'il peut voir les paquets. Puis exécutez le avec HOME_NET fixé de façon appropriée pour le réseau que vous défendez dans votre fichier de règles. Un fichier de règles par défaut vient avec la distribution de snort et est appelé "snort.conf" Vous pouvez exécuter cet ensemble basique de règles avec la ligne de commande suivante :
snort -Afull -c snort.conf
S'il est configuré correctement, une fois qu'il s'exécute faites un "ifconfig -a" et soyez sûr que l'interface est en mode promiscuous (cela dit, ceci dans la section options des impressions). Si ce n'est pas le cas, il devrait y avoir une façon de le fixer manuellement.
Si vous avez spécifié un répertoire de journalisation avec le paramètre -l alors c'est là où sont localisés vos fichiers. Si vous n'avez pas spécifié de répertoire de journalisation, alors Snort va journaliser dans /var/log/snort/ .
Dans le passé, exécuter Snort en mode démon (-D) produisait un fichier nommé "snort.alert". Pour des raisons de cohérence, ceci a été changé. Exécuter Snort en modes standard ou démon (-D) produira un fichier nommé "alert".
Ceci sera fortement influencé par la politique de votre entreprise, et ce que vous voulez détecter. Une façon de voir est de déterminer si vous voulez le placer à l'intérieur ou à l'extérieur de votre firewall. Placer un IDS à l'extérieur de votre firewall vous permettra de surveiller toutes les attaques dirigées vers votre réseau, sans tenir compte si elles sont stoppées par le firewall ou non. Ceci signifie certainement que l'IDS va remonter plus d'alertes qu'un IDS à l'intérieur de votre firewall et donc plus de journaux seront générés. Placez un IDS à l'intérieur de votre firewall si vous êtes intéressés seulement par la surveillance du trafic que votre firewall laisse passer. Si les ressources le permettent, il peut être mieux de placer un IDS à l'intérieur et un IDS à l'extérieur de votre firewall. De cette façon vous pouvez regarder tout ce qui est dirigé vers votre réseau, et tout ce qui a pu pénétrer à l'intérieur.
Ceci dépend du type de commutateur que vous avez. S'il peut dupliquer le trafic, vous pouvez le diriger vers le port où est branché votre boite Snort.
Quelques règles ont plus tendance à produire de faux positifs que d'autres. Ceci varie souvent entre les réseaux. Vous avez d'abord besoin de déterminer si c'est en effet un faux positif. Quelques règles sont référencées avec des numéros ID. Ce qui suit sont quelques systèmes communs d'identification, et où aller trouver plus d'informations à propos d'une alerte particulière.
System Example URL --------------------------------------------------------------- IDS IDS182 http://www.whitehats.com/info/IDS182 CVE CVE-2000-0138 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0138 Bugtraq BugtraqID 1 http://www.securityfocus.com/vdb/bottom.html?vid=1 McAfee Mcafee 10225 http://vil.nai.com/vil/dispVirus.asp?virus_k=10225
Il peut être nécessaire d'examiner la charge des paquets pour déterminer si l'alerte est un faux positif. La charge du paquet est journalisée en utilisant l'option -d. Si vous déterminez que les alertes sont des faux positifs, vous pouvez vouloir écrire une règle "pass" pour les machines qui en produisent un grand nombre. Si la règle produit une quantité ingérable de faux positifs de nombre de machines différentes, vous pourriez positionner la règle en "pass" pour tout le trafic. Ceci ne doit être utilisé qu'en dernier recours.
Beaucoup pensent qu'une pile de faux positifs est infiniment préférable. Ensuite les personnes peuvent désactiver ce qu'elles ne veulent pas. L'inverse, avoir un petit ensemble de règles, peut leurrer les personnes dans une autosatisfaction en pensant que Snort joue son rôle et qu'il n'y a pas de raison de s'en faire.
La plupart d'entre eux sont certainement des "destination unreachable" et des "port unreachable" qui ont été détectés par snort quand une tentative de session de communication a échoué.
Snort 1.7 supporte les listes IP. Vous pouvez assigner plusieurs adresses à une seule variable. Par exemple :
var HOME_NET [10.1.1.0/24,192.168.1.0/24]
NOTE : tous les préprocesseurs ne supportent pas les listes IP actuellement. Sauf indication contraire, assumez que tout préprocesseur utilisant une variable contenant une liste IP n'utilisera que la première valeur comme réseau local. Le préprocesseur portscan (ndt : de scans de ports) est un exemple. Pour attraper tous les scans de ports détectables, utilisez 0.0.0.0/0 comme premier paramètre.
preprocessor portscan: 0.0.0.0/0 5 3 portscan.log
Utilisez le préprocesseur portscan-ignorehosts pour régler finement et ignorer le trafic des machines de confiance et bruyantes.
Si vous utilisez au moins la version 1.7, vous pouvez spécifier une liste IP comme ceci :
var HOME_NET [192.168.<your-IP>/24,<Internet address>/32]
Si vous utilisez quelque chose de plus ancien (version 1.6.3-patch2 ou quoi que ce soit d'autre) vous pouvez re-spécifier la variable HOME_NET plusieurs fois comme ceci (par exemple) :
var HOME_NET 10.1.1.0/24
include scan-lib
etc.
var HOME_NET 192.168.1.0/24
include scan-lib
etc.
Écrivez des règles "pass" et ajoutez le(s) système(s) à la liste portscan-ignorehosts . Appelez snort avec l'option -o pour activer les règles "pass". Voyez http://www.snort.org/writing_snort_rules.htm pour plus d'informations.
Ça dépend de la configuration des journaux de snort. S'il journalise au format binaire, vous devrez traiter les journaux binaires pour obtenir le texte en clair.
ifconfig ethN up
Soit vous n'exécutez pas snort en tant que root, soit votre noyau n'est pas configuré correctement.
Il a besoin de ce répertoire pour y journaliser les alertes.
Utilisez: mkdir /var/log/snort
Une des raisons qu'il alerte sur les drapeaux PA est pour minimiser les faux positifs. Vous n'obtiendrez une alerte que pour les connexions réussies. Si vous voulez voir toutes les tentatives, vous devez soit modifier les signatures, soit ajouter vos propres signatures ou soit utiliser les journaux de votre firewall pour voir si une tentative à un port spécifique a eu lieu.
Obtenez plus d'informations de diagnostic et postez les à "snort-users" à http://www.sourceforge.net
Pour obtenir des informations de diagnostic, compilez snort soit :
make clean; make CFLAGS=-ggdb
soit :
make clean; make "CFLAGS=-ggdb -DDEBUG"
Tracez le coredump ainsi :
gdb /path/to/snort /path/to/snort/core
gdb> where
gdb> bt
gdb> print $varname, varname, $$varname etc..
ou si le fichier core n'est pas généré alors snort devrait être démarré ainsi :
gdb snort
gdb> run <snort args without -D switch :-)>
Oui, utilisez "preprocessor defrag"
Snort possède également l'option de règle "minfrag" qui cherche les petits fragments et peut générer des alertes basées seulement sur la taille des fragments. C'est une stratégie valide car il n'y a virtuellement aucun équipement réseau de disponible qui fragmente les paquets plus petits que 256 octets alors que les programmes de hackers qui essayent de masquer leur trafic avec des fragments les font aussi petits que possible. L'option minfrag vous permet de spécifier la taille limite au dessous de laquelle Snort générera des alertes.
C'était un message de diagnostic interne déclenché par un ancien bogue dans les premières versions du préprocesseur de défragmentation. Mettez à jour vers la dernière version de snort.
Vérifiez votre version de libpcap. :) Ci ce n'est pas <= 0.5, alors vous devriez mettre à jour.
Cela dépend ;-) Minimiser le nombre de règles est une augmentation standard des performances. Désactivez les règles dont vous n'avez pas besoin ou auxquelles vous n'apportez pas d'attention. Etc... Il y a eu beaucoup de discussions sur 'tweaking performance' où de nombreux 'I handle XX mb with a ___ machine setup.' (ndt : je supporte XX mb avec une configuration ___ de machine.) ont été dits. Cherchez quelques une de ces discussions sur snort-users
Extrait de l'url : http://public.pacbell.net/dedicated/cidr.html
CIDR is a new addressing scheme for the Internet which allows for more efficient allocation of IP addresses than the old Class A, B, and C address scheme. CIDR Block Prefix # Equivalent Class C # of Host Addresses /27 1/8th of a Class C 32 hosts /26 1/4th of a Class C 64 hosts /25 1/2 of a Class C 128 hosts /24 1 Class C 256 hosts /23 2 Class C 512 hosts /22 4 Class C 1,024 hosts /21 8 Class C 2,048 hosts /20 16 Class C 4,096 hosts /19 32 Class C 8,192 hosts /18 64 Class C 16,384 hosts /17 128 Class C 32,768 hosts /16 256 Class C 65,536 hosts (= 1 Class B) /15 512 Class C 131,072 hosts /14 1,024 Class C 262,144 hosts /13 2,048 Class C 524,288 hosts
Pour plus d'informations techniques détaillées sur les CIDR, allez sur http://www.rfc-editor.org/rfcsearch.html et entrez le numéro du RFC sur les CIDR qui vous intéresse :
RFC 1517: Applicability Statement for the Implementation of CIDR
RFC 1518: An Architecture for IP Address Allocation with CIDR
RFC 1519: CIDR: An Address Assignment and Aggregation Strategy
RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
http://www.tcpdump.org/
IDS signifie "Signature de Détection d'Intrusion" (vrai ?) et identifie une tentative d'attaque connue. Vous pouvez en apprendre plus à propos d'une id spécifique d'IDS sur le moteur de recherche d'arachNIDS sur http://www.whitehats.com/ .
Si vous sauvegardez les parties données des paquets, passez les en revue. Ces règles sont connues pour avoir de hauts taux de faux positifs puisque la plupart d'entre elles sont juste basées sur des numéros de ports.
C'est une partie du préprocesseur http. Typiquement, si la routine de décodage trouve %00 dans une requête http, il alertera avec ce message. Quelques fois, vous pouvez voir de faux positifs avec des sites qui utilisent des cookies avec des données binaires encodées comme des url, ou si vous scannez le port 443 et que vous obtenez du trafic chiffré SSL. Si vous journalisez les paquets suspects, vous pouvez vérifier la chaîne exacte qui a causé l'alerte. Également, l'alerte unicode est sujette aux mêmes faux positifs avec les cookies et SSL. Avoir les sauvegardes des paquets est la seule façon de dire de façon sûre si vous avez la trace d'une véritable alerte entre les mains, mais ceci est vrai pour n'importe quelle alerte basée sur le contenu.
Sans a quelques cours. Il y a quelques livre que vous pourriez vouloir obtenir.
Network Intrusion Detection An Analyst's Handbook
By Stephen Northcutt
ISBN 0735708681
TCP/IP Illustrated, Volume 1 The Protocols
By W. Richard Stevens
ISBN 0201633469
Vous pouvez construire de la redondance en utilisant plusieurs plugins output (ndt : de sortie). Voici quelques exemples.
Plusieurs instances du plugin d'une base de données :
output database: log, mysql, dbname=snort host=localhost user=xyz
output database: log, mysql, dbname=snort host=remote.loghost.com user=xyz
Base de données distante et tcpdump local :
output database: log, mysql, dbname=snort host=remote.loghost.com user=xyz
output log_tcpdump: /var/log/snort.tcpdump
Puis vous pouvez rejouer le fichier tcpdump au travers de snort pour recréer la base de données.
Ce sont des connexions échouées des paquets ICMP unreachable qui portent les 64 premiers octets du datagramme original.
Vous devez installer libpcap avec l'option --install-incl
Vous avez besoin que les outils lex et yacc ou leurs équivalents gnu flex et bison soient installés.
Utilisée en conjonction avec un fichier de règles snort, les données tcpdump peuvent être analysées pour un contenu hostile, des scans de ports, ou toutes autres choses pour lesquelles snort peut être utilisé pour les détecter. Snort peut également afficher simplement les paquets dans leur format décodé, que beaucoup de personnes trouvent plus facile à lire que la sortie tcpdump.
Utilisez l'option "-d" de la liste de commande.
Oui, ils devraient être dans le répertoire qui a la même adresse IP que le système source du paquet qui a généré l'alerte.
L'ordre par défaut d'application des règles est d'abord alert, puis les règles pass, puis les règles log. Cet ordre assure que vous n'écrivez pas 50 bonnes règles d'alertes et que vous ne les désactivez pas toutes avec une règle pass errante. Si vous voulez réellement changer cet ordre de telle sorte que les règles pass sont appliquées en premier, utilisez l'option "-o" de la ligne de commande.
Oui, cette fonctionnalité est en test BETA avec la version 1.7 .
Soyez sûr d'inclure "--enable-smbalerts" quand vous exécutez "./configure" .
Vous devez utiliser du routage entre deux interfaces dummy :
modprobe -a dummy (The dummy device has to be build by the kernel)
ifconfig dummy0 192.168.0.1
ifconfig dummy0:0 192.168.0.2
telnet 192.168.0.3 12345
Il est important que la seconde IP soit sur la même interface et non pas, par exemple, sur dummy1 ou dummy2 et que l'IP que vous essayez d'accéder n'est *pas* une de celles que vous mettez sur les interfaces. Utilisez la capacité de snort d'écouter en mode promiscuous sur un intervalle d'adresses IP. (HOMEDIR=192.168.0.0/16)
Il y a eu quelques problèmes avec les écritures de snort 1.6.3
Lee wrote.. > > Initializing rule chains... > > log_database: Database type is mysql > > log_database: Database name is snort > > log_database: Host set to localhost > > log_database: User set to root > > Problem obtaining SENSOR ID (sid) from mysql->snort->event
Dans la version 1.6.3, il apparaît que beaucoup de personnes ont vu cette erreur parce qu'ils n'ont pas compilé le support pour leur base de données. Ceci devrait être fixé dans snort 1.7
Un "réparation" rapide et facile pour les versions snort plus anciennes est d'ajouter -lm soit à LIBS soit à LDFLAGS dans les Makefile. e.g.
LIBS = -lm -lmysqlclient -lpcap -lsocket -lnsl
De toutes façons, si vous avez toujours ce problème, vous pouvez regarder les informations de mises à jours d'installation et de configuration sur le site web suivant.
http://www.incident.org/snortdb
http://lists.sourceforge.net/mailman/listinfo/snort-users
Le support service a été ajouté à snort-1.6.3-patch2
Vous pouvez télécharger le binaire depuis :
http://www.datanerds.net/~mike/dev/snort-1.6.3-patch2-service.zip
Actuellement il n'y a qu'un binaire accessible.
FAQ du service Snort :
Exécutez snort comme vous le feriez via la ligne de commande mais ajoutez un '-I'. I.E. 'snort.exe -c snort.conf -l ./log -h 192.168.1.0/24 -s' devient 'snort.exe -c C:\snort\snort.conf -l C:\snort\log -h 192.168.1.0/24 -s -I'
VOUS DEVEZ UTILISER LES CHEMINS COMPLETS POUR TOUS LES FICHIERS / REPERTOIRES.
NOTE : Vous n'avez pas besoin d'ajouter l'option -D à la ligne de commande quand vous installez le service. Si -D n'est pas là il sera automatiquement ajouté.
Exécutez 'snort -R'.
Oui. Il utilise un horrible hack pour que ça marche. A cause de cela, quand vous démarrez vous verrez une fenêtre noire de ligne de commande pendant environ 5 secondes avant que snort aille en tâche de fond. Ce mode de service est considéré comme un horrible hack et ne fonctionnera probablement pas dans toutes les situations.
Actuellement Démarrer et Arrêter. Pause et Redémarrer seront implémentées plus tard (le code existe déjà mais ne fonctionne pas proprement).
Merci d'envoyer toutes les questions, commentaires, flammes à mike@datanerds.net
http://www.silicondefense.com/snortsnarf/
http://www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html
Le plug-in de base de données de snort journalise seulement les informations des paquets vers la base de données quand une alerte est déclenchée par une règle (signature). Donc, puisque les alertes générées par les préprocesseurs tels que portscan et mini-fragment n'ont pas de règle correspondante, aucune information de paquets n'est journalisée au delà d'une entrée indiquant leur occurrence. Comme une conséquence, ACID ne peut afficher aucune information au niveau paquet (e.g. adresse IP) pour ces alertes.
Pour ces alertes particulières, certaines statistiques peuvent montrer zéro adresse IP unique, lister les adresses IP comme 'unknown' (ndt : inconnue), et ne listera aucune information de paquet en décodant l'alerte.
Très probablement que l'utilisateur DB configuré dans ACID n'a pas suffisamment de privilèges. En plus des privilèges requis pour journaliser les alertes vers une base de données (INSERT, SELECT), DELETE est également requis.
Ce problème lié aux permissions peut être confirmé manuellement en insérant une ligne dans la base de données, puis en essayant de l'effacer.
e.g. % mysql -u -p
mysql> INSERT INTO event (sid, cid, signature, timestamp) VALUES (1,1000000, "test", "0");
(ceci assume que vous n'ayez pas déjà une ligne avec un événement ID=1000000. Si c'est le cas choisissez un autre numéro d'identification d'événement)
mysql> DELETE FROM event WHERE sid=1 AND cid=10000000;
Si vous n'avez pas été capable de l'effacer, ceci confirme que c'est un problème de permission. Reconnectez vous à mysql en tant que root, et entrez une commande GRANT (en donnant les permissions DELETE) pour l'utilisateur DB de ACID.
e.g. GRANT DELETE on snort.* to acid@localhost
(ceci assume que ma base de données est 'snort', le nom d'utilisateur est 'acid', et les connexions depuis 'localhost')
C'est un problème connu. Lynx mutile quelques arguments du formulaire ajoutés à l'URL. Sa résolution est en cours d'investigation, mais utilisez Netscape, Opera, ou IE en attendant.
La réponse rapide à cette réponse est non. ACID est à la merci de la base de données sous-jacente, puisque Snort n'assigne pas de priorités, ACID n'a pas de priorités. Néanmoins, il y a plusieurs contournements :
Il est possible d'appliquer des priorités de tri au niveau de la base de données en écrivant les alertes de différentes sévérités pour séparer les bases de données. Par exemple, les alertes critiques telles que les débordements de tampons peuvent être écrites dans une base de données d'ACID, alors que les alertes de scans peuvent être écrites dans une autre. Charger alors deux différentes versions d'ACID, chacune pointant vers différentes instances des bases de données.
Avec des interventions manuelles, les Alert Groups (AG) peuvent être utilisés pour assigner des priorités. Essentiellement, cette stratégie implique la création d'un AG pour chaque niveau de priorité et le déplacement manuel des alertes quand elles arrivent dans le groupe approprié.
PHP a une variable interne fixée pour limiter la durée d'exécution d'un script. Elle est utilisée pour prévenir du code mal écrit de s'exécuter indéfiniment. Afin de modifier la valeur de time_out, examinez la variable 'max_execution_time' trouvée dans le fichier de configuration 'php.ini' .
La pile IP Linux ne rapporte pas les statistiques de paquets perdus. Ceci peut varier avec la version 2.4 de Linux, mais pour l'instant vous ne pouvez pas les obtenir. Essayez un des BSD, ils fonctionnent bien (ndt : à l'exception de FreeLSD ;-)
Les scans SYNFIN obtiennent leurs noms du fait que les deux drapeaux SYN et FIN sont positionnés ensembles.
Whitehats IDS177
http://dev.whitehats.com/cgi/test/new.pl/Show?_id=netbios-name-query spécifie le trafic venant de l'extérieur de votre réseau local. Autoriser le trafic netbios au travers de réseaux publics est habituellement très peu sécurisé.
Si la règle que vous utilisez ne se réfère seulement qu'au trafic entrant, alors ceci devrait expliquer pourquoi vous ne voyez pas beaucoup de faux positifs. Pour ceux qui lisent cela et qui voient beaucoup de faux positifs - si vous changez votre règle pour refléter l'adresse source comme étant !$HOME (ou quelleque soit la variable que vous utilisez pour représenter votre réseau interne), alors vous devriez voir la plupart des faux positifs s'en aller.
La valeur de ce contrôle est qu'un partage administratif par défaut comme C$ ADMIN$ ou un tel a été accédé. Ceci ne devrait pas arriver dans une utilisation normale - quand des personnes veulent partager des fichiers elles devraient définir implicitement les partages et les ACL (ndt : droits d'accès).
La ligne de commande obtient toujours la priorité sur le fichier de règles. Si des personnes veulent essayer quelques trucs rapidement sans avoir à éditer manuellement les fichiers de règles, elles devraient être capables de passer outre beaucoup de choses depuis la ligne de commande.
Essayez ce script pour archiver les fichiers
#!/bin/sh # # Logfile rotation script for snort writen by jameso@elwood.net. # # This script is pretty basic. We start out by setting some vars. # Its job is tho rotate the days logfiles, e-mail you with what # it logged, keep one weeks worth of uncompressed logs, and also # keep compressed tgz files of all the logs. It is made to be run # at midnight everynight. This script expects you to have a base # dir that you keep all of your logs, rule sets etc in. You can # see what sub dirs it expects from looking at the var settings # below. # # Things to note in this script is that we run this script at 12 # every night, so we want to set the dirdate var the day the script # runs minus a day so we label the files with the correct day. We # Then create a dir for the days logs, move the log files into # todays dir. As soon as that is done restart snort so we don't miss # anything. Then delete any logs that are uncompressed and over a # week old. Then compress out todays logs and archive them away, and # end up by mailling out the logs to you. # # Define where you have the base of your snort install snortbase=/usr/snort # Define other vars # logdir - Where the logs are kept # oldlogs - Where you want the archived .tgz logs kept # weeklogs - This is where you want to keep a weeks worth of log files uncompressed # dirdate - Todays Date in Month - Day - Year format # olddirdate - Todays date in the same format as dirdate, minus a week logdir=$snortbase/log oldlogs=$snortbase/oldlogs weeklogs=$snortbase/weeklogs # When I first wrote this script, I only ran it on BSD systems. That was a # mistake, as BSD systems have a date command that apperently lets you walk the # date back pretty easily. Well, some systems don't have this feature, so I had # to change the way that dates are done in here. I left in the old way, because # it is cleaner, and I added in a new way that should be portable. If anyone # has any problems, just let me know and I will try to fix it. # # You have to change the system var to either bsd or other. Set it to bsd if # your system supports the "-v" flag. If you are not sure, set it to other. system=bsd if [ $system = bsd ] then dirdate=`date -v -1d "+%m-%d-%y"` olddirdate=`date -v -8d "+%m-%d-%y"` elif [ $system = other ] month=`date "+%m"` yesterday=`expr \`date "+%d"\` - 1` eightday=`expr \`date "+%d"\` - 8` year=`date "+%y"` dirdate=$month-$yesterday-$year olddirdate=$month-$eightday-$year fi # Create the Dir for todays logs. if [ ! -d $weeklogs/$dirdate ] then mkdir $weeklogs/$dirdate fi # Move the log files into todays log dir. This is done with # a for loop right now, because I am afriad that if alot is # logged there may be to many items to move with a "mv *" # type command. There may a better way to do this, but I don't # know it yet. for logitem in `ls $logdir` ; do mv $logdir/$logitem $weeklogs/$dirdate done # Kill and restart snort now that the log files are moved. kill `cat /var/run/snort_fxp0.pid` # Restart snort in the correct way for you /usr/local/bin/snort -i fxp0 -d -D -h homeiprange/28 -l /usr/snort/log \ -c /usr/snort/etc/08292k.rules > /dev/null 2>&1 # Delete any uncompressed log files that over a week old. if [ -d $weeklogs/$olddirdate ] then rm -r $weeklogs/$olddirdate fi # Compress and save the log files to save for as long as you want. # This is done in a sub-shell because we change dirs, and I don't want # to do that within the shell that the script runs in. (cd $weeklogs; tar zcvf $oldlogs/$dirdate.tgz $dirdate > /dev/null 2>&1) # Mail out the log files for today. cat $weeklogs/$dirdate/snort.alert | mail -s "Snort logs" you@domain.com cat $weeklogs/$dirdate/snort_portscan.log | mail -s "Snort portscan logs" you@domain.com
Oui, avec un logiciel supplémentaire du répertoire contrib mais ceci peut être dangereux et n'est pas recommandé à moins que vous ne sachiez ce que vous faites.
Guardian est accessible et fait partie du répertoire contrib dans l'archive de distribution.
Guardian est un script perl qui utilise snort pour détecter les attaques, et alors utilise IPchains pour refuser toute attaque supplémentaire.
La page web de Guardian peut être trouvée sur :
http://www.chaotic.org/ astevens/Guardian/index.html
ou vous pouvez utiliser le miroir,
http://www.cyberwizards.com/ midnite/Guardian/index.html
Mais une mise en garde... exécuter des binaires externes peut également être un limitateur de performance et vous devriez lire avec attention ce qui suit...
Christopher Cramer wrote: > > Je suis sûr que ceci a été mentionné avant dans des discussions > similaires, mais ceci semble une très mauvaise idée. Que se passe t-il > si le vilain réalise ce qui se passe et utilise votre méthode de > bloquage comme attaque en déni de service. N'importe qui pourrait > commencer à envoyer une série de paquets déclenchant avec des adresses > IP spoofées. > > Puisque je ne suis plus intéressé à pénétrer dans votre site, mais > plutôt à rendre votre vie un enfer, je ne me soucie pas des données > résultat me revenant. Tout ce que j'ai à faire est de commencer à > entreprendre une liste d'adresses IP que je pense que vous ne devriez > plus être capables de parler avec. Quand vous revenez le lendemain > matin, vous trouvez que vous ne pouvez plus accéder au monde extérieur. > > Juste mes 0,02 $ . >
Si vous n'exécutez pas snort sur un noyau linux 2.1.x/2.2.x (avec LPF accessible) la seule façon est d'exécuter plusieurs instances de snort, une instance par interface. Toutefois, pour linux 2.1.x/2.2.x et plus, vous pouvez utiliser la bibliothèque libpcap avec le patch de S. Krahmer qui vous permet de spécifier 'any' comme nom d'interface. Dans ce cas snort sera capable de traiter le trafic venant de toutes les interfaces.
Vous utilisez une ancienne version de libpcap avec un noyau linux récent. Il ne devrait pas y avoir de problème avec cela tant que votre noyau supporte les sockets de type SOCK_PACKET. Toute fois pour éliminer ce message, vous devrez mettre à jour vers une version récente de libpcap. (une copie de www.tcpdump.org est recommandée).
Oui. Avec snort 1.7 et supérieurs, la variable <interface>_ADDRESS est accessible. La valeur de cette variable sera toujours à l'adresse IP/netmask de l'interface sur laquelle vous exécutez snort. Si l'interface tombe et remonte (et une adresse IP est réassignée) vous devrez redémarrer snort. Pour les versions précédentes de snort nombre de scripts pour atteindre le même résultat sont accessibles.
C'est parce qu'il y a un autre programme s'exécutant qui utilise le service DLPI. L'implémentation HP-UX n'autorise pas plus d'un programme libpcap à la fois, contrairement à Linux (de snort.c)
Vous pouvez tomber à cours d'inodes libres, ce qui typiquement signifie également que vous ne pouvez plus créer de fichiers sur la partition. La solution évidente est d'en effacer quelques uns ;-)
Quelques erreurs communes sont :
ERROR somefile.rules:yy => Port value missing in rule!
ERROR somefile.rules:yy => Bad port number: "(msg:"blah"
ERROR somefile.rules:yy => Couldn't resolve hostname blah
somefile.rules est le fichier où l'erreur de syntaxe est parvenue, et yy est le numéro de ligne où elle est parvenue. Il y a deux possibilités :
Ces messgaes sont produits par le préprocesseur http_decode. Si vous souhaitez désactiver ces vérifications, ajoutez respectivement -unicode et -cginull à la ligne du préprocesseur http_decode.
preprocessor http_decode: 80 8080 -unicode -cginull
ERROR: OpenPcap() device open:
Error opening adapter
Soit winpcap n'est pas installé, ou vous utilisez une version incompatible. Essayez de mettre à jour vers la dernière version (2.1 au 2001/04/11). Il est disponible depuis http://netgroup-serv.polito.it/winpcap/
Vous devez changer la facilité output à 'alert' plutôt que 'log'. Le préprocesseur de scans appelle les plugins de sortie enregistrés en tant que des plugins 'alert' plutôt que 'log'.
output database: alert, mysql, user=snort dbname=snort host=localhost
Marty a répondu à cela de nombreuses fois sur la liste snort-users. Voici un extrait de sont message du 22 février 2001 nommé "Re: [Snort-users] order of evaluation of rules".
(note du traducteur : cf faq originale pour les schémas et les explications en anglais ;-) ou http://www.geocrawler.com/archives/3/4890/2001/2/200/5205182/ pour l'archive du message en question.)
Donc, voici la version courte de comment cela fonctionne, une question ?
Vous avez besoin d'installer WinPcap. Il est disponible ici.