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 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 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 ?![]()
[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 ? ![]() [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 WhoLa 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) <-- 11Les flèches ("<-- [un nombre]") ont été rajoutées pour plus de clarté dans les explications. Nous voyons ici:
[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... ![]() A ceci près que, lorsque l'on change d'utilisateur via la commande "su" :
[olivier@phoenix /]$ su - Password: [root@phoenix /]# who -m olivier pts/2 Aug 3 12:53 [root@phoenix /]# whoami root II-2-10 NslookupUn 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. > exitDans cet exemple, une fois le programme lancé (1ère commande) :
II-2-11 HostAu 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.1Cette 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.1On 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 msLe 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
![]() 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 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 ! |
![]() ![]() ![]() |
![]() |
![]() ![]() |
|
Site de référence : http://olivieraj.free.fr/ | Last modified: Sun Jun 19 20:30:45 CEST 2005 |