Exploration de la configuration réseau

Exploration de la configuration réseau

par Anne

Ou lorsque votre manchot se met à communiquer avec le monde entier

Avant propos

Ce document se veut être un document synthétique qui vous permettra de répondre aux questions suivantes :

• Quelle est ma configuration réseau local et distant ?
• Quels sont les services réseaux configurés sur ma machine ?
• Quels sont les principaux outils de diagnostic réseau sur ma machine ?

Attention : la liste des commandes fournies n'est pas exhaustive et plutôt orientée sur des distributions Redhat / Mandrake. Quelques précisions sont toutefois apportées concernant Debian et Slackware pour les plus grosses différences (merci à Prae et ses connaissances Debian)

Ma configuration réseau

Le hostname

Le nom de machine, ou hostname en bon français, est extrêmement important et a des conséquences non seulement sur la configuration réseau mais aussi sur le fonctionnement (ou dysfonctionnement) du serveur X et donc de l'interface graphique.

• afficher le hostname : la commande hostname
  
• modifier le hostname : il suffit de modifier les fichiers suivants :
  /etc/sysconfig/network (sur Redhat et Mandrake), /etc/HOSTNAME (sur slackware), /etc/hostname (sur Debian), et /etc/hosts.
• utilisation du hostname avec X Window : le fonctionnement du serveur X se fonde sur la variable d'environnement DISPLAY. exemple :
  anne@pingu-~# echo $DISPLAY
  :0
  A gauche des ":", on trouve le hostname, ici sous-entendu : localhost ou 127.0.0.1, soit la machine locale. A droite, on trouve le numéro de serveur X et parfois le numéro d'écran.
  Attention : toute modification du hostname en cours de fonctionnement sous interface graphique risque fort de vous faire perdre la main.
  

L'adressage IP

Pour connaître l'adressage IP de la machine, quelle que soit la nature du réseau, une commande à connaitre : ifconfig

la commande vous retourne quelque chose comme ça :

eth0  Lien encap:Ethernet  HWaddr 00:10:5A:DA:D3:47
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:2006397 errors:0 dropped:0 overruns:0 frame:0
      TX packets:1863082 errors:0 dropped:0 overruns:0 carrier:0
      collisions:3679 lg file transmission:100
      RX bytes:1283974990 (1224.4 Mb)  TX bytes:590947572 (563.5 Mb)
      Interruption:10 Adresse de base:0xe800

eth1  Lien encap:Ethernet  HWaddr 52:54:05:F5:BB:9B
      inet adr:192.168.0.3  Bcast:192.168.0.255  Masque:255.255.255.0
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:1841782 errors:0 dropped:0 overruns:0 frame:48
      TX packets:1984028 errors:0 dropped:0 overruns:0 carrier:0
      collisions:6607 lg file transmission:100
      RX bytes:579039163 (552.2 Mb)  TX bytes:1261892485 (1203.4 Mb)
      Interruption:9 Adresse de base:0xe400

lo    Lien encap:Boucle locale
      inet adr:127.0.0.1  Masque:255.0.0.0
      UP LOOPBACK RUNNING  MTU:16436  Metric:1
      RX packets:442 errors:0 dropped:0 overruns:0 frame:0
      TX packets:442 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 lg file transmission:0
      RX bytes:278720 (272.1 Kb)  TX bytes:278720 (272.1 Kb)

ppp0  Lien encap:Protocole Point-à-Point
      inet adr:213.41.132.215  P-t-P:62.4.16.248  Masque:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
      RX packets:2001693 errors:2006395 dropped:0 overruns:0 frame:0
      TX packets:1858378 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 lg file transmission:3
      RX bytes:1238624343 (1181.2 Mb)  TX bytes:549766984 (524.2 Mb)

Les informations fournies par la commande :

eth0, ppp0, lo...	nom de l'interface réseau
HWaddr	adresse MAC ou matérielle
inet adr	adresse IP liée à l'interface réseau
Bcast	adresse de broadcast
Masque	masque de réseau
UP	état de l'interface réseau - un 1er élément de diagnostic d'une panne réseau (non fonctionnement : DOWN)
MTU	taille maximum des trames physiques
RX / TX packets	nombre de paquets arrivés à destination, perdus ou non reçus à cause de débordements (arrivent de manière trop rapide pour pouvoir être traités par le noyau) - autre élément de diagnostic notamment lorsque les transmissions deviennent très lentes voire inexistantes.
collisions	se produit lorsque 2 machines émettent en même temps sur le réseau. Il n'y a pas lieu de s'inquiéter tant que le rapport (nombre de paquets total / nombre de collisions) reste inférieur à 30%.

Pour de plus amples informations concernant le fonctionnement de l'adressage IP, lire l'article sur [../reseau/lan.php3#configreseaucarte TCP/IP].

Dans quels fichiers trouver la configuration IP ?

• configuration de la (ou les) carte(s) réseau : les principaux fichiers de configuration se situent dans /etc/sysconfig/network-scripts pour Redhat et Mandrake, ou dans /etc/rc.d pour slackware ou /etc/networks. Les fichiers s'appellent respectivement ifcfg-ethx (ou x est le numéro d'instance de la carte réseau), inet1 et interfaces.
• configuration du réseau et du routage : un fichier à connaitre, /etc/sysconfig/network pour Mandrake et Redhat, rc.inet1 pour slackware et interfaces pour Debian.
• une astuce pour récupérer uniquement l'IP : ci-dessous un exemple de script pour recupérer votre adresse IP (merci à FRED :) )

root@pingu# cat ifip
 #!/bin/bash
 if [ -z "$1" ]
 then
        IF=`cat`
 else
        IF=$1
 fi
 ifconfig $IF|grep inet|tr -s " "|cut -f3 -d" "|cut -f2 -d:

L'avantage de ce script : il fonctionne soit avec un argument, soit en récupérant la sortie standard.
Exemple :

root@pingu# ifip eth1 192.168.0.3 root@pingu# echo eth1 | ifip 192.168.0.3

Les services réseaux configurés sur ma machine

Service géré par le super démon inetd ou xinetd

(selon la version de la distribution, l'un ou l'autre est utilisé, xinetd étant le plus récent). inetd (ou xinetd) agit comme un standardiste. Dès qu'un client fait appel à un service autorisé, il passe la ligne au dit service.

• inetd : le fichier de configuration à connaître est /etc/inetd.conf. Quand vous ne pouvez pas accéder à votre machine en telnet ou que votre serveur FTP est inaccessible, vérifiez ce fichier. Il est constitué d'une ligne par service du type :

<service_name> <endpoint-type> <protocol> <wait-status> <uid> <server_program> <server-arguments>
avec :
- service_name : nom du service
- endpoint-type : type de socket (stream pour TCP, dgram pour UDP)
- protocol : protocole de transport utilisé
- wait-status : soit l'option est wait et le service est dit mono-thread (une seule connexion par service peut être gérée), soit l'option est nowait et le service est dit multi-thread (chaque requête vers le service génère un nouveau serveur)
- uid : utilisateur sous lequel est lancé le service
- server_program : nom du programme à lancer pour activer le service
- server-arguments : arguments éventuels pour le lancement du service
Exemple : telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd En cas de dysfonctionnement d'un service, vérifier la syntaxe de la ligne. De plus, pour désactiver l'accès à un service il suffit simplement de commenter la ligne le concernant. Pour réactiver un service, il suffit donc de supprimer le # démarrant la ligne.

• xinetd : C'est une version améliorée de inetd. Il permet une configuration plus fine de l'accès aux services (interdiction d'utilisateurs, d'adresses,...). Il n'y a plus un fichier unique mais un fichier /etc/xinetd.conf qui renvoie à un répertoire /etc/xinetd.d. Celui-ci contient un fichier par service configuré.
  
  La cause la plus fréquente de non fonctionnement d'un service c'est la désactivation de celui-ci (désactivation effectuée de base à l'installation du service pour des raisons de sécurité). Il suffit alors d'ouvrir le fichier et de vérifier la valeur de la variable disable qui, par défaut, est yes.
  
  Exemple :

root@pingu# vi /etc/xinetd.d/telnet
service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes
}

Dans ce cas de figure, le service telnet est désactivé. Pour l'activer, 2 étapes :

• 1. Modifier le fichier /etc/xinetd.d/telnet en remplaçant yes par no dans la variable disable.
  2. Relancer xinetd pour la prise en compte de ce nouveau paramètre :
     

root@pingu# ps -ef | grep xinetd
root   973   1  0 Oct09 ?   00:00:00 xinetd -stayalive -reuse -pidfil
root@pingu# kill -HUP 973
root@pingu#

Service tournant en standalone

Standalone : votre service tourne sans être lancé et contrôlé par le super démon inetd (ou xinetd).

• Vérifier l'état d'un service : tous les scripts de lancement se situent dans /etc/rc.d/init.d. Selon le runlevel dans lequel on se situe, le service est arrêté ou démarré. Pour cela, consultez les répertoires /etc/rc.d/rcN.d où N est le numéro de runlevel. Ces répertoires sont constitués de liens symboliques. Si le lien commence par un S, le service est démarré. S'il commence par un K, il est arrêté. Le S ou K est ensuite suivi par un nombre à deux chiffres. Ce nombnre permet de déterminer l'ordre de lancement des scripts (ordre croissant).
  
  La plupart des scripts sont utilisables avec 3 arguments : start pour le démarrer, stop pour l'arrêter et status pour connaitre son état. La plupart des scripts acceptent également l'argument restart pour redémarrer le service (stop puis start ;)

exemple :
- mon serveur Apache ne fonctionne pas.
root@pingu# /etc/rc.d/init.d/httpd status
httpd est arrêté - on démarre le serveur Apache
root@pingu# /etc/rc.d/init.d/httpd start
Démarrage de httpd : [ OK ] - on vérifie l'état du serveur
root@pingu# /etc/rc.d/init.d/httpd status
httpd (pid 14113 14112 14111 14110 14109 14106) en cours d'exécution

• Configurer le démarrage d'un service (cas général, applicable quelle que soit la distribution) : il suffit de créer le script de gestion du service dans /etc/rc.d/init.d puis les liens symboliques de démarrage et d'arrêt dans les répertoires d'état de marche.
  Exemple : je veux que mon service bidule démarre aux niveaux 3, 4 et 5. On va procéder en 2 étapes :
  - création d'un script de gestion des arguments start / stop : /etc/rc.d/init.d/bidule
  - création des liens symboliques suivants :
  

  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc0.d/K05bidule
  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc1.d/K05bidule
  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc2.d/K05bidule
  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc3.d/S95bidule
  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc4.d/S95bidule
  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc5.d/S95bidule
  root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc6.d/K05bidule

• Configurer le démarrage d'un service : la commande chkconfig. Cette commande fort pratique est spécifique aux distributions Redhat et Mandrake. L'ensemble des services est intégré à une base de données gérée par chkconfig. Grâce à cette commande, vous pouvez ajouter / supprimer / modifier les niveaux auxquels sont démarrés ou arrêtés un service.

  Ajout d'un service à la base :
  root@pingu# chkconfig --add service
  
  Suppression d'un service de la base :
  root@pingu# chkconfig --del service

  Configuration des niveaux auxquels le service doit démarrer/s'arrêter :
  root@pingu# chkconfig --level <niveaux> service on|off

  
  Pour tout complément d'information consulter l'article sur [../admin/daemons.php3 la gestion des services].

Les principaux outils de diagnostic réseau

arp

Permet de visualiser et modifier la table arp stockée en cache. La table arp est une table de correspondance entre adresses IP et adresses matérielles (ou MAC). Elle est générée au fur et à mesure grâce au protocole ARP et stockée en cache.

La commande permet de détecter 2 types de problèmes : le fonctionnement au niveau hardwarede la carte et la bonne correspondance entre une adresse IP et une carte réseau au moyen de son adresse MAC. (cf. double attribution d'une adresse IP sur un réseau, spoofing, ...).

Exemple : Vous voulez vérifier que la seconde carte réseau appelée eth1 est opérationnelle. Dans un 1er temps, on va pinger la carte, ce qui va permettre d'alimenter la table arp.

root@pingu# ping 192.168.0.4

Une fois la table alimentée, on vérifie son contenu : la présence de l'adresse IP ET de l'adresse MAC

root@pingu# arp -a
? (192.168.0.4) at 52:54:05:F5:AD:0C [ether] on eth1
? (192.168.0.1) at 00:04:76:8E:B2:90 [ether] on eth1

En cas d'erreur dans la table, il est inutile de pousser plus avant le diagnostic... On est face à un problème matériel (certainement le plus pénible à détecter).

ping

Véritable outil à tout faire, à connaitre absolument ! Il permet de détecter bon nombre de problèmes concernant votre configuration IP : adressage de votre carte réseau (adresse IP, adresse de réseau, routage, configuration de la résolution de nom).

Exemple : Mon réseau ne fonctionne pas. Je vais donc tester l'adresse avec la commande ping
root@pingu# ping 192.168.0.3
PING 192.168.0.5 (192.168.0.5) from 192.168.0.3 : 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable

Plusieurs causes de non-fonctionnement : je vérifie
- que l'adresse IP existe
- que le masque de sous-réseau est cohérent (ifconfig)
- que ma résolution de nom est opérationnelle (/etc/resolv.conf)
- que le routage est correctement configuré (commande route vue plus loin)

Si la commande ping fonctionne alors ce n'est ni un problème matériel, ni un problème de configuration IP. Toutefois le réseau peut subir des dysfonctionnements tout simplement parce qu'il est chargé. On augmente alors la taille des paquets envoyés.

Exemple :

root@pingu# ping -s 128 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 192.168.0.3 : 128(156) bytes of data.
136 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=0.583 ms
136 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=0.598 ms
136 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=0.640 ms
136 bytes from 192.168.0.1: icmp_seq=4 ttl=128 time=0.578 ms

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3008ms
rtt min/avg/max/mdev = 0.578/0.599/0.640/0.038 m

Ceci permet d'approfondir le test. On vérifiera :
- les numéros de séquences (icmp_seq) : ils sont séquentiels et numérotent les paquets envoyés. Une surcharge réseau ou un câblage de mauvaise qualité par exemple entraine la perte de paquets (voir  % loss).
- le temps de transmission (time) : plus il est long, plus le réseau est chargé.

Attention : si vous lancez un ping sur un serveur et que celui-ci ne répond pas, cela ne signifie pas forcément qu'il y ait un problème. En effet, les firewalls peuvent bloquer toute réponse à un ping et faire échouer toute tentative de ping sur eux.

route

Permet d'afficher la table de routage en cache. Une commande équivalente est netstat -r. La commande affiche la table de routage et effectue la résolution de nom dès que possible. Les commandes route -n ou netstat -rn affichent le table de routage sans résolution de nom.

Exemple :

root@pingu# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
loopback1-lns10 * 255.255.255.255 UH 0 0 0 ppp0
thepingu * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default loopback1-lns10 0.0.0.0 UG 0 0 0 ppp0

root@pingu# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
62.4.16.253 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 62.4.16.253 0.0.0.0 UG 0 0 0 ppp0

Pour info : U = routeur installé et opérationnel ; G = passerelle distante ; H = destination est un hôte et non un réseau.

Un examen de la table de routage vous permet de vérifier par exemple que la machine sur laquelle vous travaillez et qui se situe derrière une passerelle a bien une route par défaut qui lui permet d'aller vers l'extérieur (Destination : default).

Vous ne pouvez pas atteindre l'extérieur car vous n'avez pas cette route, 2 solutions :

• vous ajoutez la route pour la session en cours :
  root@pingu# route add default gw adresseIP_de_la_passerelle
• vous modifiez le fichier de configuration du routage de manière à ce que la table contienne la route pour toutes les sessions : /etc/sysconfig/network

Vous ne pouvez pas atteindre l'extérieur car vous avez une route erronée, 2 solutions :

• vous modifiez la route pour la session en cours :
  root@pingu# route del default gw adresseIP_de_la_passerelle_erronée
  root@pingu# route add default gw adresseIP_de_la_passerelle_correcte
• vous modifiez le fichier de configuration du routage de manière à ce que la table contienne la route correcte pour toutes les sessions : /etc/sysconfig/network

traceroute

Vous ne parvenez pas à atteindre une URL ou un poste donné... La commande traceroute, comme son nom l'indique, vous établit la route suivie par les paquets de données vers la destination. La route est constituée de tous les routeurs traversés pour arriver à destination.

Exemple :

root@pingu# traceroute 192.168.0.4 traceroute to 192.168.0.4 (192.168.0.4), 30 hops max, 38 byte packets 1 192.168.0.4 (192.168.0.4) 0.638 ms 1.016 ms 0.667 ms

Il s'agit d'une machine locale. Elle est située sur le même réseau, aucun routeur n'est traversé, l'adresse de destination est donc atteinte directement.

root@pingu# traceroute lea-linux.org
traceroute to lea-linux.org (80.67.179.10), 30 hops max, 38 byte packets
1 loopback1-lns103-tip-telehouse.nerim.net (62.4.16.253) 152.218 ms 51.991 ms 48.179 ms
2 hsrp1-telehouse.nerim.net (62.4.16.9) 77.410 ms 48.695 ms 66.830 ms
3 feth0-0-julo.nerim.net (62.4.16.37) 135.323 ms 55.336 ms 47.656 ms
4 placenet.freeix.net (213.228.3.223) 48.269 ms 144.190 ms 54.287 ms
5 charon.placenet.org (80.67.178.242) 115.933 ms 58.049 ms 55.553 ms
6 web.t2.tuxfamily.net (80.67.179.10) 1079.365 ms 949.915 ms 578.333 ms

On a ici une adresse située à l'extérieur, tous les routeurs traversés sont indiqués et numérotés.

Là où traceroute devient un outil de diagnostic :

Exemple :

root@pingu# traceroute 192.168.0.5 traceroute to 192.168.0.5 (192.168.0.5), 30 hops max, 38 byte packets 1 192.168.0.3 (192.168.0.3) 2999.119 ms !H 2994.720 ms !H 2999.823 ms !H

Cette fois-ci la commande nous donne des informations différentes : il lui est impossible de trouver la route et il affiche directement la destination avec un des codes d'erreur suivant :

!H : host unreachable
!N : network unreachable
!P : protocol unreachable

netstat

On a déjà vu la commande netstat dans le cadre de l'affichage de la table de routage. La commande permet également d'obtenir des informations détaillées sur l'état des interfaces réseau :

Exemple :

root@pingu# netstat -i
Table d'interfaces noyau
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 20103 0 0 0 18666 0 0 0 BMRU
eth1 1500 0 18453 0 0 0 19879 0 0 0 BMRU
lo 16436 0 466 0 0 0 466 0 0 0 LRU
ppp0 1492 0 20056 20103 0 0 18619 0 0 0 MOPRU

RX	paquets reçus
TX	paquets envoyés (transmis)
OK	paquets reçus/envoyés correctement
ERR	paquets reçus/envoyés avec des erreurs
DRP	paquets reçus/envoyés droppés
OVR	paquets reçus/envoyés retransmis

D'autres options de la commande permettent notamment de visualiser les ports ouverts : netstat -tu (tcp et udp).

Exemple :

root@pingu# netstat -tu
Connexions Internet actives (sans serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 pingu.linuxeries.:32771 132.248.32.28:46503 ESTABLISHED
tcp 0 0 pingu.linuxeries.:32773 64.12.25.127:5190 ESTABLISHED
tcp 0 0 pingu.linuxeries.:33012 217.174.201.37:ircd ESTABLISHED
tcp 0 0 192.168.0.3:netbios-ssn ouaichland:1177 ESTABLISHED
tcp 1231 0 pingu.linuxeries.:34140 193.201.103.96:http ESTABLISHED

tcpdump

Il s'agit d'un outil à réserver aux utilisateurs avertis (il nécessite quelques connaissances sur les protocoles) qui va vous permettre de visualiser les paquets qui circulent vers et/ou à partir d'une interface réseau et ce, en temps réel. C'est à la fois un outil de diagnostic sécurité mais aussi un outil de détection d'anomalies de la configuration IP ou matérielle.

Le fonctionnement en est relativement simple : la commande, sans aucun filtre, permet d'afficher le contenu des paquets et leur description qui transitent sur les interfaces réseau. On peut ensuite élaborer des filtres en fonction des informations recherchées. En voici quelques uns :

• and, or : permet de combiner les filtres
• src, dst : permet de choisir les paquets provenant de / à destination d'une interface réseau.
• host,net, port : filtrer l'affichage des paquets selon un nom de machine, un réseau et/ou un port

De cette manière, vous pouvez utiliser tcpdump si vous essayez de diagnostiquer un problème comme des erreurs de protocole, ou des déconnexions bizarres, ceci car il vous permet de voir en temps réel ce qui arrive sur le réseau. Pour bien utiliser tcpdump, vous devez avoir quelques connaissances sur les protocoles et comment ils fonctionnent, mais il est aussi utile pour quelques services simples comme vérifier que les paquets quittent bien votre machine par le bon port si vous essayez de diagnostiquer des problèmes de routage et pour voir si vous recevez des paquets en provenance de destinations éloignées.

Exemple :

root@pingu# tcpdump -i eth1 port 23
tcpdump: listening on eth1
00:53:58.230287 192.168.0.4.1497 > pingu.linuxeries.org.telnet: S 1074459360:1074459360(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
00:53:58.230477 pingu.linuxeries.org.telnet > 192.168.0.4.1497: S 607927502:607927502(0) ack 1074459361 win 5840 <mss 1460,nop,nop,sackOK> (DF)
00:53:58.230820 192.168.0.4.1497 > pingu.linuxeries.org.telnet: . ack 1 win 17520 (DF)
00:53:58.741012 pingu.linuxeries.org.telnet > 192.168.0.4.1497: P 1:13(12) ack 1 win 5840 (DF) [tos 0x10]
00:53:58.741608 192.168.0.4.1497 > pingu.linuxeries.org.telnet: P 1:7(6) ack 13 win 17508 (DF)
.....

La commande ici nous permet de visualiser les paquets liés à l'activité telnet sur l'interface réseau eth1.

nmap / nmapfe

Il s'agit d'un scanner de ports, à utiliser par simple curiosité ou pour s'assurer du niveau de sécurité effectif sur sa machine. Les options de cette commandes sont très nombreuses et je ne les détaillerai pas ici.

La syntaxe : nmap <options> adresse_IP

Exemple :

# nmap -sS -O 192.168.0.3 Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ ) Interesting ports on (192.168.0.3): (The 1544 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 53/tcp open domain 80/tcp open http 3306/tcp open mysql Remote operating system guess: Linux Kernel 2.4.0 - 2.4.17 (X86) Uptime 2.279 days (since Fri Oct 4 16:24:45 2002) Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds:!

Le scan réalisé ici permet de vérifier quels sont les ports ouverts et donc potentiellement vulnérables (grâce aux options -sS) et le système d'exploitation de la machine testée (grâce à l'option -O).

nmapfe est quant à lui une interface graphique (front end) à nmap.

lsof

La commande lsof (list opened files) permet de lister les fichiers ouverts par les processus tournant sur le système. On peut aussi l'utiliser pour ce qui nous concerne et ce de différentes manières. Là encore le traitement ne sera pas exhaustif.

Voir les fichiers utilisés par un processus réseau :

root@pingu# lsof|grep proftpd
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
proftpd 2136 root cwd DIR 22,2 4096 2 /
proftpd 2136 root rtd DIR 22,2 4096 2 /
proftpd 2136 root txt REG 22,2 236456 244504 /usr/local/sbin/proftpd
proftpd 2136 root mem REG 22,2 89547 1661383 /lib/ld-2.2.5.so
proftpd 2136 root mem REG 22,2 23575 1661394 /lib/libcrypt-2.2.5.so
proftpd 2136 root mem REG 22,2 35340 1661460 /lib/libpam.so.0.75
proftpd 2136 root mem REG 22,2 12102 1661396 /lib/libdl-2.2.5.so
proftpd 2136 root mem REG 22,2 45415 1661416 /lib/libnss_files-2.2.5.so
proftpd 2136 root mem REG 22,2 46117 1661424 /lib/libnss_nisplus-2.2.5.so
proftpd 2136 root mem REG 22,2 89424 1661400 /lib/libnsl-2.2.5.so
proftpd 2136 root mem REG 22,2 16051 1661413 /lib/libnss_dns-2.2.5.so
proftpd 2136 root mem REG 22,2 68925 1661428 /lib/libresolv-2.2.5.so
proftpd 2136 root mem REG 22,21401027 651528 /lib/i686/libc-2.2.5.so
proftpd 2136 root 0u IPv4 19073 TCP *:ftp (LISTEN)
proftpd 2136 root 1u IPv4 19074 TCP *:46000 (LISTEN)
proftpd 2136 root 2u IPv4 19075 TCP *:47000 (LISTEN)
proftpd 2136 root 3u unix 0xc4a6c0a0 16891 socket
proftpd 2136 root 4r REG 22,2 1585 213675 /etc/passwd
proftpd 2136 root 5r REG 22,2 657 212895 /etc/group

COMMAND	nom du processus
PID	numéro de processus (obtenu aussi par la commande ps
USER	identité sous laquelle est lancé le processus
FD	file descriptor - mem : memory-mapped file ; txt : program text (code and data)... plus de détails dans le man de lsof
TYPE	type de noeud (ou inode) - CHR : fichier spécial en mode caractère ; DIR : répertoire... plus de détails dans le man de lsof
DEVICE	major et minor number pour un fichier spécial, protocole...
SIZE	taille du fichier
NODE	numéro d'inode
NAME	nom du fichier ou point de montage

Voir si un fichier est utilisé par un processus réseau
Permet éventuellement de surveiller l'utilisation de fichiers dits sensibles pour la sécurité du système.

Exemple : je veux vérifier les éventuels accès au fichier /etc/passwd

root@pingu# lsof | grep /etc/passwd
proftpd 12586 root 4r REG 22,2 1585 213675 /etc/passwd

Lister les processus liés à un protocole et un port
On obtient alors une fonctionnalité similaire à la commande netstat -a filtrée en fonction d'un protocole et/ou d'un port.
Exemple : je souhaite lister les informations liées au protocole TCP et au port 80 (donc mon serveur web).

# lsof -i tcp:80 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME httpd 1136 root 16u IPv4 1963 TCP *:http (LISTEN) httpd 1139 root 16u IPv4 1963 TCP *:http (LISTEN) httpd 1140 root 16u IPv4 1963 TCP *:http (LISTEN) httpd 1141 root 16u IPv4 1963 TCP *:http (LISTEN) ....

Note
Sur la remarque tout à fait justifiée de Jicé (mais non je ne fayotte pas :), on peut en parallèle à la commande lsof, citer fuser. Elle est vous donnera moins d'informations mais peut vous permettre d'obtenir le même genre de renseignements.

Une restriction toute fois spécifée dans le man de fuser :
" fuser ne dispose de toutes les informations que s'il est exécuté avec les privilèges de root. Ainsi, des fichiers ouverts par des processus appartenant à d'autres utilisateurs n'apparaîtront peut-être pas"

Exemple : je veux savoir quels sont les fichiers utilisés par mon serveur apache :

root@pingu# fuser -auv -n tcp 80
USER PID ACCESS COMMAND
80/tcp root 1136 f.... httpd
root 1139 f.... httpd
root 1140 f.... httpd
root 1141 f.... httpd
root 1142 f.... httpd
root 1144 f.... httpd
root 1145 f.... httpd
root 1146 f.... httpd
root 1147 f.... httpd
root 6434 f.... httpd

Le problème ici est que httpd fonctionne avec l'identité apache et non root. D'où le manque d'informations sur les fichiers utilisés.

resolv.conf

Ce fichier permet la configuration d'un client DNS. C'est lui qui permet l'utilisation de serveurs DNS pour la résolution de noms en adresse IP (ce qui vous permet par exemple de taper une URL dans un navigateur et non une adresse IP). Un fichier mal configuré vous empêchera notamment de surfer.

Rappel de la syntaxe :

root@pingu# cat /etc/resolv.conf
domain nom_de_domaine
nameserver adresseIP_DNS_Primaire
nameserver adresseIP_DNS_Secondaire

Attention : nameserver est un mot-clé à recopier tel que.domain contient le nom de domaine du provider qui vous a fourni les DNS ou celui de votre domaine, si vous disposez d'un serveur DNS.

telnet

On connait telnet en tant qu'outil prise de contrôle à distance. Ce n'est pas là sa seule utilité, il est aussi très utile pour établir un diagnostic et vérifier le fonctionnement ou non d'un service en se connectant sur son port. Il permet également de vérifier la validité d'une règle de firewall.

La syntaxe : telnet <adresse IP ou nom de machine> <numéro de port du service à tester>

Exemple :
Je souhaite vérifier le bon fonctionnement de mon service ftp. Après vérification dans /etc/services, je sais que le port correspondant au serveur ftp est le 21.

• 1er cas de figure :
  

root@pingu# telnet 192.168.0.3 21
Trying 192.168.0.3...
Connected to 192.168.0.3.
Escape character is '^]'.
220 ProFTP Linuxerie's Server Ready
La connexion est réussie, le serveur est opérationnel. 
 

• 2e cas de figure :
  

root@pingu# telnet 192.168.0.3 21
Trying 192.168.0.3...
telnet: connect to address 192.168.0.3: Connexion refused

La connexion est impossible, le service n'est pas disponible.

whois

Vous avez récupéré des informations sous forme d'IP ou de nom dans vos logs ou sur une sortie écran de tcpdump, vous voulez savoir qui se cache derrière cette IP.

Exemple:

root@pingu# whois lea-linux.org
Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.

Domain Name: LEA-LINUX.ORG
Registrar: GANDI
Whois Server: whois.gandi.net
Referral URL: http://www.gandi.net
Name Server: NS1.TUXFAMILY.NET
Name Server: NS2.TUXFAMILY.NET
Updated Date: 11-feb-2002


Last update of whois database: Tue, 8 Oct 2002 05:00:23 EDT

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars.
.....

autres outils d'identification

Ci-dessous, trois autres outils qui vous permettront de faire de la résolution de nom ou de la résolution inverse avec des informations complémentaires sur l'identité du serveur :

• nslookup : utilisable en mode interactif ou non, à partir d'une adresse IP ou d'un nom.
  
  Exemple :
  

root@pingu# nslookup
> lea-linux.org
Server:         194.149.160.9
Address:        194.149.160.9#53
Non-authoritative answer:
Name:   lea-linux.org
Address: 80.67.179.10

La commande vous donne les infos suivantes :

• • Server, Address : le serveur DNS qui effectue la résolution
  • Non-authoritative answer : si la ligne est présente, cela signifie que l'adresse était présente dans le cache du serveur DNS.
  • Name, Addresse : résultat de la commande
• dig : la commande nslookup tombant en désuétude, elle est remplacée aujourd'hui de plus en plus par dig. Elle dispose de fonctionnalités supplémentaires.
  
  Exemple :
  

# dig www.lea-linux.org

 ; DiG 9.2.0 www.lea-linux.org
 ;; global options: printcmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25724
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

 ;; QUESTION SECTION:
;www.lea-linux.org. IN A

 ;; ANSWER SECTION:
www.lea-linux.org. 86400 IN A 80.67.179.10

 ;; AUTHORITY SECTION:
lea-linux.org. 604800 IN NS ns1.tuxfamily.net.
lea-linux.org. 604800 IN NS ns2.tuxfamily.net.

 ;; ADDITIONAL SECTION:
ns1.tuxfamily.net. 86400 IN A 80.67.177.2
ns2.tuxfamily.net. 86400 IN A 80.67.179.2

 ;; Query time: 325 msec
 ;; SERVER: 194.149.160.9#53(194.149.160.9)
 ;; WHEN: Fri Oct 11 00:12:30 2002
 ;; MSG SIZE rcvd: 132

La sortie standard de la commande est sensiblement la même avec quelques précisions supplémentaires (durée de réalisation de la requête, DNS du domaine...) 

• host : sans option, la sortie est extrêmement simple, il s'agit uniquement de la résolution.
  
  Exemple :
  

# host www.lea-linux.org
 www.lea-linux.org has address 80.67.179.10

Le Mot de la fin

Mon objectif en écrivant cette contribution était de débroussailler quelque peu la jungle des outils de configuration et diagnostic réseau. J'espère qu'il vous donnera envie d'approfondir encore plus ce domaine passionnant.
N'hésitez pas à m'envoyer vos remarques ou ajouts éventuels.

Remerciements

Un grand merci à Fred, Prae et Jice qui ont accepté de prendre du temps pour relire et corriger cet article (Jice : je promets de faire des efforts en html :p)

@ Retour à la rubrique Réseau

Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Anne le 09/09/2002.

Copyright

© 09/09/2002 Anne Nicolas