Table des matières Page précédente Page suivante Version mono-page

II-2 Outils d'analyse et de détection

En fait, quel que soit le rôle que l'on joue, attaquant ou défenseur, on utilise des outils similaires. Car toute personne qui voudra protéger son réseau aura à coeur de le tester lui-même !! Et tout intrus voudra d'abord se protéger lui-même, soit des gens comme lui, soit du défenseur...

II-2-1 Nmap

C'est l'outil par excellence de l'intrus. Il rentre dans la catégorie des "scanner de ports" ("port scanner" en anglais), c'est à dire qu'il va tester un ensemble de ports sur la machine cible, et déterminer lesquels sont ouverts ou fermés. Son exécution est très rapide, et de plus il peut tester automatiquement tout un intervalle d'adresse IP. Bref, si vous avez un logiciel serveur tournant sur votre machine, cet outil le trouvera.

Nmap a une seconde fonctionnalité intéressante, c'est l'identification par empreinte. C'est à dire qu'avec les quelques paquets d'informations que votre machine pourra envoyer à l'intrus, comme par exemple pour dire "ce port est fermé", nmap pourra déterminer quel est le système d'exploitation qui tourne sur votre machine. Quelle importance cela peut il avoir me direz vous ? Très simple : chaque système d'exploitation, voire chaque version de systèmes d'exploitation, possède des vulnérabilités connues ou inconnues. Ainsi, en sachant quel système tourne sur votre machine, l'intrus pourra lancer des attaques spécifiques, afin de prendre rapidement la main dessus. Donc, moins on donne d'information à l'intrus, mieux on se porte.

Nmap peut être lancé ou non en temps qu'utilisateur classique. Par défaut, nmap ne teste qu'un certain nombre de ports (ceux sur lesquels il pense qu'il va trouver des choses intéressantes), et uniquement en TCP.

Voyons par exemple ce que donne la commande nmap lancée depuis pirate.internet.net sur phoenix1.internet.net :
[intrus@pirate /]$ nmap phoenix1.internet.net

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on phoenix1.internet.net (10.0.0.1):
(The 1590 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp
23/tcp     open        telnet
25/tcp     open        smtp
53/tcp     open        domain
80/tcp     open        http
110/tcp    open        pop-3
111/tcp    open        sunrpc
139/tcp    open        netbios-ssn
443/tcp    open        https
3306/tcp   open        mysql
6000/tcp   open        X11

Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
Hummm ça, c'est que du bonheur pour notre pirate ! Autant de ports ouverts sur une machine, il va y avoir des choses intéressantes à faire... On notera au passage que nmap est très sympathique car il nous indique quel est probablement le type de serveur (exemple : http) qui se trouve derrière chaque port (exemple : 80/tcp).

Note importante à propos d'UDP : Par défaut, "nmap" ne teste que les ports TCP. Vous pouvez lui faire tester des ports UDP, mais il faut que vous lanciez "nmap" en temps que root, et en plus avec l'option "-sU". Enfin, si la machine cible est un Linux, les temps de réponses seront très long, car la cible attendra un temps de plus en plus long pour toute connexions UDP faites sur des ports fermés. Ce n'est pas un bug, c'est une mesure de protection de Linux contre le port scanner... Donc à moins que nous n'ayez le temps, ne faite pas un nmap sur tous les ports UDP d'une machine cible, mais seulement sur des ports susceptibles d'être intéressants. Par exemple : "nmap phoenix1.internet.net -sU -p 137" pour tester le port UDP de Samba / NetBIOS.

II-2-2 Tcpdump

Tcpdump est un "sniffeur de trames réseau", c'est à dire qu'il est capable d'afficher à l'utilisateur toutes les trames réseaux qui "passent devant" une carte réseau. Et entre autre, les trames réseaux qui ne sont pas destinées à cette machine. Ce n'est pas très sympathique ce genre de choses, car cela permet par exemple de récupérer un mot de passe réseau, ou une page HTML contenant des informations sensibles (numéro de carte de crédit par exemple).

Ceci est une capture par tcpdump lors de l'envoi d'une requête ping de pirate.internet.net sur phoenix1.internet.net ("ping -c 1 phoenix1.internet.net") :
[root@phoenix /]# tcpdump -i eth1
tcpdump: listening on eth1
19:31:25.170017 arp who-has phoenix1.internet.net tell pirate.0.0.10.in-addr.arpa
19:31:25.170079 arp reply phoenix1.internet.net is-at 0:4:75:df:d8:bd
19:31:25.170232 pirate.0.0.10.in-addr.arpa > phoenix1.internet.net: icmp: echo request (DF)
19:31:25.170355 phoenix1.internet.net > pirate.0.0.10.in-addr.arpa: icmp: echo reply
Comme ce type de commande est excessivement sensible pour la sécurité d'un réseau, en général elle ne peut se lancer qu'en temps que root.

Enfin, il est à noter que le lancement de tcpdump demande au système de passer la carte réseau en mode "promiscuous", ce qui a pour effet de laisser une trace dans le log de Linux (le fichier "/var/log/messages"). Cela indique donc à l'administrateur de la machine que des paquets de données ont pu être récupérés illégalement...
[root@phoenix /]# grep promiscuous /var/log/messages
Jun 28 19:31:21 phoenix kernel: device eth1 entered promiscuous mode
Jun 28 19:31:28 phoenix kernel: device eth1 left promiscuous mode

II-2-3 Ethereal

Contrairement à "tcpdump", "ethereal" est un outil en mode graphique. Mais il fait exactement le même travail que tcpdump. Dans l'exemple ci-contre, on voit la capture des trames lors d'un "nmap phoenix1.internet.net" lancé sur pirate.internet.net.

Au passage cette capture nous montre des choses très intéressantes :
  • On voit bien les demandes de connexions ("SYN") de pirate.internet.net (10.0.0.66), suivi des "ACK/SYN" de phoenix1.internet.net (10.0.0.1), puis le "ACK" en réponse de pirate.internet.net. Bref, c'est toute la poignée de main ("handshake" en anglais) qui se déroule ici.
  • On remarque que l'ordre des ports qui sont scannés est croissant, ce qui n'est pas très discret. Mais en fait on peut demander à nmap de faire ses requêtes dans un ordre aléatoire, afin d'être moins visible.
  • De même, on voit que les ports sont testés très rapidement (à peine 1/10000ème de seconde pour chaque port), certes sur un réseau rapide (100 Mbit/s). La machine cible est littéralement assaillie. Mais là encore, nmap peut se révéler être plus discret, en espaçant la durée entre chaque connexion.
Ethereal : Capture d'un nmap
Ethereal : Capture d'un nmap

II-2-4 Netstat

"Netstat" est un outil que l'on va utiliser du coté du défenseur. Il indique l'état des connexions réseaux en cours. Expliquer toutes les options de "netstat" serait trop long, aussi ne va t'on s'intéresser qu'à quelques unes :
  • -t : Indique les connexions TCP.
  • -u : Indique les connexions UDP.
  • -a : Affiche toutes ("all") les connexions, y comprit celle des serveurs en attente de connexion.
  • -e : Affiche le nom de l'utilisateur qui a lancé le programme qui utilise ce port.
  • -p : Seul le root peut utiliser cette option. Elle indique quel est le PID (Process Identifiant) et le nom du programme utilisant le port.
Ainsi, la commande "netstat -taupe" (combinaison mnémotechnique des options "-t", "-u", "-a", "-e", et "-p") permet d'un seul coup d'oeil de visualiser les programmes en mémoire qui utilisent le réseau IP :
[root@phoenix /]# netstat -taupe | sort
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse dist Etat   Utilisatr Inode  PID/Program name
tcp        0      0 *:ftp                   *:*          LISTEN root      830048 18450/xinetd
tcp        0      0 *:http                  *:*          LISTEN root      829583 17979/httpd2
tcp        0      0 *:https                 *:*          LISTEN root      829580 17979/httpd2
tcp        0      0 localhost.sky.ne:domain *:*          LISTEN named     835771 18847/
tcp        0      0 localhost.sky.net:rndc  *:*          LISTEN named     835779 18847/
tcp        0      0 localhost.sky.:webcache *:*          LISTEN privoxy   587136 6407/
tcp        0      0 *:mysql                 *:*          LISTEN root      839103 19199/
tcp        0      0 phoenix1.in:netbios-ssn *:*          LISTEN root      839012 19128/smbd
tcp        0      0 phoenix1.interne:domain *:*          LISTEN named     835775 18847/
tcp        0      0 phoenix.sky:netbios-ssn *:*          LISTEN root      839013 19128/smbd
tcp        0      0 phoenix.sky.net:domain  *:*          LISTEN named     835773 18847/
tcp        0      0 *:pop3                  *:*          LISTEN root      830047 18450/xinetd
tcp        0      0 *:smtp                  *:*          LISTEN root      827316 17081/
tcp        0      0 *:sunrpc                *:*          LISTEN root      839095 19208/
tcp        0      0 *:telnet                *:*          LISTEN root      830049 18450/xinetd
tcp        0      0 *:x11                   *:*          LISTEN root      3742   1593/X
udp        0      0 *:bootps                *:*                 root      839078 19191/dhcpd
udp        0      0 localhost.sky.ne:domain *:*                 named     835770 18847/
udp        0      0 *:netbios-dgm           *:*                 root      839024 19138/nmbd
udp        0      0 *:netbios-ns            *:*                 root      839023 19138/nmbd
udp        0      0 phoenix1.in:netbios-dgm *:*                 root      839030 19138/nmbd
udp        0      0 phoenix1.interne:domain *:*                 named     835774 18847/
udp        0      0 phoenix1.int:netbios-ns *:*                 root      839029 19138/nmbd
udp        0      0 phoenix.sky:netbios-dgm *:*                 root      839033 19138/nmbd
udp        0      0 phoenix.sky.:netbios-ns *:*                 root      839031 19138/nmbd
udp        0      0 phoenix.sky.net:domain  *:*                 named     835772 18847/
udp        0      0 *:sunrpc                *:*                 root      839094 19208/

II-2-5 Lsof

Pour avoir un résultat utilisable, "Lsof" (LiSt Open File) est un outil qui doit se lancer avec les droits root. Il indique quels sont les fichiers ouverts sur le système. Des fichiers ? Mais de quoi parle t'il ? On est ici pour parler de réseau, non ? Smiley Mais oui, on peut s'intéresser bien sûr aux fichiers classiques tel qu'on les connaît dans d'autres OS (comme un fichier texte, une image, une librairie, un programme, etc...) mais on peut aussi utiliser cette commande pour voir l'activité réseau. Comment ? Simple, sous Linux, tout ce que manipule l'OS est vu comme un fichier, les connexions IP entre autre. Dans notre cas, les paramètres intéressants de "lsof" sont :
  • -i : Restreint la recherche aux seuls "fichiers" de connexion IP.
  • -P : Converti le numéro de port (exemple : 80) en son nom équivalent (exemple : http).
Ainsi, la commande "lsof -Pi" (combinaison des options "-i" et "-P") nous donne :
[root@phoenix /]# lsof -Pi | sort
COMMAND   PID    USER   FD   TYPE DEVICE SIZE NODE NAME
dhcpd   19191    root    6u  IPv4 839078       UDP *:67
httpd2  17979    root    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  17979    root    4u  IPv4 829583       TCP *:80 (LISTEN)
httpd2  17987  apache    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  17987  apache    4u  IPv4 829583       TCP *:80 (LISTEN)
httpd2  17988  apache    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  17988  apache    4u  IPv4 829583       TCP *:80 (LISTEN)
httpd2  17989  apache    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  17989  apache    4u  IPv4 829583       TCP *:80 (LISTEN)
httpd2  17990  apache    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  17990  apache    4u  IPv4 829583       TCP *:80 (LISTEN)
httpd2  17991  apache    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  17991  apache    4u  IPv4 829583       TCP *:80 (LISTEN)
httpd2  18591  apache    3u  IPv4 829580       TCP *:443 (LISTEN)
httpd2  18591  apache    4u  IPv4 829583       TCP *:80 (LISTEN)
master  17081    root   11u  IPv4 827316       TCP *:25 (LISTEN)
mysqld  19199   mysql    3u  IPv4 839103       TCP *:3306 (LISTEN)
mysqld  19215   mysql    3u  IPv4 839103       TCP *:3306 (LISTEN)
mysqld  19216   mysql    3u  IPv4 839103       TCP *:3306 (LISTEN)
named   18847   named   10u  IPv4 835771       TCP localhost.sky.net:53 (LISTEN)
named   18847   named   11u  IPv4 835772       UDP phoenix.sky.net:53
named   18847   named   12u  IPv4 835773       TCP phoenix.sky.net:53 (LISTEN)
named   18847   named   13u  IPv4 835774       UDP phoenix1.internet.net:53
named   18847   named   14u  IPv4 835775       TCP phoenix1.internet.net:53 (LISTEN)
named   18847   named   17u  IPv4 835779       TCP localhost.sky.net:953 (LISTEN)
named   18847   named    8u  IPv4 835778       UDP *:32803
named   18847   named    9u  IPv4 835770       UDP localhost.sky.net:53
named   18848   named   10u  IPv4 835771       TCP localhost.sky.net:53 (LISTEN)
named   18848   named   11u  IPv4 835772       UDP phoenix.sky.net:53
named   18848   named   12u  IPv4 835773       TCP phoenix.sky.net:53 (LISTEN)
named   18848   named   13u  IPv4 835774       UDP phoenix1.internet.net:53
named   18848   named   14u  IPv4 835775       TCP phoenix1.internet.net:53 (LISTEN)
named   18848   named   17u  IPv4 835779       TCP localhost.sky.net:953 (LISTEN)
...
Le résultat a été tronqué, car trop long. On remarque que par rapport à la précédente commande, la liste des ports est plus longue. Bug ou erreur ? En fait, non : "lsof" affiche les forks et les threads qui utilisent les fichiers, alors que "netstat" n'affiche que les processus pères.

II-2-6 Fuser

"Fuser" (File user) est un peu comme "lsof", à savoir qu'il se base sur les fichiers pour déterminer les connexions IP ouvertes. Pour l'usage qui nous intéresse, nous ne verrons qu'un seul paramètre :
  • -v [type de ports] : Affiche les ports ouverts du type [type de ports]. Exemple : "80/tcp" pour les port TCP 80.
On voit que "fuser" n'est adapté qu'à donner des informations sur un nombre limité de ports, et qu'en aucun cas, il n'indique de lui même les ports ouverts. Par rapport à "lsof", il est donc un peu moins intéressant. A noter que tout comme "lsof", "fuser" nécessite les droits root.

La commande "fuser 80/tcp" nous donne :
[root@phoenix /]# fuser -v 80/tcp

                     USER        PID ACCESS COMMAND
80/tcp               root      17979 f....  httpd2
                     root      17987 f....  httpd2
                     root      17988 f....  httpd2
                     root      17989 f....  httpd2
                     root      17990 f....  httpd2
                     root      17991 f....  httpd2
                     root      18591 f....  httpd2
Et "fuser 67/tcp 67/udp 80/tcp" nous donne :
[root@phoenix /]# fuser 67/tcp 67/udp 80/tcp
67/udp:              19191
80/tcp:              17979 17987 17988 17989 17990 17991 18591
Ici, les ports 80 en TCP et 67 en UDP sont ouverts. Par contre, le port 67 TCP n'est pas ouvert.
Pour information, le port 67 est celui du DHCP, et il ne fonctionne en général qu'en UDP, et non TCP.

II-2-7 Ping

Il est sans doute inutile de s'étendre sur la commande "ping", tellement elle est connue. "Ping" permet de vérifier la présence d'une machine en lui envoyant un paquet ICMP, auquel la machine cible doit répondre par un paquet ICMP équivalent. La commande affiche alors des informations intéressantes : Adresse IP, durée de transmission, etc...

Utilisé à de mauvaises fins, "ping" peut :
  • Saturer une machine, en la noyant sous un flot de paquets, ce qui a pour effet de consommer la bande passante et d'augmenter la charge CPU. Une utilisation particulière basé sur la technique du "ping" est l'attaque DDOS (Distributed Deny Off Service, ou "attaque distribuée par refus de service"), qui peut ralentir énormément une machine, voire un réseau...
  • Donner des informations sur la machine cible. Même si une machine n'exécute aucun serveur (voir le paragraphe suivant), "ping" peut indiquer à l'intrus que sa cible est quand même en fonctionnement, ce qui peut être un premier pas pour exciter sa curiosité... Par défaut, les machines ne sont pas configurées pour ne pas répondre aux ping. Dans le chapitre suivant, nous verrons comment configurer la machine pour qu'elle ne réponde pas à "ping", et aux autres paquets ICMP en général.
Utilisation de la commande "ping" sur www.google.fr :
[olivier@phoenix /]$ ping www.google.fr
PING www.google.com (216.239.39.99) 56(84) bytes of data.
64 bytes from 216.239.39.99: icmp_seq=1 ttl=49 time=519 ms
64 bytes from 216.239.39.99: icmp_seq=2 ttl=49 time=229 ms
64 bytes from 216.239.39.99: icmp_seq=3 ttl=49 time=229 ms
64 bytes from 216.239.39.99: icmp_seq=4 ttl=49 time=229 ms
64 bytes from 216.239.39.99: icmp_seq=6 ttl=49 time=229 ms
64 bytes from 216.239.39.99: icmp_seq=7 ttl=49 time=229 ms
64 bytes from 216.239.39.99: icmp_seq=8 ttl=49 time=219 ms
64 bytes from 216.239.39.99: icmp_seq=10 ttl=49 time=219 ms

--- www.google.com ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9349ms
rtt min/avg/max/mdev = 219.981/263.552/519.507/96.831 ms
Cette commande nous indique que l'adresse IP de "www.google.fr" est "216.239.39.99" (en fait, il y en a plusieurs, et ceci n'est que l'une des adresses de ce site). Par contre, Google doit filtrer une partie des paquets ICMP, ou la connexion doit être mauvaise, car seul 80% des paquets envoyés par Phoenix ont reçu une réponse... Ce sont les aléas d'IP !

II-2-8 Traceroute

Cette commande se base aussi sur ICMP, mais elle est plus intéressante. Elle indique le chemin utilisé par les paquets IP pour aller de votre machine à une machine cible. En plus de cela, elle affiche le temps mis par les paquets pour passer d'un réseau à un autre.

Cette commande est principalement utilisée par les administrateurs réseaux. Elle sert le plus souvent à vérifier la qualité des connexions, ou à déterminer les engorgements dans les réseaux. Cependant, elle peut être aussi utilisée pour remonter la trace d'une machine, et trouver l'origine de sa source.

Du fait de son caractère orienté sur la sécurité, la commande "traceroute" ne peut s'exécuter qu'en temps que root. Cependant, sur certaines OS ou distributions Linux, ce programme est dit "Set-UID root" ("man chmod" pour plus d'information). C'est à dire que lorsque qu'il est lancé, Linux donne au programme les droits de son propriétaire. Concrètement, lorsque vous lancer un programme qui a de telles capacités, vous devenez temporairement root à la place du root ! (is no good ? Smiley) L'emplacement de ce type de programme est en général en dehors des emplacements classiques de stockages des programmes utilisateurs. Sous Linux, vous le trouverez généralement en "/usr/sbin/traceroute" :
[root@phoenix /]# ls -la /usr/sbin/traceroute
-rwsr-xr-x    1 root     bin         18136 mai  7  2002 /usr/sbin/traceroute*
Ici, c'est le caractère "s" qui indique que le programme est "Set-UID". Et on voit que le programme appartient au root. Donc ce programme est bien "Set-UID root".

Exemple d'utilisation de "traceroute" sur la machine "200.165.134.194" qui a tenté aujourd'hui d'accéder illégalement à ma machine :
[root@phoenix /]# traceroute 200.165.134.194
traceroute to 200.165.134.194 (200.165.134.194), 30 hops max, 38 byte packets
 1  192.168.254.254 (192.168.254.254)  119.244 ms  110.262 ms  109.510 ms
 2  grenoble-3k-1-a5.routers.proxad.net (213.228.10.30)  109.974 ms  109.811 ms  120.138 ms
 3  cbv-6k-1-a7.routers.proxad.net (213.228.3.120)  129.695 ms  119.787 ms  130.286 ms
 4  prs-b2-geth6-0.telia.net (213.248.71.13)  129.895 ms  129.943 ms  119.906 ms
 5  prs-bb1-pos1-2-0.telia.net (213.248.70.5)  129.947 ms  120.188 ms  119.663 ms
 6  ldn-bb1-pos0-2-0.telia.net (213.248.64.157)  130.058 ms  119.730 ms  129.883 ms
 7  ldn-bb2-pos0-0-0.telia.net (213.248.64.162)  149.989 ms  150.124 ms  139.694 ms
 8  nyk-bb2-pos2-3-0.telia.net (213.248.65.38)  220.042 ms  219.873 ms  219.907 ms
 9  nyk-bb1-pos0-0-0.telia.net (213.248.80.1)  189.920 ms  190.519 ms  199.344 ms
10  sl-gw27-nyc-10-0.sprintlink.net (144.232.230.29)  190.289 ms  190.159 ms  189.732 ms
11  sl-bb24-nyc-15-0.sprintlink.net (144.232.7.25)  210.080 ms  199.748 ms  199.883 ms
12  sl-bb21-nyc-6-0.sprintlink.net (144.232.13.186)  189.992 ms  209.842 ms  199.948 ms
13  sl-bb21-atl-11-1.sprintlink.net (144.232.18.69)  220.024 ms  209.990 ms  219.963 ms
14  sl-bb20-orl-14-2.sprintlink.net (144.232.19.170)  239.885 ms  229.955 ms  229.944 ms
15  sl-bb21-orl-15-0.sprintlink.net (144.232.2.146)  230.250 ms  239.882 ms  230.041 ms
16  sl-st21-mia-15-1.sprintlink.net (144.232.20.13)  239.983 ms  229.887 ms  239.914 ms
17  sl-splkt1-3-0.sprintlink.net (144.223.244.78)  349.943 ms  349.903 ms  349.912 ms
18  200.187.128.69 (200.187.128.69)  350.908 ms  349.908 ms  349.933 ms
19  200.223.131.213 (200.223.131.213)  389.949 ms  399.927 ms  390.009 ms
20  PO0-0.BOT-RJ-ROTN-01.telemar.net.br (200.223.131.122)  389.862 ms  399.640 ms  389.948 ms
21  PO6-0.ASGS-BA-ROTN-01.telemar.net.br (200.223.131.73)  390.002 ms  379.775 ms  379.940 ms
22  PO4-0.BVG-PE-ROTN-01.telemar.net.br (200.223.131.17)  390.056 ms  389.770 ms  390.063 ms
23  PO10-0.BVG-PE-ROTD-02.telemar.net.br (200.223.131.22)  399.816 ms  389.723 ms  389.966 ms
24  200.164.204.198 (200.164.204.198)  399.975 ms  389.775 ms  390.692 ms
25  200.164.234.34 (200.164.234.34)  1379.447 ms  2529.793 ms  1259.899 ms
26  200.165.134.194 (200.165.134.194)  1809.956 ms  2259.911 ms  2969.929 ms
Analysons tout ceci :
  • La première ligne est le point de départ de la commande "traceroute", c'est à dire Phoenix. Remarquez qu'il s'agit d'une adresse IP privée, ce qui n'est pas anormal pour une connexion point à point.
  • La 2nde ligne montre ma propre adresse IP sur Internet. Comme je n'utilise qu'un modem RTC pour me connecter, cette adresse IP change tout le temps. Donc inutile de vous acharner sur cette adresse afin de pirater ma machine, ce ne sera pas la mienne qui se trouvera à cette adresse IP lorsque vous lirez ces lignes Smiley. Au passage, on voit que ma machine se trouve dans la région de Grenoble (en Isère / France / Europe / Terre / Système solaire / Voie lactée), et que mon fournisseur d'accès est Free (Proxad.net <-> Free), mais cela, vous deviez déjà vous en douter...
  • La ligne 4 indique que l'on sort du réseau de Free, pour rentrer sur le réseau de TeliaSonera, qui est un groupe Européen de transmissions réseaux.
  • En 6 nous sommes à Londre (indicatif "lnd" <-> Londre).
  • En 8 nous sommes à New-York (indicatif "nyk" <-> New-York).
  • En 10, nous entrons dans le réseau de SprintLink, un autre grand réseau de communications. Les lignes suivantes nous font descendre la coté Est des États-Unis pour Miami. Afin de déterminer le chemin emprunté, on s'aide des règles d'appellation des routeurs de ce réseau.
  • En 20, nous sommes maintenant au Brésil !
  • En 23, cela se précise, nous somme dans la région de Pernambuco, sur la pointe Est du Brésil.
  • Enfin, la ligne 26 nous indique que nous avons atteint notre but. Il est difficile de déterminer quelle est la nature de cette machine, et si ou non c'est un "script kiddy" qui tue le temps à faire du port scanning, au lieu d'aller sur la plage (quoi que là bas, c'est l'hiver, et l'eau n'est peut-être qu'à seulement 25 degrés... Smiley). Mais comme c'est le port 137 de ma machine (le partage de fichiers) qui l'intéressait, j'ose espérer que ce n'était pas une société, en mal de recherche de secrets industriels !
Pour aller plus en avant dans ma recherche, il faudrait que je contacte l'administrateur de ce réseau, et obtenir plus d'informations. Quoiqu'il en soit, que les responsables de ce réseau qui lisent ce document ne se sentent pas l'esprit de justiciers, et n'aillent pas lui casser la tête !! Je me contenterai de la destruction pure et simple de sa machine, ainsi que de l'immolation de ces CD illégaux Smiley.

II-2-9 Who

La commande "who" ("qui" en français) indique quels sont les utilisateurs connectés sur la machine au moment où la commande est lancée. C'est très pratique afin de détecter si un utilisateur externe est en train d'utiliser la machine en même temps que vous (et auquel cas, vous auriez peut-être intérêt à l'en chasser au plus vite !).

Le paramètre "-u" est tout particulièrement intéressant, car il indique depuis combien de temps l'utilisateur est inactif.
[olivier@phoenix /]# who -u
root     vc/1         Aug  3 12:52 05:53        2486                      <--  1
olivier  vc/2         Aug  3 18:33 00:12        2487                      <--  2
olivier  :0           Aug  3 12:52   ?          2778                      <--  3
olivier  pts/0        Aug  3 12:53 05:52        2971                      <--  4
olivier  pts/1        Aug  3 12:53   .          2986                      <--  5
olivier  pts/2        Aug  3 12:53 00:04        3015                      <--  6
olivier  pts/3        Aug  3 12:53   .          3017                      <--  7
root     pts/4        Aug  3 13:07 05:38        4434 (:0)                 <--  8
olivier  pts/5        Aug  3 18:32 00:13       15908                      <--  9
olivier  pts/6        Aug  3 18:39 00:06       16145                      <-- 10
apache   pts/7        Aug  3 18:39 01:56       16180 (paradise.sky.net)   <-- 11
Les flèches ("<-- [un nombre]") ont été rajoutées pour plus de clarté dans les explications.

Nous voyons ici:
  • Les lignes 1 et 2 indiquent des connexions par les utilisateurs "root" et "olivier" sur respectivement les consoles virtuels (en mode texte, "vc" = "virtual consol") 1 et 2. Ceci sont des accès physiques à la machine. On peut accéder à ces consoles en utilisant les touches Ctrl+Alt+F1, Ctrl+Alt+F2, ..., Ctrl+Alt+F6.
  • La ligne 3 indique une connexion sur le "DISPLAY:0", c'est à dire sur le serveur X11 (graphique) ":0". Une machine sous Linux peut faire tourner jusqu'à 4 serveurs X11, accessible via les touches Ctrl+Alt+F7, Ctrl+Alt+F8, Ctrl+Alt+F9 et Ctrl+Alt+F10. C'est sur cette connexion que s'affiche les nombreuses fenêtres des applications graphiques que nous utilisons.
  • Les lignes 4 à 11 indiquent des connexions à des pseudo terminaux (pts" = "pseudo TTY"). Ce sont en faite tout simplement des interfaces en ligne de commande, qui permettent de taper des commandes Linux. On appelle cela généralement des "shell". Oui, 8 "shell" cela fait beaucoup, mais j'aime bien cela... Smiley
  • La ligne 8 est un peu particulière, car elle indique que l'utilisateur en question (root) a utilisé un DISPLAY qui ne lui appartient pas (":0") pour ouvrir son "pts/4". C'est tout à fait normal, car le DISPLAY en question a été ouvert par l'utilisateur "olivier" à la ligne 3. Dans ce cas précis, il s'agit d'un "/usr/X11R6/bin/rxvt" qui est lancé, c'est à dire un terminal en mode graphique.
  • Enfin, la ligne 11 indique une connexion qui n'est pas faite physiquement par l'utilisateur situé derrière le clavier, mais par un utilisateur se trouvant sur la machine paradise.sky.net. Et que cet utilisateur s'est connecté en temps que "apache". Ceci par contre est anormal, car cet utilisateur n'est pas supposé pouvoir se connecter à distance, donc cela veut dire qu'il y a un problème avec la sécurité de la machine... En effet, telle que l'indique la commande "who", cet connexion sur "pts/7" peut lancer des commandes Linux, et ce depuis une machine distante... Bref, cela ne présage rien de bon...
  • De gauche à droite, les colonnes nous indiquent :
    • Le nom de l'utilisateur (exemple : "apache")
    • La méthode de connexion (terminal virtuel, DISPLAY, pseudo-terminal,...) (exemple : "pts/7")
    • L'heure de connexion (exemple : "Aug 3 18:39", soit le 3 août à 18h39)
    • Le temps depuis lequel l'utilisateur n'a pas été actif (exemple : "01:56", soit près de 2h...)
    • Le numéro de process (PID pour "Process ID") qui utilise le lieu de connexion (exemple : "16180"). En faisant un "kill [numéro du PID]" (exemple : "kill 16180"), on pourra déconnecter l'utilisateur, à la condition d'avoir au moins autant de droit sur le système que lui. Dans le cas de notre exemple, il faudra lancer cette commande en temps que root.
    • Le nom de l'hôte d'où vient la connexion (exemple : "paradise.sky.net")
A noter que la commande "who -m"
[olivier@phoenix /]# who -m
olivier  pts/2        Aug  3 12:53
donne un résultat semblable à celui de la commande "whoami"
[olivier@phoenix /]# whoami
olivier
c'est à dire, qu'elle retourne le nom de l'utilisateur qui a lancé la commande "who". C'est utile, dans la cas où l'on ne sait plus très bien qui l'on est... Smiley.

A ceci près que, lorsque l'on change d'utilisateur via la commande "su" :
  • "who -m" retourne le nom de l'utilisateur initial, qui est bien celui qui a ouvert le shell.
  • alors que que "whoami" retourne le nom de l'utilisateur qui possède les droits d'utilisation dans le shell.
[olivier@phoenix /]$ su -
Password:
[root@phoenix /]# who -m
olivier  pts/2        Aug  3 12:53
[root@phoenix /]# whoami
root

II-2-10 Nslookup

Un outil très pratique lorsque l'on recherche l'origine d'une connexion est "nslookup". La plupart du temps, les outils d'analyse à votre disposition vous donnerons une adresse IP comme source d'une connexion. Cependant, rien n'est moins impersonnel qu'une adresse IP, si ce n'est une autre adresse IP.

Nslookup permet d'associer une adresse IP à un nom de machine, et vice-versa. Lorsqu'on le lance, ce programme agit comme un interpréteur de script interactif, c'est à dire qu'il va attendre de vous des questions, et il vous donnera des réponses. Il utilise les techniques liées aux DNS (Domain Name Serveur) pour trouver ces informations.
[olivier@phoenix /]$ nslookup
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
> 62.147.13.241
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
241.13.147.62.in-addr.arpa      name = strasbourg-2-a7-62-147-13-241.dial.proxad.net.

Authoritative answers can be found from:
13.147.62.in-addr.arpa  nameserver = ns1.proxad.net.
13.147.62.in-addr.arpa  nameserver = ns0.proxad.net.
ns0.proxad.net  internet address = 212.27.32.2
ns1.proxad.net  internet address = 212.27.32.130
> server
Default server: 127.0.0.1
Address: 127.0.0.1#53
Default server: 213.228.0.168
Address: 213.228.0.168#53
Default server: 212.27.32.5
Address: 212.27.32.5#53
> phoenix
Server:         127.0.0.1
Address:        127.0.0.1#53

phoenix.sky.net canonical name = phoenix0.sky.net.
Name:   phoenix0.sky.net
Address: 192.168.0.1
> 192.168.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

1.0.168.192.in-addr.arpa       name = phoenix0.0.168.192.in-addr.arpa.
> exit
Dans cet exemple, une fois le programme lancé (1ère commande) :
  • [62.147.13.241] On demande des informations sur la machine dont l'adresse IP est "62.147.13.241". Le programme répond "strasbourg-2-a7-62-147-13-241.dial.proxad.net". De ceci, on retiendra que:
    • la machine se trouve sur le réseau du fournisseur d'accès Free (c'est le nom de "proxad.net" en France)
    • c'est une machine connectée à Internet via un modem : "-2-a7-62-147-13-241.dial"
    • la machine est vraisemblablement située à Strasbourg : "strasbourg-..."
  • [server] La seconde commande a pour but de savoir quel sont le ou les DNS utilisé(s) par le programme pour résoudre les recherches. On voit ici que 3 DNS sont utilisés : Un DNS tournant sur la machine elle-même (127.0.0.1, ce qui est assez rare sur une machine personnelle) et les 2 DNS de Free (213.228.0.168 et 212.27.32.5). A noter que lors de la 1ère commande, c'est le DNS de la machine (127.0.0.1) qui a retourné l'information. Donc soit cette information était stockée en local (ce qui n'est pas le cas), soit il a lui-même fait la recherche sur Internet (en interrogeant les DNS de Free).
  • [phoenix] On demande ici de trouver le nom de la machine "phoenix", c'est à dire nous même. On trouve plusieurs informations intéressantes :
    • Nslookup à rajouté de lui-même l'extension ".sky.net" à la recherche, car c'est bien une machine de notre réseau local dont nous voulons des informations.
    • Il nous dit que phoenix.sky.net n'est pas le vrai nom de la machine, mais qu'il s'agit d'un alias sur son nom (une sorte de surnom). Et que le vrai nom de la machine est en fait phoenix0.sky.net.
    • Enfin, le programme nous donne l'information que nous attendons, à savoir l'adresse IP de la machine "phoenix0.sky.net" : "192.168.0.1".
  • [192.168.0.1] Cette fois ci, nous demandons l'opération inverse : A partir d'une adresse IP du réseau local, nous voulons le nom de la machine. Nslookup nous répond "phoenix0.0.168.192.in-addr.arpa". Remarquez qu'il donne le vrai nom de la machine ("phoenix0") et non son alias "phoenix"...
  • [exit] Enfin, nous sortons du programme en tapant la commande "exit", ce qui nous permet de retourner dans notre shell Linux.
Mais ceci n'est qu'un aperçu des possibilités de la "nslookup". Comme pour les autres programme, le "man nslookup" vous donnera beaucoup plus d'informations que cette brève explication.

II-2-11 Host

Au tout début de la précédente explication, vous n'avez peut-être pas fait attention à ceci :
[olivier@phoenix /]$ nslookup
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
Et oui, "nslookup" est un "vieux" programme, qui est remplacé par quelques concurrents plus récents. Pourquoi s'ennuyer donc avec "nslookup" alors ? Tout simplement parce que c'est un terme assez générique, que l'on utilise couramment pour indiquer le fait que l'on veut faire une correspondance adresse IP <-> nom de machine.

Donc comme vous devez commencer à vous en douter, "host" est une commande similaire à "nslookup", qui effectue lui aussi ce type de conversion. Mais contrairement à son prédécesseur, il ne génère pas une interface interactive lorsqu'il se lance.
[olivier@phoenix /]$ host phoenix
phoenix.sky.net is an alias for phoenix0.sky.net.
phoenix0.sky.net has address 192.168.0.1
Cette commande nous renvoie le nom complet de la machine ("phoenix.sky.net"), son nom réel ("phoenix0.sky.net") et son adresse IP("192.168.0.1")
[olivier@phoenix /]$ host phoenix 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

phoenix.sky.net is an alias for phoenix0.sky.net.
phoenix0.sky.net has address 192.168.0.1
On demande cette fois ci la même information, mais en précisant à "host" d'utiliser le serveur "127.0.0.1". Il retournera la même information, en plus d'informations sur le serveur de nom.
[olivier@phoenix /]$ host -v phoenix 127.0.0.1
Trying "phoenix.sky.net"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54222
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;phoenix.sky.net.               IN      A

;; ANSWER SECTION:
phoenix.sky.net.        43200   IN      CNAME   phoenix0.sky.net.
phoenix0.sky.net.       43200   IN      A       192.168.0.1

;; AUTHORITY SECTION:
sky.net.                43200   IN      NS      ns.sky.net.

;; ADDITIONAL SECTION:
ns.sky.net.             43200   IN      A       192.168.0.1

Received 105 bytes from 127.0.0.1#53 in 0 ms
Le paramètre "-v" passé à la commande "host" permet de la rendre plus verbeuse, c'est à dire plus bavarde... L'explication ici est assez rébarbative, mais on apprend quelques petites choses intéressantes, comme par exemple que "phoenix" est le serveur de nom de son réseau ("ns.sky.net. 43200 IN A 192.168.0.1").

Jouons maintenant un peu avec Internet :
[olivier@phoenix /]$ host www.google.fr 193.252.19.4
;; connection timed out; no servers could be reached
[olivier@phoenix /]$ host www.google.fr 212.27.32.5
www.google.fr is an alias for www.google.akadns.net.
www.google.akadns.net has address 216.239.59.99
  • La première commande demande à "host" de recherche l'adresse IP de "www.google.fr", mais en utilisant un des serveur DNS de Wanadoo ("193.252.19.4"). Mais ceux-ci sont configurés afin de ne pas répondre à des demandes de DNS à propos de machines qu'ils n'hébergent pas, et dont les demandeurs viennent de l'extérieur de leur réseau (et à plus fort raison de celui d'un concurrent !). Donc la recherche échoue, et "host" indique qu'il ne peut pas accéder au serveur DNS indiqué.
  • La seconde commande fait une recherche en forçant le DNS secondaire de Free ("212.27.32.5") à répondre. On y voit que le nom de domain renvoie sur un serveur de cache bien connu qu'est "akadns.net", et dont l'adresse IP est "216.239.59.99"
Pour une utilisation un peu plus poussée de la commande "host", je vous recommande comme précédemment la lecture du "man host". Par contre, si vous recherchez plus d'informations sur les techniques et l'utilisation du DNS, je vous invite à lire l'excellente explication (Français) que Christian Caleca a écrit à ce sujet.

II-2-12 La commande "tail -f"

Ce qu'il y a de bien avec Linux, c'est qu'il est bavare. J'entend par là que sous Linux, il est habituelle que les applicatios stockent plein d'informations sur ce qu'elle sont en train de faire, ce qui permet de voir facilement si tout se passe bien ou non. Mais plutôt que d'inonder l'écran de boîte des dialogues de messages, les applications Linux stockent ces informations dans des fichiers au format texte (ce qui rend leur analyse on ne peut plus facile). En générale, ces fichiers sont stockés dans le repertoire "/var/log". Le plus connu de ces fichiers est le "/var/log/messages", dans lequels le kernel Linux, et par défaut les autres applications importantes qui gravitent autour du kernel, y écrit abondamment.

Oui, mais si il faut ouvrir ce fichier avec un editeur de texte à chaque fois que quelque chose d'important ou d'anormal se passe, cela peut devenir assez pénible. Dd'autant qu'il n'est pas rare qu'un tel fichier fasse quelques mega-octets. D'autant qu'en général, seul la fin du fichier nous intéresse, car il contient les derniers messages.

Pour cela, on peut utiliser la commande "tail". Lancé sans paramètre supplémentaire qu'un nom de fichier, elle affiche les 10 dernières lignes du fichier :
[root@phoenix /]# tail /var/log/messages
Sep 19 12:29:04 phoenix nmbd[2375]: [2003/09/19 12:29:04, 0] libsmb/nmblib.c:send_udp(756)
Sep 19 12:29:04 phoenix nmbd[2375]:   Packet send failed to 10.255.255.255(138) ERRNO=Operation not permitted
Sep 19 12:32:04 phoenix nmbd[2375]: [2003/09/19 12:32:04, 0] libsmb/nmblib.c:send_udp(756)
Sep 19 12:32:04 phoenix nmbd[2375]:   Packet send failed to 10.255.255.255(138) ERRNO=Operation not permitted
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] libsmb/nmblib.c:send_udp(756)
Sep 19 12:32:54 phoenix nmbd[2375]:   Packet send failed to 192.168.0.255(137) ERRNO=Operation not permitted
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] nmbd/nmbd_packets.c:send_netbios_packet(172)
Sep 19 12:32:54 phoenix nmbd[2375]:   send_netbios_packet: send_packet() to IP 192.168.0.255 port 137 failed
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] nmbd/nmbd_namequery.c:query_name(256)
Sep 19 12:32:54 phoenix nmbd[2375]:   query_name: Failed to send packet trying to query name WORKGROUP<1d>
[root@phoenix /]#
On peut par contre lui demander d'afficher qu'un certain nombre de lignes. Par exemple, "tail -2 /var/log/messages" n'affiche que les 2 dernières lignes du fichier /var/log/messages :
[root@phoenix /]# tail -2 /var/log/messages
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] nmbd/nmbd_namequery.c:query_name(256)
Sep 19 12:32:54 phoenix nmbd[2375]:   query_name: Failed to send packet trying to query name WORKGROUP<1d>
[root@phoenix /]#
Mais le plus intéréssant des paramètres qui nous intéresse est le "-f" :
[root@phoenix /]# tail -f /var/log/messages
Sep 19 12:29:04 phoenix nmbd[2375]: [2003/09/19 12:29:04, 0] libsmb/nmblib.c:send_udp(756)
Sep 19 12:29:04 phoenix nmbd[2375]:   Packet send failed to 10.255.255.255(138) ERRNO=Operation not permitted
Sep 19 12:32:04 phoenix nmbd[2375]: [2003/09/19 12:32:04, 0] libsmb/nmblib.c:send_udp(756)
Sep 19 12:32:04 phoenix nmbd[2375]:   Packet send failed to 10.255.255.255(138) ERRNO=Operation not permitted
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] libsmb/nmblib.c:send_udp(756)
Sep 19 12:32:54 phoenix nmbd[2375]:   Packet send failed to 192.168.0.255(137) ERRNO=Operation not permitted
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] nmbd/nmbd_packets.c:send_netbios_packet(172)
Sep 19 12:32:54 phoenix nmbd[2375]:   send_netbios_packet: send_packet() to IP 192.168.0.255 port 137 failed
Sep 19 12:32:54 phoenix nmbd[2375]: [2003/09/19 12:32:54, 0] nmbd/nmbd_namequery.c:query_name(256)
Sep 19 12:32:54 phoenix nmbd[2375]:   query_name: Failed to send packet trying to query name WORKGROUP<1d>
Contrairement aux autres exemples ci-dessus, on voit que la commande "tail" ne rend pas la main à l'utilisateur (il n'y a pas le "[root@phoenix /]#" a la fin) . Car tant qu'elle est lancée, elle affichera en temps réel les nouvelles lignes rajoutées au fichier. Cette commande "tail -f" est donc très pratique, car on peut lire immédiatement les messages qu'envoit le kernel, et donc se rendre compte facilement si quelque chose ne vas pas. Pour sortir de la commande "tail -f", un simple CTRL+C suffit, et vous renverra à la ligne de commande.

Nous verrons un peu plus loin l'utilisation du système de LOG de "netfilter" : "tail -f" est alors très utile, notament lors de l'écriture des scripts de firewall, afin de voir quels sont les paquets bloqués par "netfilter".

Pour ceux qui, comme moi, aiment bien voir s'afficher les logs (car c'est toujours très instructif), j'ai écris un petit programme de script qui permet de surveiller très facilement certains fichiers de log. Il s'appelle rxvt_log.sh et lance tout simplement un "rxvt" (c'est un "terminal X", comme "xterm", "konsole", etc...) dans lequel s'execute un "tail -f" sur un fichier. Tel qu'il est fournit, il permet d'afficher un certain nombre de fichiers de log, mais libre à vous de le modifier pour en afficher d'autres !

La seul contrainte de ce programme, c'est qu'il faut le lancer avec les droits nécéssaire pour accéder au fichier de log que vous voulez. Ainsi, si vous voulez surveille le "/var/log/messages", comme celui-ci n'est généralement pas accessible aux utilisateurs standards, il vous faudra lancer "rxvt_log.sh" en temps que "root", ou que membre du groupe "adm" :
rxvt_log
Rxvt_log sur le /var/log/messages
TODO TODO TODO
[olivier@phoenix scripts]$ ls -la /var/log/messages
-rw-r-----    1 root     adm       1164314 sep 19 14:15 /var/log/messages

II-2-13 Autres informations

Évidement, ceci n'est qu'une petite liste des outils Linux de surveillance de l'activité réseau. Il en existe beaucoup d'autres, et encore plus qui seront développés dans l'avenir. La recherche sur Internet ou sur des sites spécialisés dans la sécurité informatique vous en apprendra beaucoup plus que ces quelques lignes. Nous avons majoritairement vu ici des outils en mode ligne de commande, mais il en existe des équivalents en mode graphique.

Pour ce qui est de l'utilisation plus complète de ces programmes, je vous invite à consulter leurs documentations respectives. Les commandes "man netstat", "info nmap", etc... sont vos meilleurs amis !

Table des matières Page précédente Page suivante Version mono-page
Valid XHTML 1.0! Valid CSS!
Site de référence : http://olivieraj.free.fr/ Last modified: Sun Jun 19 20:30:45 CEST 2005