IPFlow : Collecteur Netflow

difficulthopefulΛογισμικό & κατασκευή λογ/κού

2 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

454 εμφανίσεις

Collecteur IPFlow
IPFlow

: Collecteur Netflow
1Introduction
...............................................................................................................................
4
2Architectures supportées
...........................................................................................................
5
3Rappels sur Netflow
..................................................................................................................
5
3.1 Principes
............................................................................................................................
5
3.2 Versions de Netflow
..........................................................................................................
6
4Fichier de configuration et démarrage
......................................................................................
6
5Routeurs
....................................................................................................................................
8
5.1 Paramé trage
.......................................................................................................................
8
5.2 Utilisation d’un «

dispatcher

»
..........................................................................................
9
5.3 Renommage des interfaces
..............................................................................................
11
6Service de dispatching
.............................................................................................................
12
7Sites
.........................................................................................................................................
14
7.1 Notion de site
..................................................................................................................
14
7.2 Exemple pratique
............................................................................................................
14
7.3 Gestion des sous-réseaux
................................................................................................
15
7.4 Sites particuliers
..............................................................................................................
15
7.5 Configuration
..................................................................................................................
16
8Règles d’analyse (Rules)
.........................................................................................................
17
8.1 Actions possibles
.............................................................................................................
17
8.1.1Colorisation des flux
.................................................................................................
17
8.1.2Matrice de trafic de sites
...........................................................................................
17
8.1.3Agré gation
.................................................................................................................
18
8.1.4Logging
.....................................................................................................................
18
8.1.5Détection de scans de port
.........................................................................................
18
8.1.6Ré é criture d’adresses
................................................................................................
18
8.1.7Evaluation des termes
...............................................................................................
19
8.2 Spé cification des rè gles
...................................................................................................
19
8.3 Configuration
..................................................................................................................
21
9Access-Lists
............................................................................................................................
22
9.1 Evaluation
.......................................................................................................................
22
9.2 Description des critè res
...................................................................................................
22
9.2.1Protocole IP
...............................................................................................................
22
9.2.2Adresses IPv4 source et destination
..........................................................................
23
9.2.3Adresses IPv6 source et destination
..........................................................................
23
9.2.4Champ TOS
...............................................................................................................
23
9.2.5Flags TCP
..................................................................................................................
23
9.2.6Ports source et destination
.........................................................................................
24
9.2.7AS source et destination
............................................................................................
24
9.2.8Duré e
.........................................................................................................................
24
9.2.9Nombre de paquets et d’octets
..................................................................................
25
9.3 Optimisation
....................................................................................................................
25
9.4 Configuration
..................................................................................................................
26
10Channels
................................................................................................................................
27
10.1 Fichiers binaires et textes
..............................................................................................
27
Christophe Fillot -
06/10/2005
1
/
86
Collecteur IPFlow
10.1.1Fichiers textes
.........................................................................................................
27
10.1.2Fichiers binaires
......................................................................................................
27
10.1.3Fichiers «

Matrices de Trafic de Sites

»
..................................................................
29
10.2 Logging dans un fichier
................................................................................................
30
10.3 Logging dans une socket TCP/UDP
.............................................................................
30
10.4 Logging dans une socket UNIX
....................................................................................
31
10.5 Formatage des logs
........................................................................................................
31
10.6 Rotation des logs
...........................................................................................................
31
10.6.1Critères de déclenchement
.....................................................................................
32
10.6.2Exemples de configuration
......................................................................................
33
10.7 Options spécifiques des fichiers binaires
......................................................................
33
10.8 Configuration
................................................................................................................
34
11Formatage des logs
................................................................................................................
35
11.1 Principe
.........................................................................................................................
35
11.2 Chaînes de formatage (fichiers textes)
..........................................................................
35
11.2.1Spé cification des champs
........................................................................................
36
11.2.2Champs spé ciaux
.....................................................................................................
37
11.2.2.1Drapeaux TCP
..................................................................................................
37
11.2.2.2Date et Heure
....................................................................................................
37
11.2.2.3Couleur
.............................................................................................................
38
11.3 Liste de champs (fichiers binaires)
...............................................................................
39
11.4 Format par dé faut
..........................................................................................................
40
12Matrices de trafic de sites
......................................................................................................
42
12.1 Principe
.........................................................................................................................
42
12.2 Configuration
................................................................................................................
43
12.3 Exemple d’utilisation
....................................................................................................
43
12.4 Enregistrement sur disque
.............................................................................................
44
13Agrégateurs
...........................................................................................................................
46
13.1 Principe
.........................................................................................................................
46
13.2 Configuration
...............................................................................................................
46
13.3 Ecriture sur disque (pré cisions)
.....................................................................................
48
13.4 Affinage des paramè tres
................................................................................................
49
14Dé tection de scans de ports
...................................................................................................
49
14.1 Notions de scans horizontaux et verticaux
....................................................................
49
14.2 Spé cification des valeurs seuils
.....................................................................................
50
14.3 Notifications
..................................................................................................................
50
14.4 Exemple
........................................................................................................................
50
14.5 Configuration
................................................................................................................
52
15Netflow v8
.............................................................................................................................
53
16Netflow v9
.............................................................................................................................
55
16.1 Dé finition d’une template
.............................................................................................
55
16.2 Options avancé es
...........................................................................................................
56
16.2.1Spé cification du numé ro de Template (ID)
.............................................................
57
16.2.2Dé finition exacte des champs
..................................................................................
57
16.2.3Affichage du contenu des templates
.......................................................................
57
16.2.4Affichage des templates inconnus
...........................................................................
57
17Exploitation de compteurs
....................................................................................................
58
Christophe Fillot -
06/10/2005
2
/
86
Collecteur IPFlow
17.1 Principe des compteurs
.................................................................................................
58
17.2 Déclaration d'un fichier de sortie
..................................................................................
58
17.3 Compteur de règle
.........................................................................................................
59
17.4 Compteur d'ACL
...........................................................................................................
60
17.5 Compteur de matrice de trafic de sites
..........................................................................
60
17.6 Compteur de routeur
.....................................................................................................
61
17.7 Compteur d'interface
.....................................................................................................
61
17.8 Templates (Netflow v9 seulement)
...............................................................................
62
17.9 Exemple
........................................................................................................................
63
18Utilisation de RRDTool
........................................................................................................
65
18.1 Installation de RRDTool
...............................................................................................
65
18.2 Cré ation manuelle d'une base RRD
..............................................................................
66
18.3 Cré ation automatique d’une base RRD
.........................................................................
66
18.4 Génération des graphiques
............................................................................................
67
18.5 Exemple
........................................................................................................................
68
19Utilitaire IPFlow Grep : recherche multicritères
...................................................................
70
19.1 Critè res
..........................................................................................................................
70
19.1.1Fonctionnement des options «

--addr

» e t «

--prefix

»
............................................
71
19.1.2Spécification de la taille (option «

--size

»)
............................................................
71
19.2 Options diverses
............................................................................................................
71
19.3 Exemples
.......................................................................................................................
72
20Utilitaire IPFlow «

Flow_Info

»
............................................................................................
75
21Utilitaire IPFlow «

STM_Info

»
............................................................................................
80
22Utilitaire IPFlow «

STM_Fetch

»

........................................................................................
83
23Annexe : exemple
..................................................................................................................
85
Christophe Fillot -
06/10/2005
3
/
86
Collecteur IPFlow
1
Introduction
Le collecteur IPFlow est un collecteur Netflow développé à l’UTC et utilisé dans le cadre du
Réseau Régional de Télécommunications de Picardie.
Ce collecteur supporte actuellement les versions suivantes de Netflow

:
-
v1, v5, v6 et v7

: donné es non agré gé es. Netflow v5 est la version la plus couramment
utilisé e ;
-
v8

: donné es agré gé es par les routeurs, suivant des schémas prédéfinis. Le support de
cette version est encore incomplet dans le collecteur.
-
v9

: nouveau format d’export, basé sur la notion de templates. Le collecteur IPFlow
supporte (avec IPv6) cette version telle qu’elle est décrite dans le White Paper sur
http://www.cisco.com
.
IPFlow permet de recevoir les informations de flux Netflow et d’appliquer un certain nombre
de traitements

parmi lesquels :
-
Logging dans des fichiers disques

(format texte ou binaire) ;
-
Colorisation des flux

;
-
Agrégation des données

;
-
Détection de scans de ports

;
-
Remplissage de bases RRDTool

;
IPFlow permet é galement de ré -émettre les datagrammes Netflow reçus vers d’autres
collecteurs, afin de permettre l’analyse des données suivant différentes configurations.
Les rapports de bugs et les suggestions de nouvelles fonctionnalité s peuvent être envoyés à
Christophe Fillot (
cf@utc.fr)
.
Des exemples supplé mentaires ou des é lé ments spé cifiques de configuration (notamment pour
Netflow v9 et IPv6) peuvent ê tre trouvé es à l’adresse

:
http://www.rrt.cr-picardie.fr/~fillot/nf6 /
Christophe Fillot -
06/10/2005
4
/
86
Collecteur IPFlow
2
Architectures supportées
Le collecteur IPFlow a été compilé et testé avec succès sur les architectures suivantes

:
-
Linux 2.4.x sur i386,
-
FreeBSD 4.x sur i386,
-
Solaris 8 sur Sparc.
3
Rappels sur Netflow
3.1
Principes
Netflow est une technique mise au point par la société Cisco Systems pour réaliser de la
mé trologie réseau. Le concept majeur de Netflow est la notion de flux, un flux étant déterminé
par les critè res suivants

:
-
Adresses IP source et destination,
-
Protocole (TCP, UDP, ICMP,…),
-
ToS (Type Of Service)
-
Ports applicatifs (http, smtp, dns,…),
-
Interfaces d’entrée et de sortie du routeur.
Pour qu’un paquet IP appartienne à un flux, il doit correspondre à tous ces critères,
simultané ment.
Un routeur qui utilise Netflow garde en mé moire une table des flux actifs à un instant donné,
et compte le nombre de paquets et d’octets reçus pour chaque flux. Cisco appelle cette table
«

cache Netflow

» da ns sa documentation.
A chaque paquet reç u, le routeur met à jour ce cache, soit en cré ant une nouvelle entré e si le
flux n’est pas connu, soit en incré mentant les compteurs correspondant au flux dé jà pré sent
dans le cache.
Pour ne pas consommer toute la mé moire du routeur avec un ajout incessant de nouveaux
flux, celui-ci efface au fur et à mesure les flux considérés comme terminés. Quand un flux a
é té inactif pendant un certain temps («

inactive timeout

» e st le terme utilisé par Cisco), le flux
est retiré du cache. Un flux peut é galement être supprimé s’il a été actif trop longtemps


active timeout

»), afin que le cache ne garde pas indé finiment des flux qui ne se terminent
jamais. Enfin, lorsque le routeur voit les drapeaux TCP «

RST

» ou «

FIN

» qui signalent la
fin d’une connexion TCP, le flux est é galement supprimé.
Pour connaître l’ «

inactivité

» d’un flux, le routeur se sert de la date du dernier paquet reç u
pour ce flux et la compare à la date actuelle.
Christophe Fillot -
06/10/2005
5
/
86
Collecteur IPFlow
L’intérêt de Netflow étant de pouvoir réaliser de la métrologie, il était donc nécessaire de
fournir les informations sur les flux à un programme d’analyse. En fait, lorsqu’un flux a
expiré et est supprimé du cache, il peut être exporté vers une machine de collecte, qui reçoit
ainsi des paquets Netflow suivant un protocole bien défini par Cisco. Il en existe plusieurs
versions, la dernière étant la version 9.
Pour des raisons d’efficacité et d’é conomie de bande passante, le routeur groupe l’envoi de
plusieurs flux dans un mê me paquet (entre 20 et 30 flux par paquets).
3.2
Versions de Netflow
Cisco a cré é plusieurs versions du protocole Netflow, au fur et à mesure de l’apparition de
nouveaux besoins de ses clients. A ce jour, les versions 1, 5, 6, 7, 8 et 9 existent. La 9 devrait
ê tre en mesure de ré pondre aux problè mes d’é volutivité qui ont touché les versions
pré cé dentes et devrait donc ê tre la derniè re.
Pour rappel, la version 5 est la plus utilisé e sur les routeurs. La version 7 est spé cifique aux
commutateurs Catalyst. La version 8 permet d’utiliser des sché mas d’agré gation suivant
certains critè res.
Enfin, la version 9 supporte les «

nouveaux protocoles

», à savoir principalement IPv6 et
MPLS (
MultiProtocol Label Switching
).
4
Fichier de configuration et démarrage
Le paramé trage du collecteur IPFlow s’effectue à l’aide d’un fichier de configuration divisé
en sections hié rarchisé es, et dont le format se rapproche du serveur DNS «

BIND

»

:
! Commentaire
section <parametre> {

sous-section {

parametre <valeur>;

parametre-liste {

<valeur_A>;

<valeur_B>;

<valeur_C>;

};

};
};
Remarques

:
-
L’analyse du fichier est sensible à la casse (distinction majuscules/minuscules).
-
Il est possible d’utiliser des commentaires «

à la C

»

: /* commentaire */
-
Il est possible d’inclure des fichiers au moyen de la directive
$include
"
nom_de_fichier
"
.
Le lancement du collecteur s’effectue simplement par la commande

:
Christophe Fillot -
06/10/2005
6
/
86
Collecteur IPFlow
ipflow collector <nom_du_fichier_de_configuration>
Lorsque le collecteur démarre, un certain nombre de messages sont affichés

:
[rrtadm@nemesys ~]$ ./ipflow collector config-1.txt
IPFlow Collector - Release 0.49.3 26-Jul-02 (experimental)
Compiled at Aug 29 2002 00:04:22 by Christophe Fillot (cf@utc.fr)
Initializing IPv4 and IPv6 MLS caches.
IPv4 MLS: level-4, IPv6 MLS: level-16
Default IPv4 address: 193.49.251.82.
Default IPv6 address: undefined.
Creating site matrix for traffic classifier.
8 sites, 7 networks found in configuration.
Retrieving 7500_UTC interface list by SNMP...
Router 7500_UTC supervised (80 interfaces detected).
IPFlow is using 310 Kb of memory in 122 blocks.
MLS: memory allocated by IPv4 cache: 5 Kb, by IPv6 cache: 1 Kb.
Enabling Netflow export on 1 router(s).
>>> 100 OK
Router 7500_UTC: registered with dispatching service (IPv4)
Netflow v5 enabled for router 7500_UTC.
UDP port=56040
[
Pression de Control-C pour arrêt du collecteur
]
Termination signal received, halting...
Stopping Netflow dispatching for router 7500_UTC...
>>> 100 OK
IPFlow system successfully stopped.
Si des erreurs ont été rencontrées dans le fichier de configuration, le collecteur s’arrête
immé diatement et affiche des dé tails sur l’erreur.
Pour arrê ter le collecteur, l’appui sur les touches «

Ctrl-C

» s uffit.
Christophe Fillot -
06/10/2005
7
/
86
Collecteur IPFlow
5
Routeurs
Chaque routeur dont on souhaite recevoir les records Netflow doit être décrit dans le fichier de
configuration. Les routeurs sont identifiés par un nom unique (en principe le
hostname
du
routeur, mais ce n’est pas obligatoire).
5.1
Paramétrage
Les paramètres à indiquer pour recevoir les datagrammes Netflow d’un routeur sont les
suivants

:
-
L’adresse IP du routeur, avec laquelle sont envoyés les datagrammes. Il peut être
né cessaire de fixer cette adresse sur le routeur au moyen de la commande IOS
«

ip flow-export source <adresse_ip>|<interface>

».
-
Une communauté SNMP avec privilège de lecture seule. Un accès SNMP est nécessaire
sur le routeur pour dé terminer les noms des interfaces associé s à chaque index SNMP. Si
aucune communauté n’est indiqué e, le collecteur utilise la communauté «

public

» par
dé faut.
-
Version de Netflow. Les versions supportées par le collecteur sont

: 1, 5, 6, 7, 8 et 9. Si
aucune version n’est spé cifié e, v5 est la version utilisé e par dé faut.
-
L’adresse IP et le port UDP de réception à utiliser pour recevoir les datagrammes.
Indiquer une adresse IP sert gé né ralement dans le cas de machines disposant de plusieurs
interfaces ré seaux (
multi-homed
).
Fixer le port de ré ception permet de conserver la mê me configuration d’export du routeur
(par dé faut le port est attribué dynamiquement par le systè me).
Christophe Fillot -
06/10/2005
8
/
86
Collecteur IPFlow
Le format de configuration

est le suivant:
router <nom_de_routeur> {

ip-address <adresse_ip_routeur>;

snmp-community <communaute_snmp>;

netflow {

version 1|5|6|7|8|9;

receiver-address <adresse_ip_locale>;

receiver-port <port_de_reception>;

};
};
Exemple

:
router 7500_UTC {

ip-address 193.51.1.105;

snmp-community netflow;

netflow {

version 5;

receiver-address 193.49.251.82;

receiver-port 8000;

};
};
Dans cet exemple, le routeur à superviser a pour adresse IP 193.51.1.105, et envoie des
datagrammes Netflow v5. Le collecteur recevra les données sur l’interface de la machine
ayant l’adresse IP 193.49.251.82, avec le port 8000/udp comme port de réception.
La configuration IOS du routeur serait

:
interface Loopback0

ip address 193.51.1.105

255.255.255.255;
!
ip flow-export version 5
ip flow-export source Loopback0
ip flow-export destination 193.49.251.82 8000
!
access-list 10 permit 193.49.251.82
snmp-community netflow RO 10
!
5.2
Utilisation d’un «

dispatcher

»
Au lieu de collecter les datagrammes Netflow directement en provenance des routeurs, il est
possible d’utiliser des dispatchers.
Les dispatchers ont pour rôl e de dupliquer les datagrammes Netflow reçus des routeurs (voire
d’autres dispatchers) et de les ré-émettre à destination des collecteurs qui en ont fait la
demande. Il est ainsi possible de lancer plusieurs collecteurs avec des configurations
diffé rentes pour analyser le même trafic Netflow. Ce paragraphe aborde la configuration de la
partie cliente

; la partie serveur étant abordée dans la section «

Service de dispatching

».
Pour pouvoir recevoir le trafic Netflow d’un dispatcher, un collecteur doit s’abonner auprès de
celui-ci.
Christophe Fillot -
06/10/2005
9
/
86
Collecteur IPFlow
Le processus d’abonnement permet au collecteur d’indiquer au dispatcher les éléments
suivants

:
-
Le nom du routeur

;
-
Le port UDP utilisé pour la réception des datagrammes

du côt é collecteur;
-
La version de Netflow souhaitée.
Lorsque le collecteur est stoppé, une procédure de désabonnement est lancée auprès du
dispatcher pour stopper l’envoi des datagrammes Netflow.
La version de Netflow employée doit naturellement être identique entre le collecteur et le
dispatcher. En cas de non concordance, la configuration du routeur échouera.
Les messages d’abonnement / désabonnement sont envoyés au moyen d’une connexion TCP
ouverte du collecteur vers le dispatcher. Par dé faut, le port TCP utilisé par le dispatcher est le
5555.
Un dispatcher est indiqué dans le fichier de configuration sous la forme

:
dispatcher <nom_du_dispatcher> {

hostname <host>;

port <port_de_contrôle>;
};
Chaque dispatcher est identifié par un nom unique, il est donc tout à fait possible d’utiliser
plusieurs dispatchers dans un mê me fichier de configuration.
Il est ensuite né cessaire d’indiquer dans la configuration des routeurs que l’on souhaite
recevoir les datagrammes Netflow d’un dispatcher

:
router <nom_du_routeur> {

netflow {

dispatcher <nom_du_dispatcher>;

};
};
Remarques

:
-
Le nom du routeur doit ê tre identique dans les configurations du collecteur et du
dispatcher.
-
Il est né cessaire d’indiquer une adresse IP et une communauté SNMP même en cas
d’utilisation d’un dispatcher, le collecteur ayant besoin d’interroger le routeur en SNMP
pour obtenir la liste des interfaces.
Christophe Fillot -
06/10/2005
10
/
86
Collecteur IPFlow
Exemple

:
dispatcher Nemesys {

hostname nemesys.rrt.cr-picardie.fr;

port 5555;
};
router 7500_UTC {

ip-address 193.51.1.105;

snmp-community public;

netflow {

version 5;

dispatcher Nemesys;

};
};
5.3
Renommage des interfaces
Pour faciliter la gestion des configurations IPFlow, il est possible de renommer les interfaces
d’un point de vue du collecteur. Ceci permet d’être indépendant de toute modification
d’interface sur un routeur, ce qui peut arriver par exemple quand un site donné change
d’interface (changement du type du lien notamment). L’intérêt principal de cette fonction est
de pouvoir affecter des noms d’interfaces plus simples à retenir et à manipuler, et de faciliter
les recherches dans les fichiers de logs (abordé s plus loin).
La syntaxe pour renommer une interface est simple

:
router C6k-MSFC {

ip-address 195.83.155.1;

snmp-community netflow;

netflow {

version 5;

};

interface Vlan2 {

rename-to “Internet”;

};

interface Vlan3 {

rename-to “SI”; /* Service Informatique */

};
};
Christophe Fillot -
06/10/2005
11
/
86
Collecteur IPFlow
6
Service de dispatching
Le service de dispatching (partie «

serveur

») des datagrammes Netflow fait partie intégrante
du collecteur. Toute instance du collecteur peut donc faire office de dispatcher.
Le service de dispatching s’active au moyen de la section «

dispatching-process

», décrite ci-
dessous

:
dispatching-process {

control-port <port_de_contrôle>;

protocol ipv4|ipv6;

allowed-routers {

<liste_de_routeurs>;

};
};
Les routeurs pour lesquels on souhaite autoriser le dispatching doivent être explicitement
indiqué s dans la sous-section «

allowed-routers

».
Le port de contrôl e définit le numéro de port TCP utilisé pour les messages d’abonnements et
de dé sabonnements circulant entre collecteur et dispatcher. Si aucun numéro de port n’est
spé cifié, la valeur par dé faut
5555
est utilisé e.
La directive «

protocol

» permet de choisir le protocole (IPv4 ou IPv6) employé. Si rien n’est
spé cifié, le dispatcher acceptera les connexions en IPv4 ou en IPv6, selon ce qui est supporté
par le système d’exploitation.
Exemple de configuration

:
router 7500_UTC {

ip-address 193.51.1.105;

snmp-community netflow;

netflow {

version 5;

};
};
router 7500_CURI {

ip-address 193.51.1.104;

snmp-community netflow;

netflow {

version 5;

};
};
dispatching-process {

control-port 5555;

allowed-routers {

7500_UTC;

7500_CURI;

};
};
Christophe Fillot -
06/10/2005
12
/
86
Collecteur IPFlow
Remarque

: il est tout à fait possible de configurer un collecteur pour traiter des flux (avec
agrégation, logging, etc.) et d’activer le service de dispatching en parallèle.
Christophe Fillot -
06/10/2005
13
/
86
Collecteur IPFlow
7
Sites
7.1
Notion de site
Le collecteur IPFlow s’appuie sur la notion de site pour faciliter la classification du trafic en
provenance des routeurs. Un flux Netflow contient (hormis pour certains schémas
d’agrégation Netflow v8), une adresse source et une adresse destination. La classification par
site permet de dé terminer à quels sites appartiennent ces deux adresses.
Un site est dé fini par les é lé ments suivants

:
-
Une liste de ré seaux IPv4

;
-
Une liste de ré seaux IPv6

;
-
Une liste de «

sous-sites

».
Un ré seau IPv4 ou IPv6 peut être déclaré dans un ou plusieurs sites. Dans ce cas, l’adresse IP
à classifier appartiendra à tous ces sites.
7.2
Exemple pratique
A titre d’exemple, supposons que dans le cadre d’un réseau régional on ait deux sites
universitaires, IUT_A et IUT_B, comprenant les réseaux suivants

:
-
IUT_A

: 192.168.1.0/24 et 192.168.2.0/24

;
-
IUT_B

: 192.168.3.0/24 et 192.168.4.0/24

;
La configuration IPFlow serait la suivante

:
site IUT_A {

networks {

192.168.1.0/24;

192.168.2.0/24;

};
};
site IUT_B {

networks {

192.168.3.0/24;

192.168.4.0/24;

};
};
Imaginons maintenant que l’on souhaite pouvoir regrouper ces deux IUTs sous un site
gé né rique, nommé «

IUT

». L a configuration serait alors

:
site IUT {

contains {

IUT_A;

IUT_B;

};
Christophe Fillot -
06/10/2005
14
/
86
Collecteur IPFlow
};
Ainsi, si le collecteur reçoit un record Netflow indiquant comme adresse source 192.168.4.18,
alors cette adresse appartiendra simultanément aux sites IUT_B et IUT.
La notion d’appartenance de sites supporte plusieurs niveaux hiérarchiques

:
site Education {

contains {

IUT;

Lycees;

Universites;

};
};
Remarque

: l’ordre de dé finition des sites dans le fichier de configuration est libre.
7.3
Gestion des sous-réseaux
Le collecteur IPFlow gère la notion de sous-réseaux IP. Supposons que l’on ait la
configuration suivante

:
site A {

networks {

192.168.1.0/24;

};
};
site B {

networks {

192.168.1.0/25;

};
};
Ainsi, les adresses IP appartenant à la plage 192.168.1.0 - 192.168.1.127 appartiendront à la
fois au site A et au site B.
7.4
Sites particuliers
Deux sites sont définis automatiquement par le collecteur Netflow

: «

ANY

» e t «

OTHER

».
Toute adresse IP (qu’elle soit v4 ou v6) appartient au site «

ANY

». Toute adresse IP qui
n’appartient à aucun site dé fini dans la configuration est classé e dans le site «

OTHER

».
Le site «

OTHER

» est donc un moyen simple de déterminer si une adresse IP donnée est
exté rieure ou non au ré seau supervisé. Pour ce faire, l’ensemble des adresses de ce ré seau doit
donc être déclaré dans le fichier de configuration.
Christophe Fillot -
06/10/2005
15
/
86
Collecteur IPFlow
7.5
Configuration
Ce paragraphe reprend la syntaxe de la configuration d’un site

:
site <nom_de_site> {

networks {

<prefixe_ipv4>;


<prefixe_ipv4>;

};

ipv6_networks {

<prefixe_ipv6>;


<prefixe_ipv6>;

};

contains {

<nom_de_site>;


<nom_de_site>;

};
};
Christophe Fillot -
06/10/2005
16
/
86
Collecteur IPFlow
8
Règles d’analyse (Rules)
Les règles d’analyse définissent les actions (logging, comptage, etc.) à appliquer aux records
Netflow reçus des routeurs. Une règle est composée de termes, évalués successivement
suivant l’ordre donné dans le fichier de configuration. Contrairement aux access-lists, tous les
termes sont é valué s, sauf indication contraire de l’utilisateur.
Chaque terme contient une liste d’action à effectuer et une liste de critè res, qui doivent être
obligatoirement vérifiés pour pouvoir déclencher les actions.
Les deux premiers critè res utilisables sont les sites source et destination. Une access-list peut
ê tre
optionnellement
indiqué e pour sé lectionner plus finement le type de trafic (avec
notamment des critè res de niveau 4, par exemple les ports TCP ou UDP). Les access-lists
sont dé crites dans la section suivante.
Pour que le terme de la rè gle soit «

matché

», les adresses IP source et destination (v4 ou v6)
dans le record Netflow doivent appartenir aux sites indiqué s dans la configuration du terme,
suivant les principes é voqué s dans la section

«

Sites

». Si le site source ou destination n’est
pas spé cifié, le collecteur utilise par dé faut le site «

ANY

».
Si une access-list a é té indiqué e, le record Netflow doit é galement «

matcher

» c ette ACL pour
que le terme soit é valué positivement.
8.1
Actions possibles
Lorsqu’un terme est «

matché

», une ou plusieurs actions peuvent ê tre appliqué es sur le flux
reç u. Ces diffé rentes actions visent à logguer le flux, le coloriser, ou encore effectuer une
agré gation. Ce paragraphe pré sente un ré sumé des actions possibles, les dé tails de la
configuration é tant donné s dans les sections dé dié es à chaque action.
8.1.1
Colorisation des flux
Pour permettre un suivi temps ré el des flux à l’é cran, il est possible de coloriser les flux au
moyen du mot clé «

color

».
Les couleurs possibles sont

: «

white

», «

red

», «

green

»,
«

yellow

», «

blue

», «

pink

», «

cyan

», «

bold-red

», «

bold-green

», «

bold-yellow

», «

bold-
blue

», «

bold-pink

», «

bold-cyan

».
Ces couleurs sont gé né ré es au moyen de codes ANSI, il est donc né cessaire de disposer de
terminaux gé rant ces codes.
8.1.2
Matrice de trafic de sites
Christophe Fillot -
06/10/2005
17
/
86
Collecteur IPFlow
Ces matrices permettant de comptabiliser le nombre de flux, de paquets et d’octets échangés
entre sites.
Trois modes existent

:

Source

: le comptage s’effectue suivant les sites sources uniquement

;

Destination

: le comptage s’effectue suivante les sites destinations uniquement

;

Flux

: le comptage s’effectue suivant les sites sources et les sites destinations.
Remarques

:
-
Le comptage est effectué en fonction des adresses IP source et destination.
-
Une matrice de trafic peut être indiquée dans la configuration générale de la règle
d’analyse.
L’utilisation d’une matrice de trafic s’effectue au moyen du mot-clé «

site-traffic-matrix

».
8.1.3
Agrégation
Les agré gateurs permettent d’agré ger les flux suivant un certain nombre de champs
(protocole, ports UDP/TCP, TOS, etc).
L’envoi du flux à un agrégateur se fait au moyen du mot-clé «

aggregator

».
8.1.4
Logging
Il est possible de logguer le flux dans un fichier au moyen du mot-clé «

channel

». Un channel
peut ê tre un fichier sur disque ou bien une socket TCP, UDP ou UNIX.
8.1.5
Détection de scans de port
Le collecteur permet de dé tecter en temps ré el les scans de ports sur un ensemble de machines
ou pour une machine particuliè re.
8.1.6
Réécriture d’adresses
Dans certains cas, il peut ê tre inté ressant de ré é crire les adresses source et/ou destination
reçues d’une interface donnée. Cette possibilité est souvent utilisée pour mapper les adresses
IP situé es à l’exté rieur d’un ré seau (Internet) vers une seule adresse symbolique, afin
notamment de ré duire la taille des tables d’agré gation.
Il est important de garder à l’esprit qu’une fois les adresses ré é crites, il n’est plus possible de
manipuler leur ancien contenu. Dans le cas où il est nécessaire de disposer de l’ensemble des
Christophe Fillot -
06/10/2005
18
/
86
Collecteur IPFlow
adresses et d’adresses mappées, il faut lancer deux instances du collecteur en s’appuyant sur le
service de dispatching.
L’exemple ci-dessous montre le mappage des adresses Internet vers une seule adresse 0.0.0.0,
en supposant que l’interface vers Internet est FastEthernet0/0

:
router 7200 {

! […]

interface FastEthernet0/0 {

rule-input rewrite_input;

rule-output rewrite_output;

};
};
rule rewrite_input {

term 1 {

rewrite-src-addr 0.0.0.0;

};
};
rule rewrite_output {

term 1 {

rewrite-dst-addr 0.0.0.0;

};
};
Remarque

: il est é galement possible de réécrire les adresses IPv6 au moyen des directives
«

rewrite-ipv6-src-addr

» e t «

rewrite-ipv6-dst-addr

».
8.1.7
Evaluation des termes
Sauf indication contraire, tous les termes d’une règle sont évalués successivement.
Il existe deux moyens d’effectuer une rupture de sé quence

:

Arrêt de l’évaluation de la règle, au moyen de l’indication «

evaluation stop

». Lorsqu’un
terme est «

matché

» et que cette indication est pré sente, l’é valuation de la rè gle est
stoppé e.

Branchement sur une autre règle, au moyen du mot-clé «

jump

». Lorsqu’un terme est
«

matché

» et que ce mot-clé est pré sent, la rè gle indiqué e est é valué e. A la fin de
l’é valuation de cette rè gle, le contrôl e est rendue à la règle appelante. Cette notion évoque
celle de
sous-programmes
.
8.2
Spé cification des règles
Les rè gles d’analyse permettent d’appliquer des actions spé cifiques aux flux reçus en fonction
des critè res dé finis par l’utilisateur. Pour ê tre utilisé es, les rè gles doivent ê tre associé es aux
routeurs. Il existe trois mé thodes d’affectation

:
Christophe Fillot -
06/10/2005
19
/
86
Collecteur IPFlow
-
Affectation par interface d’entrée

;
-
Affectation par interface de sortie

;
-
Affectation globale au routeur, indépendamment des interfaces.
La syntaxe au niveau de la configuration d’un routeur est la suivante

:
router <nom_du_routeur> {

interface <nom_interface> {

! Règle en entrée d’interface

rule-input <nom_de_regle>;

! Règle en sortie d’interface

rule-output <nom_de_regle>;

};

! Règle globale

rule <nom_de_regle>;
};
Le collecteur IPFlow analyse les règles dans cet ordre

:
1.
Règle en entrée,
2.
Rè gle en sortie.
3.
Rè gle globale,
Christophe Fillot -
06/10/2005
20
/
86
Collecteur IPFlow
8.3
Configuration
Ce paragraphe reprend en détail la syntaxe d’une règle d’analyse

:
rule <nom_de_regle> {

site-traffic-matrix <nom_de_matrice>;

term <nom_de_terme_1> {

source <nom_de_site>;

destination <nom_de_site>;

access-list <nom_acl>;

aggregator <nom_aggregateur>;

site-traffic-matrix <nom_de_matrice>;

scan-detector <nom_du_detecteur>;

color <nom_de_couleur>;

channel <nom_de_channel>;

evaluation stop;

jump <nom_de_regle>;

rewrite-src-addr <adresse_ipv4>;

rewrite-dst-addr <adresse_ipv4>;

rewrite-ipv6-src-addr <adresse_ipv6>;

rewrite-ipv6-dst-addr <adresse_ipv6>;

};

term <nom_de_terme_2> {


};

};
Récapitulatif des couleurs possibles

:
-
white,
-
red,
-
green,
-
yellow,
-
blue,
-
pink,
-
cyan,
-
bold-red,
-
bold-green,
-
bold-yellow,
-
bold-blue,
-
bold-pink,
-
bold-cyan.
Christophe Fillot -
06/10/2005
21
/
86
Collecteur IPFlow
9
Access-Lists
Les access-lists IPFlow permettent d’appliquer des filtres pointus sur le trafic à analyser au
niveau des règles. Une access-list est composée de termes, évalués séquentiellement dans
l’ordre indiqué par le fichier de configuration. Dès qu’un terme est «

matché

», l’évaluation de
l’ACL est stoppée. Les ACL IPFlow sont donc similaires aux ACL Cisco.
Il est possible de spécifier les critères suivants dans les termes

:
-
Protocole

IP

;
-
Adresses (IPv4 ou IPv6) source et destination

;
-
Ports TCP/UDP source et destination

;
-
Champ TOS (Type Of Service)

;
-
Flags TCP

;
-
Systè mes Autonomes (AS) source et destination

;
-
Duré e du flux

;
-
Nombre de paquets du flux

;
-
Nombre d’octets du flux.
Remarque

: certains champs sont susceptibles de ne pas être disponibles dans les records
Netflow suivant la version de Netflow ou le sché ma d’agré gation utilisé s. Les champs non
disponibles sont fixé s automatiquement à zéro par le collecteur.
9.1
Evaluation
Le ré sultat de l’é valuation d’une access-list peut ê tre soit «

permit

», soit «

deny

». Lorsque
aucun des termes n’est «

matché

», l e ré sultat implicite est «

deny

».
Le ré sultat à renvoyer au niveau d’un terme est indiqué grâce au mot-clé «

action

», suivi de
«

permit

» ou «

deny

».
9.2
Description des critères
9.2.1
Protocole IP
Le protocole IP est filtré au moyen du mot-clé «

protocol

». Le protocole peut ê tre spé cifié
sous forme de chaîne de caractères pour les protocoles les plus courants (tcp, udp, icmp) ou
sous forme de nombre 8-bits.
Christophe Fillot -
06/10/2005
22
/
86
Collecteur IPFlow
9.2.2
Adresses IPv4 source et destination
Les adresses IPv4 source et destination sont filtrées au moyen des mots-clés «

src-addr

» /
«

src-mask

» e t «

dst-addr

» / «

dst-mask

».
Contrairement aux ACLs Cisco où les masques sont des «

wildcards masks

» (bits à 0
significatifs), le collecteur IPFlow utilise des masques où l es bits à 1 sont significatifs.
Exemple

: le filtre suivant matche les adresses 192.168.1.0 à 192.168.1.255

:
src-addr 192.168.1.0;
src-mask 255.255.255.0;
9.2.3
Adresses IPv6 source et destination
Les adresses IPv6 source et destination peuvent être filtrées au moyen des directives «

ipv6-
src-addr

» et «

ipv6-dst-addr

». Contrairement aux adresses IPv4, les adresses à filtrer doivent
ê tre indiqué es sous forme de pré fixe.
Exemple

:
ipv6-src-addr fec0:c000::/32;
9.2.4
Champ TOS
Le champ TOS est filtré grâce aux champs «

tos-value

» et «

tos-mask

». De manière similaire
aux adresses IP, les bits significatifs du masque sont à 1.
9.2.5
Flags TCP
Les flags TCP sont filtré s au moyen des mots-clé s «

tcp-flags

» et «

tcp-mask

», qui prennent
en paramè tres une liste de flags

:
-
«

syn

»

: ouverture de la connexion

;
-
«

fin

»

: fin de la connexion

;
-
«

ack

»

: acquittement

;
-
«

rst

»

: reset de la connexion

;
-
«

push

»

: envoi des donné es bufferisé es à l’application

;
-
«

urg

»

: donné es urgentes pré sentes.
Exemple

:
tcp-flags { syn; ack; };
tcp-mask { syn; ack; rst; };
Christophe Fillot -
06/10/2005
23
/
86
Collecteur IPFlow
Dans cet exemple, seuls les flux avec les bits SYN et ACK positionnés et le bit RST à zéro
seront matchés. La valeur des flags non spécifiés dans le masque est ignorée.
Remarques :

Il est important de garder à l’esprit que les flags TCP répertoriés par Netflow sont une
combinaison en «

OU

logique

» de s flags qui ont circulé dans les paquets du flux.

Il est fortement recommandé de filtrer le protocole IP au moyen de la ligne «

protocol
tcp;

»

; les flags TCP étant évidemment indéfinis pour des protocoles autres que TCP.
9.2.6
Ports source et destination
Les ports source et destination sont indiqué s au moyen des mots clé s «

src-port

» et «

dst-
port

». I l est possible d’indiquer un port ou une é tendue de ports.
Exemple :
src-port 25;
dst-port 1024-65535;
9.2.7
AS source et destination
Les systèmes autonomes source et destination peuvent être filtrés au moyen des mots-clés
«

src-as

» e t «

dst-as

».
Exemple

:
src-as 2200;
9.2.8
Duré e
Pour chaque flux, le process Netflow d’un routeur conserve un timestamp pour le premier et
le dernier paquets reçus. La durée d’un flux peut donc être aisément déterminée par le
collecteur IPFlow.
Il est possible d’indiquer une contrainte sur la duré e des flux dans une ACL au moyen du mot-
clé «

time-range

», qui prend en paramè tre une plage de valeurs, indiqué es en millisecondes.
Exemple

:
time-range 120000-180000;
Dans cet exemple, seuls les flux ayant duré entre 2 et 3 minutes seront matchés.
Remarque

: lorsque l’on ne souhaite pas indiquer de limite haute, il suffit de prendre une
valeur suffisamment grande (par ex. 1.000.000.000) qui ne sera jamais rencontrée en pratique.
Christophe Fillot -
06/10/2005
24
/
86
Collecteur IPFlow
9.2.9
Nombre de paquets et d’octets
Il est également possible d’indiquer une contrainte sur le nombre de paquets et d’octets du
flux grâce aux mots-clé «

packet-range

» et «

size-range

», qui prennent tous deux une plage
de valeurs en paramètres.
9.3
Optimisation
Chaque ACL étant évaluée séquentiellement, un trop grand nombre de termes peut avoir un
impact né gatif sur la performance du collecteur, en particulier si les termes les plus souvent
matché s se situent en fin d’ACL.
Il est possible de compiler les access-lists pour obtenir un temps constant dans leur é valuation,
quelque soit le nombre de termes. Cette fonctionnalité est analogue aux «

Turbo ACL

»
disponibles dans certaines versions d’IOS.
Les ACLs ne peuvent pas être compilées lorsque les critères suivants sont utilisés

:
-
AS source et destination

;
-
Durée du flux

;
-
Nombre de paquets du flux

;
-
Nombre d’octets du flux.
Remarques

:

La tentative de compilation d’une ACL comportant les critè res é voqué s ci-dessous
é chouera au dé marrage du collecteur, mais ne provoquera pas de problè me à l’utilisation.

Le choix de la compilation s’effectue par ACL, contrairement à IOS où toutes les ACLs
sont systématiquement compilées lors de la saisie de la commande «

access-list
compiled

».

Il est possible d’afficher les termes inutiles d’une ACL lorsque celle-ci est compilé e en
indiquant «

show-unused-terms yes

»

dans la configuration globale de l’ACL.
L’algorithme de compilation permet en effet de dé terminer les rè gles qui ne seront jamais
«

matché es

».
Christophe Fillot -
06/10/2005
25
/
86
Collecteur IPFlow
9.4
Configuration
access-list <nom_acl> {

compiled-mode enable|disable;

show-unused-terms yes|no;

term <nom_de_terme_1> {

action permit|deny;

protocol tcp|udp|icmp|<numero>;

tos-value <valeur_tos>;

tos-mask <valeur_masque>;

tcp-flags { syn; ack; urg; push; fin; rst; };

tcp-mask { syn; ack; urg; push; fin; rst; };

src-addr <adresse_ip>;

src-mask <adresse_ip>;

dst-addr <adresse_ip>;

dst-mask <adresse_ip>;

ipv6-src-addr <prefixe_ipv6>;

ipv6-dst-addr <prefixe_ipv6>;

src-port <port>|(<port_debut>-<port_fin>);

dst-port <port>|(<port_debut>-<port_fin>);

src-as <numero_AS>;

dst-as <numero_AS>;

time-range <valeur_debut>-<valeur_fin>;

size-range <valeur_debut>-<valeur_fin>;

packet-range <valeur_debut>-<valeur_fin>;

};

term <nom_de_terme_2> {


};

};
Christophe Fillot -
06/10/2005
26
/
86
Collecteur IPFlow
10
Channels
Les channels permettent de logguer les flux en format texte ou binaire sur disque ou dans une
socket TCP, UDP ou UNIX. Chaque channel est identifié par un nom unique, qui sert alors de
ré fé rence dans les autres sections du fichier de configuration (voir notamment la configuration
des règles).
10.1
Fichiers binaires et textes
Le collecteur IPFlow permet de stocker les donné es dans deux types de fichiers

: les fichiers
textes et les fichiers binaires.
10.1.1
Fichiers textes
Les fichiers textes sont lisibles «

à l’œ il nu

» par l’utilisateur (au moyen d’utilitaires comme
grep
,
cat
, …), mais ont pour désavantage d’être volumineux et ils ne sont pas adaptés pour
ê tre traité s rapidement par une machine. Avec un fichier texte, l’utilisateur peut spécifier la
maniè re de formater la sortie pour n’afficher que les champs qui l’inté ressent.
10.1.2
Fichiers binaires
Les fichiers binaires ne sont pas lisibles à l’œ il nu, mais ils offrent une capacité optimum pour
le stockage des donné es et permettent des post-traitements par une machine. Seul le stockage
sur disque est possible avec ce type de channel (les sockets ne sont pas supporté es). Pour ces
fichiers, l’utilisateur spé cifie quels sont les champs Netflow qui doivent ê tre stocké s.
Les utilitaires suivants (documenté s plus pré cisé ment dans d’autres chapitres) permettent la
manipulation des fichiers binaire de type «

flux

»

:
-
flow_info

: obtenir des informations sur le fichier

;
-
grep

: effectue une recherche multicritè res

;
-
top

: agré gation des donné es, repè re les é lé ments (adresses, protocoles, … ) les plus
«

causants

» ( top-talkers)

;
-

sdraw

: ré alise des graphes de trafic (avec RRDTool).
Dans un fichier texte, les flux sont é crits en continu, alors que dans les fichiers binaires les
flux sont é crits dans une structure organisé e en sections. Les sections sont configuré es par
l’utilisateur qui dé termine la duré e de chaque section. Par dé faut, l’intervalle entre les sections
et de 5 minutes, et se change au moyen de la directive «

time-mark » en indiquant un nombre
de secondes.
Christophe Fillot -
06/10/2005
27
/
86
Collecteur IPFlow
L’utilisateur choisit d’écrire les sections à intervalle de 5 minutes à partir de 12H00.
Par exemple la section 0 correspond à l’ensemble des flux
stockés à partir de 12H00 jusqu’à 12H05.
La section 1 correspond donc à l’ensemble de flux stocké s
entre 12H05 et 12H10.
Il est important de noter que les numé ros de sections et de flux
commencent à 0.
La structure des fichiers binaire est inté ressante. En effet il est possible de se positionner dans
le fichier en fonction des flux et des sections. Supposons qu’un utilisateur veuille accéder au
flux 2 de la section 1. Afin d’éviter de parcourir l’intégralité du fichier (ce qui peut représenter
dans certains cas une é norme perte de temps), il peut utiliser les options suivantes

avec les
utilitaires «

grep

», «

top

» e t «

sdraw

»:
-
--count |-c <arg>
-
--last <arg>
-
--start <arg>
-
--section-count <arg>
-
--section-last <arg>
-
--section-start <arg>
L’utilisateur va donc taper :
ipflow grep --section-start 1 -–start 2 fichier.log
S’il veut les parcourir les deux dernières sections du fichier, il tapera :
ipflow grep --section-last 2 fichier.log
Les options --count, --last et --start s’utilisent pour se positionner dans le fichier en fonction
des flux

:
-
--start indique à partir de quel flux va commencer la recherche

;
-
--last indique le nombre de flux à parcourir en partant de la fin

;
-
--count indique le nombre de flux à parcourir.
Les options --section/-count/-last/-start s’utilisent pour se positionner dans le fichier en
fonction d’une section

:
-
--section-count indique le nombre de sections à parcourir

;
-
--section-last indique le nombre de sections à parcourir en partant de la fin;
-
--section-start indique à partir de quelle section commencera la recherche.
Il est possible d’utiliser simultané ment plusieurs options. Les options --section-last et --last
s’utilisent seules.
Christophe Fillot -
06/10/2005
28
/
86
section 0
flux 0
flux 1
flux 2
flux 3
section 1
flux 0
flux 1
flux 2
section 2
Collecteur IPFlow
Si on utilise conjointement les options de positionnement de flux avec celles des sections,
alors les flux à analyser seront restreints dans les sections spécifiées.
ipflow grep --section-start 1 --section-count 2 --last 1000
Les flux examinés seront les 1000 derniers flux à partir de la section 1, et s’étendant sur deux
sections.
Les sections sont é crites par dé faut à intervalle de 300 secondes (5 minutes). La directive
‘time-mark <arg>’ dans la configuration d’une «

channel

» pe rmet de changer cet intervalle.
10.1.3
Fichiers «

Matrices de Trafic de Sites

»
Les matrices de trafic de sites permettent de comptabiliser le trafic émis ou reçu par les sites
dé finis dans la configuration du collecteur. Il est conseillé de se reporter au chapitre traitant
spé cifiquement de ces matrices pour bien appréhender leur fonctionnement.
Il est possible d’enregistrer le contenu de ces matrices en utilisant des fichiers de type STM
(
Site Traffic Matrix
). Les fichiers STM sont des fichiers binaires, et il faut garder à l’esprit
que ce type de fichier ne peut enregistrer le contenu que d’une seule matrice.
Deux utilitaires existent pour manipuler ces fichiers: «

stm_info

» permet de connaître les
caracté ristiques d’un fichier binaire STM, tandis que «

stm_fetch

» permet de ré cupé rer des
donné es dans un fichier binaire type STM, et de les afficher à l’é cran ou remplir une base
RRDTool.
Il existe trois types de matrices

:
-
les matrices sources
-
les matrices destinations
-
les matrices «

full-flow

»
Il est important de noter que de manière tacite les sites ANY et OTHER sont inclus dans les
matrices.
Une matrice source ou destination est de la forme suivante. Suivants les cas les sites sont
considé ré s comme sites sources ou comme sites destinations

:

Flux
Paquets
Octets
site 1
site 2
site 3
site 4
Pour chaque site on compte le nombre de flux, paquets et octets.
Christophe Fillot -
06/10/2005
29
/
86
Collecteur IPFlow
Les matrices «

full-flow

» s ont des matrices bilinéaires de la forme

:
site 1
site 2
site 3
site 4
site 1
flux/paquets/octets
site 2
site 3
site 4
Pour chaque couple (site i, site j) on compte le nombre de flux, paquets et octets.
10.2
Logging dans un fichier
L’option la plus classique pour un channel est de logguer les flux dans un fichier sur disque.
La configuration est alors la suivante

:
channel <nom_de_channel> {

filename

nom_de_fichier

;
};
Il est possible d’utiliser la sortie é cran du collecteur Netflow en utilisant le fichier «

/dev/tty

».
Il est à noter que plusieurs channels peuvent utiliser ce fichier spécial simultanément.
Remarque importante

: si le channel correspond à un fichier binaire, le contenu du fichier
est repris par le collecteur. Toutefois, les flux sont stockés en utilisant le format préalablement
dé fini dans le fichier, et non dans la configuration du collecteur. Pour les fichiers textes, les
donné es sont ajouté es à la fin du fichier (mode «

append

»), dans un format é ventuellement
diffé rent.
10.3
Logging dans une socket TCP/UDP
Le logging dans une socket TCP ou UDP nécessite deux paramètres

: le nom DNS (ou
l’adresse IP) de la machine destinataire et le port de destination de l’application cliente. La
syntaxe est la suivante

:
channel <nom_de_channel> {

protocol tcp|udp;

hostname <nom_de_machine>;

port <port_tcp_ou_udp>;
};
Exemple

:
channel Machine_1 {

protocol tcp;

hostname nemesys.rrt.cr-picardie.fr;
Christophe Fillot -
06/10/2005
30
/
86
Collecteur IPFlow

port 3000;
};
Remarques

:

Il est possible de spécifier une adresse IP à la place du nom de machine.

Les protocoles IPv4 et IPv6 sont supportés.
10.4
Logging dans une socket UNIX
Le logging dans une socket UNIX permet d’envoyer facilement les données du flux à un
programme fonctionnant sur la même machine. Contrairement aux sockets TCP ou UDP, une
socket UNIX né cessite la pré sence d’un fichier spé cial sur disque de type socket pour pouvoir
fonctionner.
La configuration pour le collecteur est dé crite ci-dessous

:
channel <nom_de_channel> {

protocol unix;

filename

nom_de_fichier

;
};
10.5
Formatage des logs
Il est souvent souhaitable de dé finir un format de sortie des logs personnalisé, notamment
pour pouvoir ne logguer que les é lé ments inté ressants des flux. Les formats de logs offrent
cette possibilité.
Un format de log est identifié par un nom unique, et peut ê tre affecté à un ou plusieurs
channels, au moyen de la directive «

log-format

».
Les formats de logs sont dé crits pré cisé ment dans la section suivante.
10.6
Rotation des logs
Pour faciliter l’archivage des logs (qu’ils soient binaires ou textes), le collecteur dispose d’une
fonctionnalité de rotation, permettant de faire tourner les fichiers sur disque.
Afin de distinguer les fichiers entre eux, la date de création est stockée dans le nom de fichier,
par exemple «

essai-%Y%m%d.log

» (contenant anné e, mois et jour). Les directives de temps
sont donné es dans la page de manuel de strftime (faire
man strftime
pour toutes les connaître).
Les plus importantes sont

:
-
%H

: heures (0 à 23),
-
%M

:

minutes (0 à 59),
Christophe Fillot -
06/10/2005
31
/
86
Collecteur IPFlow
-
%S

: secondes (0 à 59),
-
%d

: jour du mois (1 à 31),
-
%b

: nom du mois abrégé,
-
%m

: mois (1 à 12)
-
%Y

: anné e (sur 4 chiffres),
-
%y

: anné e (2 derniers chiffres).
10.6.1
Critères de déclenchement
Il existe deux possibilités pour déclencher la rotation

:
-
Dépassement d’un certain nombre de flux dans le fichier,
-
Pé riodiquement (par ex. tous les jours).
Christophe Fillot -
06/10/2005
32
/
86
Collecteur IPFlow
10.6.2
Exemples de configuration
L’exemple suivant montre comment réaliser une rotation tous les jours

:
channel test {

filename

essai-%Y%m%d.log

;

rotation {

interval 1440; ! 1440 minutes = 1 journée

};
};
Les fichiers se nommeront ainsi

:
-
essai-20031225.log
-
essai-20031226.log
-

L’exemple ci-dessous montre comment réaliser une rotation au bout de 100000 flux stockés

:
channel test {

filename

essai-%Y%m%d-%H%M.log

;

rotation {

flow-limit 100000; !
1440 minutes = 1 journée

};
};
Les fichiers se nommeront ainsi

(suivant le moment où l a rotation survient) :
-
essai-20031225-1210.log
-
essai-20031225-1403.log
-
essai-20031226-0801.log
-

10.7
Options spécifiques des fichiers binaires
Les fichiers binaires offrent la possibilité d’enregistrer une description et un format de log
sous forme texte pour faciliter leur exploitation ulté rieure.
La configuration se pré sente sous cette forme

:
channel <nom_de_channel> {

filename

nom_de_fichier

;

options {

description <description_du_fichier>;

format <chaine_de_formatage>;

};
};
La chaîne de formatage permet de spécifier un format d’affichage «

par dé faut

» pour le
fichier lors de son exploitation avec un outil tel que IPFlow Grep. Il est conseillé de se
Christophe Fillot -
06/10/2005
33
/
86
Collecteur IPFlow
reporter à la section «

Formatage des logs

» pour obtenir une description complète de
l’utilisation des chaînes de formatage.
10.8
Configuration
channel <nom_de_channel> {

protocol tcp|udp|unix|file;

filename

nom_de_fichier

;

hostname <nom_de_machine>;

port <port_tcp_ou_udp>;

log-format <nom_du_format>;

time-mark <intervalle_entre_sections_en_secondes>;

rotation {

interval <nombre_de_minutes>;

flow-limit <nombre_maxi_de_flux>;

};
};
Christophe Fillot -
06/10/2005
34
/
86
Collecteur IPFlow
11
Formatage des logs
11.1
Principe
Les formats de logs permettent de définir facilement les informations à logguer dans les
fichiers ou sockets de sortie (voir configuration des channels), soit en indiquant dans une
chaîne de caractères les champs Netflow utilisés (fichiers textes), soit en indiquant une liste de
champs à stocker (fichiers binaires). Les données des flux ainsi émises peuvent être agencées
et pré senté es de maniè re souple pour l’utilisateur.
Le but des channels est de pouvoir fournir une abstraction sur le fichier de sortie utilisé et les
donné es qui y sont effectivement stockées.
11.2
Chaînes de formatage (fichiers textes)
Les formats de logs sont dé finis au moyen d’une chaî ne de formatage, dont le principe est
similaire à celui des fonctions C
printf()
,
sprintf()
, etc. Les champs Netflow sont indiqué s sous
la forme «

%{nom_de_champ}

» da ns cette chaîne.
Supposons le format de log suivant

:
log-format Format_Texte {

string

%{router} : %{ipv4-src-addr} > %{ipv4-dst-addr}\n

;
};
Un exemple de sortie serait

:
cisco-7200

: 192.168.1.1 > 195.30.1.1
gw1

: 130.1.1.15 > 172.16.30.254
Il est possible d’appliquer un formatage particulier (du type de ceux utilisé s par
printf()
),
notamment pour permettre d’aligner les donné es.
En reprenant l’exemple ci-dessus, mais en spécifiant un alignement, on obtiendrait donc

:
log-format Format_Texte {

string

%-12s{router} : %-15s{ipv4-src-addr} > %-15s{ipv4-dst-addr}\n

;
};
La sortie serait alors

:
cisco-7200

: 192.168.1.1 > 195.30.1.1
gw1

: 130.1.1.15 > 172.16.30.254
La liste des champs existants est donné e dans le paragraphe suivant.
Christophe Fillot -
06/10/2005
35
/
86
Collecteur IPFlow
11.2.1
Spécification des champs
Il est possible d’utiliser les champs suivants

:
Nom du champ
Description
Type
Format par défaut
router
Nom du routeur
String
%s
router-addr
Adresse (Ipv4) du routeur
String
%s
ipv4-src-addr
Adresse source IPv4
String
%s
ipv4-dst-addr
Adresse destination IPv4
String
%s
ipv4-src-prefix
Préfixe source IPv4
String
%s
ipv4-dst-prefix
Préfixe destination IPv4
String
%s
ipv4-nexthop
Routeur “Next-Hop” IPv4
String
%s
ipv4-bgp-nexthop
Routeur “Next-Hop” BGP IPv4
String
%s
ipv6-src-addr
Adresse source IPv6
String
%s
ipv6-dst-addr
Adresse destination IPv6
String
%s
ipv6-src-prefix
Préfixe source IPv6
String
%s
ipv6-dst-prefix
Préfixe destination IPv6
String
%s
ipv6-nexthop
Routeur “Next-Hop” IPv6
String
%s
ipv6-bgp-nexthop
Routeur “Next-Hop” BGP IPv6
String
%s
ipv6-flow-label
Flow Label IPv6
Integer
%u
ipv6-options-headers
Entêtes IPv6
Integer
%4.4x
src-port
Port source
Integer
%u
dst-prt
Port destination
Integer
%u
protocol
Protocole IP
Integer
%u
src-mask
Masque source
Integer
%u
dst-mask
Masque destination
Integer
%u
src-as
Système autonome (AS) source
Integer
%u
dst-as
Système autonome (AS) destination
Integer
%u
tos
Type de Service (ToS)
Integer
%u
ref-count
Nombre de références (agrégateurs)
Integer
%u
tag
Tag défini par l’utilisateur
Integer
%u
duration
Durée du flux
Integer
%u
timestamp
Timestamp Unix de début du flux
Integer
%llu
mpls-label-1
MPLS Label en Position 1
Integer
%3.3x
mpls-label-2
MPLS Label en Position 2
Integer
%3.3x
mpls-label-3
MPLS Label en Position 3
Integer
%3.3x
mpls-label-4
MPLS Label en Position 4
Integer
%3.3x
mpls-label-5
MPLS Label en Position 5
Integer
%3.3x
mpls-label-6
MPLS Label en Position 6
Integer
%3.3x
mpls-label-7
MPLS Label en Position 7
Integer
%3.3x
mpls-label-8
MPLS Label en Position 8
Integer
%3.3x
mpls-label-9
MPLS Label en Position 9
Integer
%3.3x
mpls-label-10
MPLS Label en Position 10
Integer
%3.3x
flows
Nombre de flux
Integer
%u
packets
Nombre de paquets
32-bit Integer
%llu
bytes
Nombre d’octets
32-bit Integer
%llu
packets-64
Nombre de paquets
64-bit Integer
%llu
bytes-64
Nombre d’octets
64-bit Integer
%llu
proto-num
Protocole IP (nombre)
Integer
%2.2u
proto-str
Protocole IP (texte)
String
%s
tcp-flags
Drapeaux TCP

n
Christophe Fillot -
06/10/2005
36
/
86
Collecteur IPFlow
input-ifindex
Index de l’interface d’entrée
Integer
%u
output-ifindex
Index de l’interface de sortie
Integer
%u
input-ifname
Nom de l’interface d’entrée
String
%s
output-ifname
Nom de l’interface de sortie
String
%s
vlan-id
Identifiant de VLAN
Integer
%u
template-id
Identifiant de Template Netflow v9
Integer
%u
template-model
Modèle de Template Netflow v9
String
%s
date
Date (YYYY-MM-DD)
String
%s
time
Heure (hh:mm:ss)
N/A
N/A
unixtime
Unix Time (nombre de secondes depuis le 1er
janvier 1970)
N/A
N/A
ctime
Affichage personnalisé de la date et de l’heure
(voir la page de manuel de strftime)


color-set
Fixe la couleur d’affichage
N/A
N/A
color-reset
Remise à zéro des paramètres d’affichage
N/A
N/A
Remarque

importante :
il est important de respecter les directives de formatage données dans
le tableau, en particulier au niveau de la distinction entiers / chaînes de caractères.
11.2.2
Champs spéciaux
Certains champs du tableau ci-dessus ont des propriétés ou des utilisations particulières

:

Les drapeaux TCP

: «

tcp-flags

» ;

L’heure et la date de début du flux

: «

date

» e t «

time

» ;

La colorisation

: «

color-set

» e t «

color-reset

».
11.2.2.1
Drapeaux TCP
Par dé faut, les drapeaux TCP sont affiché s sous forme numé rique, en hexadécimal (format
«

%2.2x

»).
Il est possible d’afficher ces drapeaux sous une forme plus claire, en utilisant un formatage de
type chaîne. Chaque flag sera alors désigné par une lettre

:
-
S

: Syn
-
F

: Fin
-
R

: Rst
-
A

: Ack
-
U

: Urg
-
P

: Push
11.2.2.2
Date et Heure
Christophe Fillot -
06/10/2005
37
/
86
Collecteur IPFlow
La date est logguée sous le format

AAAA-MM-JJ avec

:
-
AAAA = Année

;
-
MM = Mois

;
-
JJ = Jour.
L’heure est logguée sous le format

HH:MM:SS.MMM avec

:
-
HH = Heures

;
-
MM = Minutes

;
-
SS = Secondes ;
-
MMM = Millisecondes.
Pour spécifier un formatage particulier de l’heure et de la date, il est conseillé d’employer la
directive «

ctime

». Cette directive fournit à l’utilisateur une plus grande souplesse, car elle
s’appuie sur la fonction C ANSI «

strftime()

». Il est conseillé de lire la page de manuel UNIX
de cette fonction pour connaître les différentes possibilités de formatage.
Les plus importantes sont

:
-
%H

: heures (0 à 23),
-
%M

:

minutes (0 à 59),
-
%S

: secondes (0 à 59),
-
%d

: jour du mois (1 à 31),
-
%b

: nom du mois abré gé,
-
%m

: mois (1 à 12)
-
%Y

: anné e (sur 4 chiffres),
-
%y

: anné e (2 derniers chiffres).
Exemple

:
log-format Format_Texte {

string

%H:%M{ctime} %{router} : %{ipv4-src-addr} > %{ipv4-dst-addr}\n

;
};
11.2.2.3
Couleur
Comme il l’a é té indiqué dans la section traitant des règles d’analyse, il est possible de
coloriser les flux au moyen de la directive «

color

» spé cifié e dans un terme d’une rè gle. Ce
systè me de colorisation s’appuie sur les codes ANSI.
Pour é mettre ces codes en sortie, la directive de formatage «

%{color-set}

» doit être utilisée.
Pour annuler l’effet de couleur (options standard du terminal), la directive %{color-reset} doit
ê tre utilisé e.
Christophe Fillot -
06/10/2005
38
/
86
Collecteur IPFlow
11.3
Liste de champs (fichiers binaires)
Lorsqu’un fichier binaire doit être produit, l’utilisateur doit spécifier la liste des champs qui
doivent être stockés pour chaque flux. L’intérêt de cette manière de procéder est de réduire la
taille du fichier produit, puisque seuls les champs considé ré s comme pertinents par
l’utilisateurs sont enregistrés.
La syntaxe à utiliser est la suivante

:
log-format Format_Binaire {

fields {

< nom_du_champ_1 >;


< nom_du_champ_n >;

};
};
Les noms des champs sont dé finis dans le tableau suivant

:
Nom du champ
Description
router
Nom du routeur
ipv4-src-addr
Adresse source IPv4
ipv4-dst-addr
Adresse destination IPv4
ipv4-nexthop
Routeur “Next-Hop” IPv4
ipv4-bgp-nexthop
Routeur “Next-Hop” BGP IPv4
ipv6-src-addr
Adresse source IPv6
ipv6-dst-addr
Adresse destination IPv6
ipv6-nexthop
Routeur “Next-Hop” IPv6
ipv6-bgp-nexthop
Routeur “Next-Hop” BGP IPv6
ipv6-flow-label
Flow Label IPv6
ipv6-options-headers
Entêtes IPv6
src-port
Port source
dst-port
Port destination
protocol
Protocole IP
src-mask
Masque source
dst-mask
Masque destination
src-as
Système Autonome (AS) source
dst-as
Système Autonome (AS) destination
tos
Type de Service (ToS)
ref-count
Nombre de références dans un agrégateur
tag
Tag défini par l’utilisateur
duration
Durée du flux
timestamp
Flow Timestamp
mpls-label-1
MPLS Label en Position 1
mpls-label-2
MPLS Label en Position 2
mpls-label-3
MPLS Label en Position 3
mpls-label-4
MPLS Label en Position 4
mpls-label-5
MPLS Label en Position 5
mpls-label-6
MPLS Label en Position 6
mpls-label-7
MPLS Label en Position 7
mpls-label-8
MPLS Label en Position 8
mpls-label-9
MPLS Label en Position 9
Christophe Fillot -
06/10/2005
39
/
86
Collecteur IPFlow
mpls-label-10
MPLS Label en Position 10
flows
Nombre de flux
packets
Nombre de paquets (compteur 32-bits)
bytes
Nombre d’octets (compteur 32-bits)
packets-64
Nombre de paquets (compteur 64-bits)
bytes-64
Nombre d’octets (compteur 64-bits)
tcp-flags
Drapeaux TCP
input-ifindex
Index de l’interface d’entrée
output-ifindex
Index de l’interface de sortie
vlan-id
Numéro de VLAN
template-id
Identifiant de Template Netflow v9
Il est possible de spécifier n’importe quelle combinaison de champs (rien n’est imposé).
Exemple

:
log-format Format_Binaire {

fields {

ipv4-src-addr;

ipv4-dst-addr;

protocol;

tos;

};
};
11.4
Format par dé faut
En cas d’utilisation d’un channel sans spé cification de format de log, le fichier sera au
format
texte
et le format par dé faut suivant sera employé

:
«

%{color-set}%-12s{router} %{date} %{time} |

%-15s{ipv4-src-addr} | %-15s{ipv4-dst-addr} |

%-4s{proto-str} %5u{src-port} %5u{dst-port} | P: %5Lu{packets} | S: %7Lu{bytes} |

T: %6u{duration} | %-22s{input-ifname} -> %{output-ifname} %{color-reset}\n

»
Exemple de ré sultat

:
«

7500_UTC 2002-05-13 10:44:36.324 | 195.221.156.8 | 195.134.210.10 |

TCP 61255 80 | P: 6 | S: 685 | T: 284 |

ATM0/1/0.10 -> ATM0/1/0.2

»
Cette chaîne contient donc

:
-
le nom du routeur («

7500_UTC

»),
-
la date et l’heure («

2002-05-13 10:44:36.324

»),
-
l’adresse source («

195.221.156.8

»),
-
l’adresse destination («

195.134.210.10

»),
-
le protocole («

TCP

»),
-
le port source («

61255

»),
-
le port destination («

80

»),
-
le nombre de paquets («

P

: 6

»),
Christophe Fillot -
06/10/2005
40
/
86
Collecteur IPFlow
-
la taille totale du flux en octets («

S

: 685

»),
-
la durée du flux en ms («

T

: 284

»),
-
l’interface source («

ATM0/1/0.10

»),
-
l’interface destination («

ATM0/1/0.2

»).
Remarque

: la taille de cette chaîne est importante et il est recommandé d’utiliser un terminal
avec un grand nombre de colonnes pour que les flux ne soient pas «

coupé s

» à l’affichage.
Christophe Fillot -
06/10/2005
41
/
86
Collecteur IPFlow
12
Matrices de trafic de sites
12.1
Principe
Les matrices de trafic de sites constituent un moyen simple de comptage du trafic des sites. Il
existe trois modes de comptage

:

Mode «

source

»

: le comptage s’effectue par rapport aux sites sources

;

Mode «

destination

»

: le comptage s’effectue par rapport aux sites destinations

;

Mode «

flow

»

: le comptage s’effectue pour tous les couples (site source, site
destination).
Pour les deux premiers modes, les données recueillies sont donc stockées sous forme de
vecteurs, tandis que le troisième mode génère une matrice de trafic inter-sites.
Les compteurs contiennent trois champs

:

Nombre de flux

;

Nombre de paquets

;

Nombre d’octets.
Une matrice source ou destination est donc de la forme suivante :

Flux
Paquets
Octets
site 1
site 2
site 3
site 4
Pour chaque site on compte le nombre de flux, paquets et octets.
Les matrices «

full-flow

» s ont des matrices biliné aires de la forme

:
site 1
site 2
site 3
site 4
site 1
flux/paquets/octets
site 2
site 3
site 4
Pour chaque couple (site i, site j) on compte le nombre de flux, paquets et octets.
Christophe Fillot -
06/10/2005
42
/
86
Collecteur IPFlow
12.2
Configuration
La configuration d’une matrice est simple

:
site-traffic-matrix <nom_de_matrice> {

mode source|destination|flow;
};
Il est à noter que les matrices incluent des compteurs pour tous les sites

ou couples de sites, il
n’est donc pas nécessaire d’indiquer les sites pour lesquels on souhaite mettre en place un
comptage. Les deux sites ANY et OTHER, créés automatiquement par le collecteur, sont
é galement gé ré s.
Les ré sultats collecté s par une matrice peuvent ensuite être stockés dans des bases RRDTool.
12.3
Exemple d’utilisation
Imaginons un ré seau ré gional fournissant un accès Internet à trois Universités A, B et C, ainsi
qu’à d’autres sites (Lycées, etc.). On souhaite connaître la part de trafic de chacune des deux
université s A et B é mis vers Internet, ainsi que le trafic total pour les université s.
Christophe Fillot -
06/10/2005
43
/
86
Collecteur IPFlow
La configuration du collecteur serait la suivante

:
site Universite_A {

networks {

195.1.1.0/24;

195.1.2.0/24;

};
};
site Universite_B {

networks {

193.128.1.0/24;

193.128.2.0/24;

};
};
site Universites {

contains {

Universite_A;

Universite_B;

};
};
site-traffic-matrix Comptage_Internet {

mode source;
};
router Cisco7200
{

! Accès Internet sur ATM0/0/0.1

interface ATM0/0/0.1 {

rule-output Sortie_Internet;

};
};
rule Sortie_Internet {

term 1 {

source ANY;

destination ANY;

site-traffic-matrix Comptage_Internet;

};
};
La matrice «

Comptage_Internet

» comptabilisera donc le trafic en provenance des sites
Universite_A, Universite_B, Universites, ANY et OTHER.
Il est donc simple à partir de cette matrice de déterminer la proportion du trafic des universités
par rapport au trafic total (donné par les compteurs du site ANY).
Il est important de garder à l’esprit qu’une adresse IP peut appartenir à plusieurs sites, et donc
que plusieurs sites peuvent voir leurs compteurs augmenter pour une même adresse IP.
Dans l’exemple ci-dessus, la réception de trafic en provenance du réseau 195.1.1.0/24
provoquerait la mise à jour des compteurs pour les sites

: Universite_A, Universites et ANY.
12.4
Enregistrement sur disque
Il est possible d’enregistrer le contenu des matrices dans un fichier sur disque au moyen d’un
channel de type «

STM

».
Christophe Fillot -
06/10/2005
44
/
86
Collecteur IPFlow
Exemple de configuration

:
site-traffic-matrix matrice {

mode flow;

flush-interval 60;

channel fichier_stm;
};
channel fichier_stm {

mode source;

filename «

essai-stm.log

»;
};
La directive «

flush-interval

» indique que la matrice doit être écrite dans le fichier toutes les
60 secondes. La directive «

channel

» indique le fichier STM à utiliser. A chaque fois que la
matrice est é crite, une section est créée dans le fichier binaire de sortie, cela offre ainsi la
possibilité de connaître l’évolution de la matrice au cours du temps. Rappelons qu’une seule
matrice peut ê tre é crite par fichier STM.
Si l’on souhaite é crire la matrice avec une grande pé riode (par ex. toutes les heures ou tous les
jours), il peut être utile d’employer la synchronisation pour mettre à jour plus fréquemment le
fichier de sortie. Par rapport à une é criture «

normale

», le collecteur mettra à jour la dernière
section é crite (sans en cré er de nouvelle), cette section é tant marqué e comme «

partielle

».
Prenons par exemple la configuration suivante