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 NmapC'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 TcpdumpTcpdump 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 EtherealContrairement à "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 :
|
 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 :
[root@phoenix /]# netstat -taupe | sort
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante 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 LsofPour 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 ? 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 :
[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 :
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 PingIl 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 :
[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 TracerouteCette 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 ? ) 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 msAnalysons tout ceci :
.II-2-9 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 ! |
|
