HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Argus
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Argus  

by Yann Berthier (15/02/2002)




	--[ A R G U S ]--

Argus (Audit Record Generation and Utilisation System) est un outil permettant
de faire de l'audit de réseau IP.

Argus peut être utilisé selon deux modes :

o analyse à partir d'une trace réseau existante pour en dégager des flux
'anormaux'
o déploiement de sondes argus qui enregistrent le trafic, et exploitation des
données générées.

Les informations générées par Argus permettent notamment : 

o de diagnostiquer des problèmes réseau, par exemple de performances.
o d'aider à faire de la sécurité sur ses réseaux - c'est sous cet aspect que
nous allons présenter Argus. 


	--[ Installation de Argus ]--

Argus est disponible à l'URL suivante : http://qosient.com/argus/

L'installation est standard et ne devrait pas poser de problème particulier :
./configure && make && sudo make install

Mais comme on dit, votre kilométrage peut varier.


	--[ Fonctionnement de Argus ]--

Argus est composé de plusieurs programmes, dont le fonctionnement est
contrôlable par des fichiers de configuration et / ou par des options en ligne
de commande :

o le programme argus lit du trafic réseau (en écoutant sur le réseau, ou en
relisant une trace au format tcpdump ou snoop) et génère des informations sur
les flux au format argus(8), soit sur le réseau, soit dans un fichier. 5
sorties différentes peuvent être précisées.

o les programmes ra* prennent en entrée des données au format argus, soit via
le réseau, soit en relisant un fichier au format argus, et produisent une
sortie au format ASCII.

Il est enfin possible de spécifier des filtres de type bpf¹ pour chacun des
programmes composant argus.


¹ bien que la syntaxe soit celle de bpf(4), des expressions propres à argus
sont disponibles pour faire des filtres sur les flux générés. 


argus
-----

Les principales options de argus : 

-d : met argus en mode 'démon'
-r <fichier> : pour qu'argus relise une trace générée par tcpdump / snoop
-i <interface> : pour spécifier l'interface sur laquelle argus écoute
-w <fichier> : pour enregistrer la sortie d'argus dans un fichier
-P <port> : pour qu'argus écoute sur le port TCP <port>

Quand l'option -P est utilisée, argus supporte TCP-Wrappers pour le contrôle
d'accès, et SASL pour l'authentification - le support de SASL doit cependant
être précisé au moment de la compilation.


ra*
---

Options communes aux programmes ra* :

-r : pour lire une trace au format argus
-S <serveur> : pour spécifier un serveur argus et lire les données de ce
serveur
-P : pour spécifier le port du serveur argus
-F <fichier> : pour spécifier un fichier de configuration
-a : pour afficher un résumé par protocole à la fin de la sortie générée 
-c : pour afficher le nombre de paquets et le nombre d'octets d'un flux
-g : pour afficher la durée d'un flux
-n : pour supprimer la résolution dns
-p <nombre> : fixe le nombre de décimales pour les dates à <nombre>
-m : pour afficher les adresses MAC
-w <fichier> : pour envoyer la sortie de ra* dans un fichier (par défaut la
sortie se fait sur la sortie standard)

Il est également possible de spécifier une plage de temps avec l'options -t :
cette possibilité permet par exemple de se concentrer sur les flux quand il n'y
a plus d'utilisateurs sur le réseau, (il est bien connu que le vrai problème en
informatique, ce sont les utilisateurs :-/) et ainsi être à même d'identifier
plus facilement des flux qui n'ont pas lieu d'être.

Par exemple :

-t 02/12 pour les flux du 12 février
-t 14 pour les flux de 14 à 15 h chaque jour
-t 02/07.18 - 02/08.08 pour les flux de 18h le 7 février à 8h le 8 février 


Les principaux programmes ra*
-----------------------------

ra : prend en entrée des données générées par argus et produit une sortie
ASCII. 

ragator : fait de l'aggrégation de flux à partir de données argus(8). Les
possibilités d'aggrégations sont contrôlées via un fichier de configuration
(flowfile) utilisé avec l'option -f <fichier>

Par défaut, ragator regroupe les flux par couples {(saddr, sport),
(daddr,dport)}.  Il est tout à fait possible d'aggréger des réseaux, par
exemple pour regrouper tout les flux 25/TCP vers la dmz des serveurs SMTP.

rasort : trie les données générées (le tri peut être multi-critères), et en
ressort des flux au format argus.

raxml : produit une sortie au format xml.

Les programmes ra* prennent également en entrée des données au format Cisco
Netflow.

Un exemple classique de ligne de commande :

# argus -i ep0 -w - | ra -n -g -c -L 0 - 'ip and src net 192.70.106.0/24'

L'option -L 0 est utilisée pour afficher le nom des colonnes.


	--[ Argus et la gestion des flux ]--

Un des points forts de Argus pour pouvoir mettre en évidence des anomalies sur
un réseau est sa notion de 'flux'.

Pour ICMP, Argus considère les adresses source et destination ainsi que le
type icmp, détaillé dans la sortie de Argus. Par exemple :

    Start_Time      Duration Type     SrcAddr    Sport  Dir       DstAddr  port  SrcPkt   Dstpkt    Response Information    State
14 Feb 02 13:33:39        0  icmp   192.168.3.75       <->     192.168.3.33       1        1         98           98          ECO

indique un flux icmp echo request de 192.168.3.75 vers 192.168.3.33. La colonne
'Dir' ainsi que la colonne 'Dstpkt' indiquent que 192.168.3.33 a bien répondu
avec un paquet echo reply.

Pour UDP, sont considérés les couples (adresse source, port source) et (adresse
destination, port destination) ainsi que l'état de la 'connexion' : 

INT pour indiquer une demande de connexion : un paquet UDP a été envoyé de
l'adresse source vers l'adresse destination.

ACC pour indiquer qu'il y a eu une réponse de la destination :

14 Feb 02 13:44:32        0   udp   192.168.3.75.1493  <->     192.168.2.99.53    1        1         66           121         ACC

Cette trace montre une interrogation DNS de 192.168.3.75 vers 192.168.2.99 et
sa réponse (de 121 octets)

CON pour indiquer qu'il y a une connexion établie avec échange de plusieurs
datagrammes UDP entre la source et la destination. Ici pour une synchronisation
NTP :

14 Feb 02 13:50:46        0   udp   192.168.3.75.123   <->     192.168.3.33.123   4        4         360          360         CON


Pour TCP, les mêmes couples que pour UDP sont bien entendu considérés, mais en
tenant compte également des drapeaux TCP positionnés :

REQ indique une demande de connexion (bit SYN de la source vers la
destination).
EST indique que la session TCP est établie
CLO indique que la session TCP s'est terminée normalement, avec les échanges de
paquets ayant le bit FIN de positionné en fin de connexion.


Ceux qui ont déjà dû éplucher un week end de traces tcpdump pour y trouver les
signes d'une compromission doivent commencer à voir ce que peut leur apporter
Argus.


	--[ Utilisations de Argus ]--

Argus peut trouver de multiples emplois en terme de sécurité.

Le premier est de permettre de synthétiser les flux circulants, pour apprendre
à caractériser son réseau, connaitre les flux légitimes, et ainsi le
cloisonner.

Cette synthèse permet également de mettre en évidence des flux non légitimes et
/ ou des règles de filtrage trop laxistes :

trafic à des heures anormales, par exemple flux irc vers Internet ou nombreuses
requêtes DNS émanant d'une station du réseau la nuit

trafic vers des destinations 'anormales'

trafic présentant des caractéristiques 'anormales', par exemple flux icmp avec
des tailles de paquets importantes

Toutes ces anomalies peuvent être le signe d'une machine compromise.

Il est par ailleurs possible de mettre en évidence des scans lents, notamment
en utilisant ragator :

./ragator -n -G -c -L 0 -R -r /data/trace3.arg

(L'option -G affiche l'heure de début et l'heure de fin du flux)

13 Feb 02 20:01:41  14 Feb 02 09:27:27  icmp      192.168.0.11        ->     172.16.3.33   	85 	0         5610         0           ECO

Ici, 85 datagrammes icmp (echo request) ont été émis par la source, de 20h01 le
13 février à 9h27 le 14 février). La destination n'a répondu à ces paquets.


13 Feb 02 18:47:47  14 Feb 02 09:22:57  icmp      192.168.22.68       <->     172.16.3.25       352      352       34496        34496       ECO

Ici, la destination a bien répondu des echo reply à chacun des echo request
envoyés par 192.168.22.68.


Par ailleurs, plusieurs scripts en perl sont disponibles dans le répertoire
contrib/ des sources Argus pour aider à détecter des scans. 

D'autres scripts ont été écrits pour par exemple détecter des attaques contre
SSH (crc32 compensation attack) dans une trace Argus.


	--[ En guise de conclusion ]--

Quand nous sommes appelés après un incident, nous demandons à notre client de
placer des sniffeurs sur son réseau pour pouvoir disposer d'éventuels traces
d'une compromission (par exemple) à notre arrivée.

Mais c'est hélas souvent trop tard : il nous aurait souvent fallu des traces
datant du début de l'incident pour savoir précisément ce qui s'est passé. Des
sondes Argus déployées sur le réseau auraient permis de disposer de cette
information.

En fait, dans la vraie vie, les choses sont rarement aussi simples qu'un joli
rootkit sur une machine Linux compromise !

Bien souvent, nous sommes appelés après un incident relevé sur le réseau et
nous devons déterminer l'origine du problème :

o intrusion externe
o malveillance interne 
o erreur humaine
o ...

Sans traces réseaux, il est souvent très difficile de :

o déterminer précisément ce qui s'est passé
o le cas échéant confirmer ou infirmer les différentes hypothèses.


Argus n'est là ni pour remplacer un sniffeur tel que tcpdump, ni pour remplacer
un NIDS tel que Snort. 

C'est une autre approche pour faire de la détection d'attaque (détection
d'intrusion pour causer marketing), tout à fait complémentaire de sondes NIDS
'classiques' :

o Argus ne repose pas sur des signatures.
o Argus peut aider à mettre en évidence des faits difficiles à mettre en
évidence avec une sonde NIDS: scans lents ou canaux cachés, par exemple.
o Les flux réseaux enregistrés par les sondes Argus peuvent se réveler cruciaux
pour faire de l'analyse forensique sur le réseau, et pour permettre de
comprendre ce qui s'est réellement passé.


Argus est d'ailleurs utilisé en ce sens, avec des sondes déployées sur des
réseaux à fort trafic.

Il ne reste plus qu'à le tester sur votre réseau ...

$Id: argus_fr.tip,v 1.5 2002/03/04 17:37:27 berthier Exp $



Last modified on 12 November 2003 at 13:55:00 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants