Beber l'ARGUSnaute NOTE : la rédaction initiale de cet article est bien antérieure à la publication de la brève chez HSC. Son copyright original date de 2001. Outre les utilitaires classiques de logging comme syslog, il existe un outil pouvant s'avérer grandement utile dans la surveillance et l'audit d'un réseau et de son trafic. Il s'agit d'ARGUS, l'Audit Record Generation and Utilization System, programme composé d'un serveur se basant sur TCPdump et la libpcap pour capturer tout le trafic passant par une interface réseau ; ainsi que d'un client appelé 'ra' (pour read argus), décliné, grâce à une API simple, en une multitude de clients spécifiques, permettant tous de récupérer les données collectées par le serveur Argus pour les afficher et les trier. Installez Argus et ses clients ra* depuis le système de package habituel de votre OS, ou bien récupérez directement les sources d'Argus depuis http://www.qosient.com/argus/. Les dernières versions supportent Linux, {Free,Net,Open}BSD, Solaris et MacOS X, ainsi que, pour les clients uniquement, Cygwin. Vérifier tout de même la présence de la libpcap pour pouvoir utiliser des BPF, ainsi que à du support BPF via la libpcap, ainsi qu'à autoriser l'ouverture de ports privilégiés sur la machine hôte (Argus server). La configuration s'effectuera ensuite par l'intermédiaire du fichier argus.conf situé dans /etc. Notez que la majorité de ces options peuvent également être paramétrées depuis la ligne de commande et placées dans le script de démarrage (un exemple est contenu dans l'archive) à placer dans /usr/local/etc/rc.d, remplaçant ainsi un argus -F /etc/argus.conf spécifiant le fichier de configuration. Comme les options spécifiées par argus.conf surpasse celles de la ligne de commande lorsque vous utiliserez l'option -F, n'y mettez que les options les plus indispensables dont vous vous servirez toujours. # vi /etc/argus.conf ------------------------------------ SNiP ------------------------------------- # lancer Argus en tant que daemon # pour le lancer au démarrage, voyez l'exemple dans /support/Startup/argus ARGUS_DAEMON=yes # écrire le PID d'Argus pour en faciliter la gestion # kill -9 'cat /var/run/argus.*.*.pid' ARGUS_SET_PID=yes # spécifie une identificateur sur 32 bits # utile si vous gérez plusieurs capteurs ARGUS_MONITOR_ID=`hostname -a` # spécifie le port TCP et l'IP d'écoute d'Argus # mettre le port à 0 désactive l'écoute # permettant ainsi de lire les résultats localement depuis les logs Argus # ARGUS_ACCESS_PORT=561 # ARGUS_BIND_IP=127.0.0.1 # interface de capture d'Argus # ARGUS_INTERFACE=ed0 # passage en mode promiscuous # sinon Argus ne verra que les paquets partant ou destinés à son hôte ARGUS_GO_PROMISCUOUS=yes # vous pouvez spécifier jusqu'à 5 fichier log concurrents # les données allant dans chaque fichiers peuvent être filtreés par des # expressions BPF : # ARGUS_OUTPUT_FILE=/var/log/argus/webserver.log host 'webserver' & tcp port 80 # ARGUS_OUTPUT_FILE=/var/log/argus.log # générer des Round-Trip Time Measurement # afficher les adresses MAC # afficher les performances (e.g. taux de rejet) à la fin de chaque session # et capturer une partie du payload (comme tcpdump -x 'snaplen') ARGUS_GENERATE_RESPONSE_TIME_DATA=yes ARGUS_GENERATE_MAC_DATA=yes ARGUS_GENERATE_JITTER_DATA=yes # ARGUS_CAPTURE_DATA_LEN=256 # intervalle de génération d'un rapport sur un flux, en secondes ARGUS_FLOW_STATUS_INTERVAL=30 # même chose pour les rapports de statut d'Argus ARGUS_MAR_STATUS_INTERVAL=300 # utilisation de l'optimisation de filtres proposée par libpcap ARGUS_FILTER_OPTIMIZER=yes # vous pouvez spécifier jusqu'à 2ko d'expressions BPF # le triage est cependant plus intéressant à faire depuis les clients ra* ARGUS_FILTER="" ------------------------------------ SNiP ------------------------------------- Pour Argus, comme pour les clients ra* que nous étudierons ensuite, quasiment toutes les options des fichiers de configuration peuvent être modifiées à chaque exécution en spécifiant des options sur la ligne de commande. Par exemple, -B permet de spécifier l'adresser IP d'écoute, -d permet de lancer Argus en tant que daemon, -e indique l'identificateur, -i permet d'indiquer l'interface de capture, -p interdit le passage en mode promiscuous, ou encore -U spécifie la longueur des données du payload à afficher. Plus particulièrement, -P permet de spécifier le port d'écoute. Si vous capturez (avec Argus) et afficher (avec ra*) les données sur la même machine, désactivez l'écoute, indiquez à Argus d'écrire directement sur la sortie standard (stdout) avec l'option -w, puis utilisez un simple pipe : # argus -i ed0 -F /etc/argus.conf -U 0 -w - | \ ra -r - host De la même manière, -r ordonne - pour Argus comme pour ra* - de lire les données à partir d'un fichier de log. Pour Argus, ce fichier pourra être au format TCPdump ou snoop. Avant d'étudier l'utilisation des différents clients ra*, nous avons la possibilité de préciser certaines options communes à travers le fichier .rarc que vous trouverez dans votre /home. Comme pour Argus, -f permet de spécifier le .rarc à utiliser pour ra* et, toujours comme pour Argus, chaque option spécifiée à l'intérieur surpasse celles de la ligne de commande. ------------------------------------ SNiP ------------------------------------- # localisation du serveur argus (hostname ou IP) RA_ARGUS_SERVER=localhost RA_ARGUS_SERVERPORT=561 # les clients ra* sont capables de lire le Cisco NetFlow Export Data Format # > http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/nfc_3_0/nfc_ug/nfcform.htm#18955 # RA_CISCONETFLOW_SERVER=no # spécifie la sortie # ici, nous utilisons la sortie standards RA_OUTPUT_FILE="-" # délimiteur de champ pour la sortie ASCII # ici, n'écrivez pas [tab], tapez-le RA_FIELD_DELIMITER='[tab]' # afficher un résumé à la fin de la session RA_PRINT_SUMMARY=yes # contrepartie à ARGUS_MONITOR_ID, permet de distinguer plusieurs sources RA_PRINT_ARGUSID=yes # affichier les adresses MAC RA_PRINT_MACADDRS=yes # afficher des données supplémentaires comme les états du protocole RA_PRINT_INDICATORS=yes # afficher le nombre de paquets et d'octets RA_PRINT_COUNTS=yes # afficher les données répondues si le protocole permet de les identifier RA_PRINT_RESPONSE_DATA=no # afficher les payload en ASCII ou en Encode64 RA_USERDATA_ENCODE=ASCII # ra* supporte la précision d'un espace de temps pour les entrées à récupérer # sous la forme timespace-timespace avec timespace = yy/mm/dd.hh:mm:ss # RA_TIMERANGE="" # durée d'exécution de ra* en secondes. 0 signifie indéfiniment RA_RUN_TIME=300 # afficher la durée totale de la session RA_PRINT_DURATION=yes # spécifier le format temps RA_TIME_FORMAT="%T %d/%m/%y" # options liées à l'utilisation de l'authentification SASL # RA_USER_AUTH="user_id/authorization_id" # RA_AUTH_PASS="password" # champ similaire à ARGUS_FILTER dans argus.conf RA_FILTER="" ------------------------------------ SNiP ------------------------------------- Le format des commandes ra* est toujours 'ra [ra options][expr BPF]'. La ligne de commande offre quelques fonctionnalités et une précision accrue. Par exemple, pour préciser la longueur exacte données que nous voulons voir affichée, nous pouvons utiliser l'option -d de cette manière : # ra -d s20:d48 dst 192.168.0.1 avec N la longueur des données pour la source (sN) et la destination (dN). Un simple chiffre (sans s ni d) indique d'afficher autant de données pour la source et la destination. Ou encore lorsque nous utilisons des filtres ra ou des expressions BPF, toutes les données collectées ne correspondant à aucun filtre peuvent être redirigées vers un fichier à l'aide de l'option -E 'filename'. Dans le même ordre d'idée, nous avons l'option -w 'filename' écrivant toutes les données matchées dans un fichier. Enfin, comme nous l'avons vu précédemment, en remplaçant filename par stdout ('-'), nous avons la possibilité de chaîner des commandes Argus et ra* (même entre elles) avec des pipes. Pour le temps, nous avons l'option -G inscrivant les temps de début et de fin de la session de capture. Ou bien l'option permettant de spécifier un espace de temps avec le même format qu'expliqué dans .rarc. Par exemple pour voir les données capturées durant la nuit (utile chaque matin pour les administrateurs). # ra -G -t 2001/11/14.18:00:00-2001/11/15-09:00:00 Si nous désirons récupérer les données venant d'un daemon Argus distant, -S et -P permettent d'indiquer respectivement l'adresse et le port d'écoute du daemon. Si -P n'est pas spécifié, le défaut est 561/tcp. Mais vous pouvez également directement lire les données transmises par Cisco NetFlow. Sur votre routeur Cisco, il faudra entrer la ligne suivante : router(config)#ip flow-export [version ] En remplaçant et par l'adresse et le port d'écoute du client ra*. Pour indiquer à celui-ci que nous souhaitons recevoir des données NetFlow, il faudra lui adjoindre l'option -C. Le port d'écoute par défaut est alors 9995/udp. Avec la présence de l'option -C, l'option -P permet alors de modifier ce numéro de port. Comme nous l'avons déjà dit, ra supporte en plus d'une série d'options, des expressions BPF telles que décrites dans les manuels de tcpdump et de ra. Mais ra* supporte également une série d'expressions supplémentaires directement issues de son comportement face au trafic. En effet, Argus considère les transmissions comme des flux soit 'connection-oriented' comme TCP et se sert alors des flags et numéros de séquence pour identifier les différents états, soit 'connection-less' comme UDP et ICMP pour lesquels il vérifie simplement la présence du couple requête/réponse dans un laps de temps fini, au bout duquel le suivi du flux est considéré comme ayant expiré si il n'y a pas eu de nouvel échange. Un échange régulier entre les 2 hôtes dans un flux connection-less est considéré comme un keep-alive et le flux est dit persistant. Nous disposons ainsi, pour sélectionner un état précis une fois la connexion établie, des expressions 'normal', 'wait', 'timeout' ainsi que 'est' ou 'con'. De même, nous pouvons utiliser 'frag' ou 'fragonly' pour enregistrer tout flux ayant généré des fragments IP. Une expression très intéressante est 'multipath' qui permet de rechercher et afficher les flux dont les pairs d'adresses MAC, du point de vue local d’Argus, ont changé durant la connexion, indiquant que les données empruntent différents chemins. Ce peut également être un indice de spoofing. Ensuite viennent les expressions spécifiques aux flux TCP c'est-à-dire 'syn' (SYN sent), 'synack' (SYN received), 'data' (etablished), 'ecn' (CE codepoint), 'fin' (FIN-WAIT-1), 'finack' (FIN-WAIT-2), 'reset' (RST), 'retrans' (Sack) et 'winshut' (window shutdown) correspondant à divers états de la connexion. Suivent les primitives ICMP avec 'echo' (type 0/8), 'unreach' (type 3), 'redirection' (type 5) et 'timexed' (type 11). Notez que pour les expressions 'frag', 'reset', 'retrans' et 'winshut', il est nécessaire de préciser une direction. Le format de sortie de ra est alors le suivant : time proto [mac] src.host dir dst.host [count] status ‘time’ indique, par défaut, le temps de début et de fin de la transaction. ‘proto’ est, quant à lui, un champ divisé en 2 parties renseignant sur le protocole utilisé. La première indique des options spécifiques au protocole. Ces indications sont les suivantes (tirées de la man page) : m - MPLS encapsulated flow q - 802.1Q encapsulated flow p - PPP over Enternet encapsulated flow E - Multiple encapsulations/tags s - Src TCP packet retransmissions (retrans) d - Dst TCP packet retransmissions (retrans) * - Both Src and Dst TCP retransmissions (retrans) S - Src TCP Window Closure (winshut) D - Dst TCP Window Closure (winshut) @ - Both Src and Dst Window Closure (winshut) M - Multiple physical layer paths I - ICMP event mapped to this flow F - Fragments seen (frag) f - Partial Fragment (frag) V - Fragment overlap seen (frag) S - IP option Strict Source Route L - IP option Loose Source Route T - IP option Time Stamp + - IP option Security R - IP option Record Route N - IP option SATNET O - multiple IP options set Le second champ désigne le protocole IP effectivement utilisé pour ce flux. Argus reconnaît actuellement les protocoles TCP, UDP, ESP, ICMP, IGMP, RTP et RTCP. L'option -nn vous permet de forcer l’affichage des adresses et des numéros de protocole sous forme numérique, évitant d’avoir à résoudre des noms de domaine ou de mal considérer un flux en faisant confiance à /etc/services. ‘mac’ n'est affiché que si ra est invoqué avec l'option -m et permet d'afficher les adresses MAC. Avec le .rarc définit plus haut, nous n'avons pas besoin de l'option -m, les adresses MAC seront toujours affichées. 'src.host' et 'dst.host' sont les adresses ou hostnames de la source et du destinataire. Les adresses MAC et les champs 'src.host' et 'dst.host' sont couplés. 'dir' indique la direction du flux à l'aide des flèches < et >. Pour TCP, ce champ donne également des informations sur l'état de la transmission en ajoutant les symboles '-' si la transaction a été normale, '|' si elle a été interrompue (reset) et 'o' si elle a expiré. '?' indique enfin que le sens de la transaction est inconnu. ‘count’ est optionnel, affiché avec l'option -c mais par défaut affiché par notre .rarc comme pour les adresses MAC. Comme le champ optionnel MAC, il est couplé de manière respective avec src.host et dst.host. Il est composé de 2 champs : le premier indique le nombre de paquets et le second indique le nombre d'octets. Enfin vient le champ ‘status’ spécifiant comme son nom l'indique le statut du flux. Toutes les transactions sont classés selon un schéma établissant les différents statuts, présentés ci-dessous : - REQ|INT, requested pour TCP et initial pour UDP, indique qu'une connexion est demandée - ACC pour accepted, signifie qu'il y a eu réponse à la requête précédente. Pour TCP, ceci correspond à un SYN|ACK ; pour les protocoles connection-less, cela veut dire qu'une paire de paquets à été échangé. - EST|CON, established pour TCP et connected pour UDP, signifie que la connexion est établie et active. - CLO, pour closed, indique la fermeture normale d'une connexion TCP uniquement à travers un 4-way-handshake-close. - TIM, pour timeout, signifie que Argus n'a pas vu d'activité pour ce flux avant la limite de temps indiquant un timeout pour ce protocole. En clair, il n'a vu aucun keep-alive. Argus dispose également d'une notation spécifique au protocole ICMP. Par ailleurs, pour certains types de messages ICMP, l'option -I à l'invocation de ra permet d'obtenir des informations supplémentaires. La notation et les informations sont les suivantes : ECO echo request ECR echo reply URF unreachable need fragmentation URH unreachable host URN unreachable network URO unreachable protocol URP unreachable port URS unreachable source failed SRC source quench RED redirect TIM time exceeded PAR parameter problem TST timestamp request TSR timestamp reply IRQ information request IRR information reply MAS mask request MSR mask reply Il faut savoir enfin qu'Argus possède une multitude de clients avec des buts différents et qu'il est très simple d'en écrire soi-même pour un usage nouveau grâce à un format de fichier argus simple et documenté. Il existe actuellement comme clients supplémentaires racount, rasort, ramon et raxml. Racount simplifie les opérations de comptages et statistiques. Il vous suffit d'invoquer racount avec par exemple l'option -a pour une sortie détaillée avec un comptage explicite des données par paquets et octets. Par ailleurs, comme l'ensemble des clients ra*, racount supporte les filtres ra* décrits plus haut. Nous avons ensuite rasort qui permet de sortir les entrées Argus selon différents critères invoqués avec l'option -s. Ces critères sont les suivant : startime record start time (sortie par défaut) lasttime record last time. duration record duration. srcaddr source IP addr. dstaddr destination IP addr. proto transaction protocol. sport source port number. dport destination port number. stos source TOS byte value. dtos destination TOS byte value. sttl src -> dst TTL value. dttl dst -> src TTL value. bytes total transaction bytes. srcbytes src -> dst transaction bytes. dstbytes dst -> src transaction bytes. packets total transaction packet count. srcpackets src -> dst packet count. dstpackets dst -> src packet count. Une priorité entre ces critères peut être définie en les enchaînant avec plusieurs options -s. Ainsi, pour sortir les données par protocole puis, par durée, entrez la commande suivante : # rasort -s proto -s duration Nous disposons également de ramon qui offre un rapport des données dans le style du protocole RMON2 d'administration réseau. Ramon dispose donc de plusieurs mode d'affichage à utiliser avec l'option -M. TopN présente ainsi la liste des plus gros consommateurs de bande passante du réseau et Matrix propose une liste similaire mais par paire d'hôte. Vous pouvez également découvrir la liste des protocoles utilisés par chaque adresse avec HostProto, ainsi que des services (basée sur les numéros de port) avec HostSvc (ou Svc pour un liste absolue). Pour indiquer le nombre de machine que vous voulez prendre en compte, c'est-à-dire la taille de vos listes, utilisez -N suivi du nombre désiré. Toutes ces options fournissent également la comptabilité en termes de paquets et d'octets. Si vous êtes sur une passerelle, triez plutôt par réseau avec -M Net suivi éventuellement d'un masque de sous-réseau en notation CIDR. Enfin, avec -a, vous pouvez choisir d'ignorer les filtres appliqués via .rarc afin d'obtenir la totalité des sources ayant servies à la comptabilité. Avant de créer une politique de traffic shaping, utiliser ramon de la façon suivante : # ramon -S 127.0.0.1 -M TopN -N 25 host En remplaçant par le réseau accueillant vos principaux serveurs. Vous pourrez ainsi voir qui consomme le plus, donc qui a le plus besoin de bande passante, ainsi qu'identifier les parasites pour une investigation plus approfondie (par exemple pour détecter des transmissions TCP long-living ou dénotant des problèmes de window). Dans le même type d'outil simple mais diablement utile, vous trouverez ragraph. Celui-ci se base sur les RRD-tools permettant de créer facilement des bases de données à partir de captures issues du réseau, afin de créer des graphiques illustrant l'utilisation de celui-ci. Le plus fameux exemple est MRTG dont il existe une version modifiée pour exploiter la puissance de RRD. Ragraph vous permettra ainsi de choisir votre fichier de sortie .gif avec -w, la base de temps avec -M suivi d'une fréquence - en secondes, minutes, heures, jours, mois et années - ainsi qu'une multitude de petites options d'affichage, tel l'utilisation d'une échelle semi-log avec l'option -log. Bien plus encore dans le manuel atenant. Tout aussi utile que ramon pour la création de politique, mais de filtrage cette fois. Les récents raclients comptent parmis eux rapolicy dont le but est d'indiquer toutes violations d'une ACL Cisco prise en argument avec l'option -f. En installant un capteur Argus derrière l'un de vos routeurs/firewalls, vous avez ainsi la possibilité de vérifier si un trafic illégitime passe quand même afin d'adapter votre politique. Rapolicy propose quelques options spécifiques avec le switch -D. S'il est suivi d'un zéro (valeur par défaut quand -D n'est pas précisé), rapolicy affiche les flux qui violent l'ACL ; s'il est à 1, les flux qui violent l'ACL ainsi que les règles violées ; et enfin, s'il est à 2, ce sont tous les flux accompagnés des règles qu'ils ont déclenchées qui sont affichés. Supposons que vous souhaitiez empêcher l'accès à un serveur ftp interne depuis l'extérieur, mais vous interrogez quant à l'impact d'un tel filtre. Ou même, après avoir utilisé ramon, vous vous êtes rendu compte de quantité d'un tel trafic illégitime. Dans ces deux cas, rapolicy est la solution. Executez-le selon la syntaxe suivante : # rapolicy -S 127.0.0.1 -D 1 -f ftp.policy Avec un contenu de ftp.policy similaire à : access-list 101 permit tcp 0.0.0.0 eq 21 access-list 101 deny tcp any any Il ne reste plus qu'à constater les violations ou au contraire l'efficacité du filtre. Vous pourriez utiliser une expression BPF du type 'gateway ' pour n'obtenir que les violations par des flux traversant le routeur/firewall. Nous avons évoqué la simplicité du développement de nouveaux clients ra* Nous allons l'illustrer par rapreluce, un petit client dont le but est d'enregistrer les résultats d'une commande ra* auprès d'un manager d'un IDS Prelude. Ce dernier peut être local ou distant. Dans ce dernier cas, raprelude utilise libprelude qui permet de gérer ces connexions de façon complètement transparente et d'y ajouter un chiffrement SSL pour les accès distants. L'adresse du manager est spécifiée dans le fichier prelude.conf livré avec l'IDS lui-même. La partie qui nous intéresse est la ligne suivante : manager-addr = 127.0.0.1 Vous pouvez spécifier un :port et même utiliser des opérateurs logiques || et && pour vous utiliser des managers de secours. Enfin, Prelude utilise, pour un maximum d'interoperabilité, le format IDMEF pour ses alertes, tel que défini par l'Intrusion Detection Working Group de l'IETF (voir http://www.ietf.org/html.charters/idwg-charter.html). Puisque raprelude permet de loguer dans une base de données IDMEF, nous devons renseigner un maximum de champs IDMEF pour rendre l'alerte utile à l'administrateur. Cette opération s'effectue à l'aide du switch -I suivi du champ IDMEF et de sa valeur. Les champs supportés sont les suivants (d'après raprelude(1)) : IDMEF_STRING = [IDMEF_ENTRY]+ IDMEF_ENTRY = CLASS_NAME | CLASS_URL | CLASS_ORIGIN | IMPACT_TYPE | IMPACT_DESCR | IMPACT_COMPL | IMPACT_SEVER | CONF_RATING CLASS_NAME = IClassName=Name of this Class of Attacks; CLASS_URL = IClassURL=URL of Description; CLASS_ORIGIN = IClassOriging=[unknown | bugtraqid | cve | vendor\-specific]; IMPACT_TYPE = IImpactType=[admin | dos | file | recon | user | other]; IMPACT_DESCR = IImpactDescription=Describing Text; IMPACT_COMPL = IImpactCompletion=[failed | succeeded]; IMPACT_SEVER = IImpactSeverity=[low | medium | high]; CONF_RATING = IConfidenceRating=[low | medium | high]; L'exemple typique, donné par l'auteur, est la combinaison de raprelude et de rapolicy (auquel il a participé). En les liant par un pipe, on peut transformer Argus en senseur Prelude, comme dans l'exemple suivant : # rapolicy -S 127.0.0.1 -w - -f acl.policy | \ raprelude -I "IClassName=Access Control Violation;" -f prelude.conf On pourrait aller plus loin : en lancant plusieurs instances du même type, mais avec des fichiers policy différents permettant de distinguer des types de trafic ou les routeurs/firewalls concernés, il serait possible d'affiner les champs IDMEF, en particulier le type, la description et la sévérité. D'autre part, l'utilisation de la primitive ra* multipath ou de rarpwatch pourrait fournir des informations similaires au plugin ArpSpoof de prelude-nids. Le problème sera alors simplement d'obtenir une commande qui se termine pour pouvoir en utiliser la sortie. Il suffit, dans un shellscript, de limiter le temps d'exécution avec -T, puis de traiter la sortie dans un log sur lequel on recherchera une chaîne de caractère donnée, en la présence de laquelle on appelera raprelude. A la fin de ce cycle, on relance la première commande ra pour un nouveau cycle. Vous trouverez ce client et quelques informations supplémentaires, notamment quant à son installation à http://www.intrusion-lab.net/tools/raprelude/. Notre dernier client sera raxml qui permet de sortir les données collectées par Argus sous forme de document XML sur stdout. Vous pouvez préciser dans quel format les données capturées seront affichées à l'aide de l'option -e suivi de Ascii ou Encode64. N'oubliez pas qu'absolument tous les clients ra* supportent les expressions BPF et les primitives ra* pour affiner leur utilisation. Nous avons vu que par son support des expressions BPF et par son approche du trafic en termes de flux, Argus et ses multiples clients ra* peuvent offrir une quantité colossale d'informations sur l'activité du réseau et permettre, par exemple, de corriger des règles de filtrages après l'apparition de flux indésirables ou bien suspecter un quelconque spoofing pour les flux correspondant à un filtre multipath. Argus peut, par ailleurs, s'avérer extrêmement intéressant dans le cadre d'une analyse post-mortem suivant une intrusion sur l'une des machines du réseau. La simplicité d'Argus pour synthétiser et afficher le trafic de manière lisible via ses multiples clients en font un excellent outil de forensic. Laissez donc Argus fonctionner sur une machine qui enregistrera sur des disques durs volumineux la totalité du trafic ou, au moins, la partie la plus sensible. En cas d'intrusion, il vous suffira alors d'utiliser les clients ra* pour retrouver de nombreux détails de la session ayant conduit à un tel désastre. Il faudra alors savoir quoi chercher. Luca Deri, l'auteur de Ntop a produit sur ce sujet un article (http://luca.ntop.org/ADS.pdf) intéressant concernant l'utilisation des outils d'analyse réseau (en l'occurence Ntop) dans le cadre de la détection d'intrusion anomaly-based. Il a ainsi décrit plusieurs types de vulnérabilités détectables par une simple analyse du trafic. Les paquets forgés pourraient ainsi être en partie détectés en recherchant dans le trafic les paquets dont les adresses source et destination sont les mêmes, ou dont les adresses sont théoriquement réservées et/ou non-routable - ce dernier cas de figure est cependant supposé avoir être empêché par un filtrage 'ingress' efficace. En connaissant votre réseau, de simples expressions BPF permettent de détecter ces cas basiques d'usurpation avec ARGUS, comme dans les exemples ci-dessous pour un réseau imaginaire 192.168.1.0/8. # ra -G - nn -z src host 192.168.1.42 and gateway 192.168.1.1 De même, les paquets de taille trop importante (Ping of Death) peuvent être detectés avec l'opérateur logique 'greater' de BPF ou avec rasort, ou bien les paquets contenant des combinaisons de flags TCP avec une expression BPF classique. Grâce à la capacité d'ARGUS de suivre les connexions, vous pourriez également repérer au sein d'un flux des paquets out-of-sequence qui peuvent indiquer une tentative de hijacking. Cette fonctionnalité, appliquée à IP, permet de surveiller la création de fragments et de voir s'ils sont trop nombreux ou eux aussi out-of-sequence, signes de DoS par exemple. La liste est longue, et pourtant non exhaustive, des attaques aisément détectables par un analyste, cette détection pouvant même être simplifiée et automatisée par quelques scripts. La détection de nouvelle connexion est ainsi facilité en utilisant rapolicy pour faire apparaître celles qui sont illégales d'après la politique de sécurité locale. La surveillance des attaques sur la couche liaison est également possible puisque ARGUS peu isoler les trames 802.1Q, MPLS ou ARP/RARP, et reporter les adresses MAC des trames ethernet interceptées. 'multipath' peu alors servir à détecter facilement des tentatives de spoofing ou de cache poisoning. Racount et rasort peuvent quant à eux offrir des statistques intéressantes pour détecter une augmentation anormale du trafic, indiquant un DoS en cours. De même, eu surveillant les transmission 'broadcast' avec des expressions BPF, vous pouvez détecter des attaques de type smurf. Les man pages d'ARGUS et de tcpdump fournissent plusieurs exemples d'utilisation des expressions BPF. N'hésitez pas à télécharger les dernières versions beta des clients ra* pour découvrir et tester ceux qui ne sont pas documentés ou bien recèlent encore quelques erreurs. Vous trouverez ainsi rarpwatch qui permet de suivre les paires d'adresses IP/MAC afin de détecter conflits et usurpations ; raseq qui détecte les numéro de séquence manquant dans une transmission TCP ; rapath qui détermine le chemin complet d'un flux sur le lien local et permet même de le dessiner en SVG, etc. Vous pourrez enfin lire avec avidité ratemplate qui vous guidera pour développer vos propres clients ra*.