Analysez l’activité réseau

Vous avez appris à surveiller l'activité du système via l'analyse des fichiers de traces
et des processus. Dans ce dernier chapitre, je vous propose de nous intéresser à
l'activité réseau du serveur.

1. Nous utiliserons les commandes ss et lsof pour relever les ports en écoute
de la machine,
2. Nous explorerons les outils bmon et iptraf qui affichent l'activité en temps réel
des interfaces,
3. Nous lancerons quelques captures de trames avec l'utilitaire tcpdump et nous
les afficherons dans l'analyseur de paquets wireshark
Relevez les services réseau mis à disposition par le système
Pour héberger un service réseau, votre serveur Linux doit disposer d'au moins une
adresse IP accessible sur un réseau. Chaque service réseau pourra alors ouvrir un
port en écoute et l'associer à cette adresse IP.

Pour plus d'informations sur le sujet, consultez les cours :

 Concevez votre réseau TCP/IP
 Gérez votre serveur Linux et ses services
Imaginons que l'unique adresse IP de votre serveur soit 192.168.1.100. Tous les
services réseaux de ce serveur seront associés à cette adresse IP.
Par exemple :

 Un service httpd(serveur web) serait alors disponible en standard sur le port

80 de l'adresse IP tel que : 192.168.1.100:80
 Un service mysqld(base de données) serait éventuellement disponible en
standard sur le port 3306 de l'adresse IP tel que : 1 92.168.1.100:3306
Linux fournit des commandes permettant de relever la liste des services réseau
actuellement disponibles sur le serveur.

La commande ss
La commande ss (pour "socket statistics") est fournie par le
package iproute2 installé en standard sur les distributions.
Les plus anciens d'entre nous auront connu netstat, mais le paquet net-tools, qui
reste disponible, n'est plus maintenu et n'est donc plus installé par défaut sur les
distributions.
Cette commande dispose de nombreuses options. Je vais simplement vous indiquer
celles que j'utilise le plus fréquemment.

Par ailleurs, étant donné que tout est fichier sous Linux, vous pourrez remarquer
que chaque "socket" dispose de son "file descriptor" (fd sur les lignes résultat).
La commande lsof
La commande lsof(pour "list open files"), très connue également (fournie par le
package lsof du même nom), s'attache à relever tous les fichiers ouverts. Il est
donc possible de retrouver ces éléments avec cette commande.
Voyons tout de suite comment utiliser ss et lsof pour afficher la liste des ports
ouverts en écoute sur le système. Nous verrons ensemble comment interpréter les
résultats de cette commande. C’est parti !
Observez l’activité réseau sur les interfaces
Maintenant que vous savez relever les processus en écoute sur le serveur, il est
temps de vous pencher sur l'analyse de l'activité réseau sur les cartes du serveur.

Encore une fois, Linux fourmille d'outils permettant de vous aider à ce sujet. Je vais
vous proposer deux outils que j'utilise fréquemment :

1. bmon (pour "bandwidth monitor") vise à afficher le trafic en émission et

réception sur les cartes. Il s'installe avec le package du même nom bmon.
2. iptraf propose l'affichage des connexions de manière plus détaillée, en
indiquant notamment les sources ou les destinations relatives au trafic. Il
s'installe avec le package du même nom :iptraf.
Citons encore quelques outils d'analyse de trafic en temps réel :

 Nload,
 iftop(très connu aussi celui-là),
 slurm,
 tcptrack,
 speedometer(il a l'avantage de présenter, en mode terminal, une vue assez
colorée du trafic sur une interface)
 et j'en oublie sûrement...
Allez, je vous propose d'installer et d'exécuter bmon puis iptraf pour relever l’activité
réseau sur les interfaces. On y va :
Capturez le trafic réseau d’une interface
Enfin, dernier point de ce chapitre : il vous sera sûrement nécessaire de capturer le
trafic d'une interface.

Pour cela, il existe un utilitaire en mode terminal très connu également, qui se
nomme tcpdump. Il s'installe avec le package portant le même nom.
Vous allez constater que cet outil peut être très très verbeux ! Il est important de bien
spécifier les options de capture en fonction de votre besoin.

Avec tcpdump, vous avez aussi la possibilité d’enregistrer votre capture dans un
fichier, qui sera ensuite lisible par wireshark, le très célèbre analyseur de trames
réseau.
Dans la vidéo ci-dessous, je vous propose :

 d'installer ces deux outils,

 de capturer un trafic réseau spécifique à un besoin, par exemple, l’analyse
des flux d’un service Web,
 et de les importer dans wireshark pour compléter leur analyse.
C’est parti !

En résumé
 La commande ss permet de relever les ports ouverts et les processus
associés sur un serveur Linux
 Complétée par la commande lsof, on peut référencer tous les fichiers qui
étaient ouverts par des processus en écoute
  Grâce à bmon et iptraf, on peut lire le trafic entrant et sortant en temps réel
sur les cartes réseau de la machine
 tcpdump et wireshark permettent de capturer et d’analyser ce trafic
Ce chapitre vient clôturer ce cours d’initiation à l'administration d'un serveur Linux.
J'espère qu'il vous a plu et je vous dis à bientôt sur OpenClassrooms !

TP : Un ping pong avec une drôle de balle…

L'objectif de ce TP est d'utiliser la surveillance réseau et les outils évoqués dans la

partie 4 du cours pour analyser un peu plus dans le détail le trafic généré par les
fameuses commandes ping.
Allez, on sort sa loupe de Sherlock et c'est parti !

Étape 1
Connecté sur votre serveur Linux (console physique ou terminal) vérifiez que vous
pouvez lancer une commande ping sur une autre machine joignable sur votre réseau
local. (Dans l'exemple ici, je lance la commande ping sur la machine qui héberge la
VM Linux).
seb@debServer:~$ ping 172.20.10.2
PING 172.20.10.2 (172.20.10.2) 56(84) bytes of data.
64 bytes from 172.20.10.2: icmp_seq=1 ttl=64 time=0.401 ms
64 bytes from 172.20.10.2: icmp_seq=2 ttl=64 time=0.574 ms
64 bytes from 172.20.10.2: icmp_seq=3 ttl=64 time=0.479 ms
64 bytes from 172.20.10.2: icmp_seq=4 ttl=64 time=0.528 ms
^C
--- 172.20.10.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3728ms
rtt min/avg/max/mdev = 0.401/0.495/0.574/0.064 ms
seb@debServer:~$
Vous allez constater que sous Linux, la commande ping ne s'arrête pas toute
seule… Pour la stopper, utilisez le signal SIGINT vu pendant le cours et la
combinaison de touche CTRL+c (heureusement pour nous que cette commande
écoute ce signal !).
Étape 2
À l'aide d'une connexion secondaire (seconde console physique ou nouvelle session
via un terminal), sous le compte root, lancez la commande tcpdump en indiquant en
paramètre le protocole utilisé par la commande ping: icmp. Et vérifiez depuis la
première connexion en relançant la commande ping que vous parvenez à relever le
trafic icmp. Vous devriez obtenir quelque chose ressemblant à ça :
root@debServer:~# tcpdump icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144
bytes
17:17:00.011565 IP 172.20.10.13 > 172.20.10.2: ICMP echo request, id 4673,
seq 1, length 64
17:17:00.012004 IP 172.20.10.2 > 172.20.10.13: ICMP echo reply, id 4673,
seq 1, length 64
17:17:01.270579 IP 172.20.10.13 > 172.20.10.2: ICMP echo request, id 4673,
seq 2, length 64
17:17:01.271290 IP 172.20.10.2 > 172.20.10.13: ICMP echo reply, id 4673,
seq 2, length 64
17:17:02.294303 IP 172.20.10.13 > 172.20.10.2: ICMP echo request, id 4673,
seq 3, length 64
17:17:02.294849 IP 172.20.10.2 > 172.20.10.13: ICMP echo reply, id 4673,
seq 3, length 64
17:17:03.321463 IP 172.20.10.13 > 172.20.10.2: ICMP echo request, id 4673,
seq 4, length 64
17:17:03.322027 IP 172.20.10.2 > 172.20.10.13: ICMP echo reply, id 4673,
seq 4, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Idem ici, tcpdump écoute SIGINT, donc un petit CTRL+c pour l'arrêter.
Étape 3
Réitérez cette opération en indiquant un fichier d'enregistrement pour tcpdump, par
exemple/tmp/traficICMP.dump. Capturez ainsi quelques paquets ICMP (entre 4 et 8
par exemple) tels que :
root@debServer:~# tcpdump icmp -w /tmp/traficICMP.dump
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), snapshot length
262144 bytes
^C6 packets captured
6 packets received by filter
0 packets dropped by kernel
Étape 4
Transférez cette trace réseau sur un poste de travail disposant de wireshark. Dans
l'exemple ci dessous, je transfère ce fichier sur un poste Ubuntu via scp, tel que :
root@debServer:~# scp /tmp/traficICMP.dump seb@172.20.10.2:/home/seb/
The authenticity of host '172.20.10.2 (172.20.10.2)' can't be established.
ECDSA key fingerprint is
SHA256:XD+IBQsATgzNTJ0PVKyOkCYKHekM9b408PvSA7cGF1o.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.20.10.2' (ECDSA) to the list of known
hosts.
seb@172.20.10.2's password:
traficICMP.dump 100%
708 1.2MB/s 00:00
root@debServer:~#
Étape 5
Ouvrez la trace avec Wireshark telle que :
La visualisation d’une trace réseau sur Wireshark
Étape 6
Dépliez les différentes couches OSI de la trace et notamment la couche ICMP,
pouvez-vous relever les données envoyées par la commande ping? Quelle taille fait
le paquet ICMP ?
Détail des paquets ICMP dans une trace réseau
Étape 7
Sélectionnez le paquet de données ICMP et faites un clic droit / show packet bytes
(ou CTRL+SHIFT+O ) afin de visualiser ces données :
Contenu du paquet ICMP
En gros la commande ping envoie quelques caractères tels
que!"#$%&'()*+,-./01234567au format hexadécimal, voilà une balle originale pour
faire un ping/pong 😁
Étape 8
Cherchez dans les options de la commande ping comment passer la taille du paquet
ICMP à 128 bits et effectuez une nouvelle capture. Que devient notre balle de ping
pong ?
Réponse : Elle est complétée entre autres avec les caractères de l’alphabet en
minuscule et majuscule !
 Contenu du paquet ICMP

Surveiller l’activité d’un système Linux

Vous n'avez pas validé ce quiz.

Vous n'avez pas atteint le seuil de validation de cet exercice, c'est-à-dire 70%. Ce n'est pas
très grave car vous pourrez refaire le quiz dans 24h.
Compétences évaluées

 Auditer le système d'un système d'exploitation

 Question 1

Vous cherchez à consulter l'historique des connexions SSH sur le serveur

Linux. En consultant le fichier rsyslog.conf vous obtenez les informations
suivantes :
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
 kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
#user.* -/var/log/user.log
Dans quel fichier devez-vous chercher les connexions SSH ?

/var/log/syslog

/var/log/user.log

/var/log/auth.log

/var/log/kern.log
Dans ce fichier de configuration Rsyslog, Les traces de processus d'authentification
sont écrites sur/var/log/auth.log.
Le fichier /var/log/syslog contient toutes les traces exceptées celles concernant
justement les processus d'authentification.

 Question 2

En lançant la commande suivante :

root@debServer:~# dmesg | grep -i e1000
Vous obtenez le résultat suivant :
[ 0.918415] e1000: Intel(R) PRO/1000 Network Driver
[ 0.918416] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 1.282541] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:46:df:1e
[ 1.282547] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 1.656622] e1000 0000:00:08.0 eth1: (PCI:33MHz:32-bit) 08:00:27:c6:ca:e0
[ 1.656630] e1000 0000:00:08.0 eth1: Intel(R) PRO/1000 Network Connection
[ 1.657825] e1000 0000:00:08.0 enp0s8: renamed from eth1
[ 1.667383] e1000 0000:00:03.0 enp0s3: renamed from eth0
[ 5.335843] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
[ 37.267426] e1000: enp0s8 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
Que pouvez-vous en déduire ?

Attention, plusieurs réponses sont possibles.

o

Le noyau Linux a chargé le pilote de carte réseau générique e1000 .

Il y a 4 cartes réseau sur le serveur : eth0, eth1, enp0s3, enp0s8.

Les débits des cartes réseau sont limités à 10Mb/s.

Les deux cartes réseau enp0s3 et enp0s8 sont connectées.

Les traces indiquent que le noyau Linux a bien chargé le pilote générique de carte
réseau e1000, et qu'il a détecté 2 cartes (eth0 eteth1) renommées ensuite
en enp0s3 et enp0s8. Ces deux cartes réseau sont bien connectées avec une vitesse
reconnue de 1Gb/s.

 Question 3

Dans quel fichier de traces allez-vous trouver les informations concernant les
redémarrages du serveur ?

/var/log/user.log

/var/log/wtmp
Le fichier de trace wtmp contient toutes les informations de connexions et
déconnexions au système ainsi que les traces des redémarrages système.

 Question 4

Le résultat de l'exécution de la commande w est le suivant :

root@debServer:~# w
10:31:05 up 2 min, 2 users, load average: 0,00, 0,00, 0,00
UTIL. TTY DE LOGIN@ IDLE JCPU PCPU QUOI
root tty1 - 10:29 1:45 0.12s 0.04s -bash
seb pts/0 172.20.10.3 10:29 0.00s 0.08s 0.09s sshd: seb [priv]
 Vous pouvez conclure que la première console physique du serveur est
connectée.

Vrai.

Faux.
La première ligne de cette trace vous indique que le compte root est actuellement
connecté depuis la première console physique du serveur et qu'il exécute un
shell Bash.

 Question 5

L'exécution de la commandepsvous donne le résultat suivant :

root@debServer:~# ps -edf | grep seb
seb 589 576 0 10:29 ? 00:00:00 sshd: seb@pts/0
seb 590 589 0 10:29 pts/0 00:00:00 -bash
root 642 594 0 10:35 pts/0 00:00:00 grep seb
Que pouvez-vous déduire de ce résultat ?

Attention, plusieurs réponses sont possibles.

Le compte utilisateur seb est connecté sur un terminal virtuel.

La commande donnant ce résultat a été exécutée avec le compte utilisateur seb.

Le compte utilisateur seb a effectué une élévation de privilèges.

4. La première ligne indique une connexion du compte utilisateur seb via le

service sshd,
5. la seconde ligne indique que le compte utilisateur seb a lancé un shell depuis
un terminal virtuel,
6. la troisième ligne indique que la commande grep seb(correspondante au filtre
de la première commande ps -edf via le pipe linux) est lancée avec le
compte root sur le même terminal virtuel,
 7. donc le compte utilisateur seb a effectué une élévation de privilèges et est
passé root.
 Question 6

Quel objectif avez-vous si vous lancez la commande suivante ?

root@debServer:~# renice +15 878

Vous augmentez la priorité du processus PID=878.

Vous diminuez la priorité du processus PID=878.

La priorité des processus est définie entre -20 et 20 et établie par défaut à 0, en
augmentant cette valeur, vous diminuez la priorité des processus sur le processeur.

 Question 7

Parmi les affirmations suivantes, lesquelles sont vraies ?

Attention, plusieurs réponses sont possibles.

Le signal SIGINT est plus puissant que SIGKILL.

Il vaut mieux utiliser SIGINT que SIGKILL.

La commande kill -9 termine un processus proprement.

Par défaut, un processus écoute le signal SIGINT.

Le moyen le plus propre de terminer un processus est de lui envoyer le signal
SIGINT (#2, CTRL+c ). Dans ce cas, c'est le processus lui-même qui cherche à se
terminer en libérant les ressources qu'il utilise. Le signal SIGKILL donne la
 responsabilité de la terminaison du processus à Init ou Systemd, il est plus violent et
ne pourra pas gérer les ressources de manière optimale.

 Question 8

Que pouvez-vous déduire de la commande suivante ?

root@debServer:~# ss -lptun
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
Process
udp UNCONN 0 0 0.0.0.0:514 0.0.0.0:* users
("rsyslogd",pid=296,fd=6))
udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:* users
("dhclient",pid=331,fd=9))
udp UNCONN 0 0 [::]:514 [::]:* users
("rsyslogd",pid=296,fd=7))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users
("sshd",pid=555,fd=3))
tcp LISTEN 0 128 [::]:22 [::]:* users
("sshd",pid=555,fd=4))

Attention, plusieurs réponses sont possibles.

Au moins une carte réseau n'est probablement pas configurée de manière

statique.

Le serveur héberge une centralisation des traces.

Les cartes réseau ne sont pas configurées en IPv6.

Il n'est pas possible de prendre la main à distance sur ce serveur.

La commande ss indique les ports ouverts sur le serveur Linux. Ici le
processus rsyslogd ouvre les ports 514 en TCP et UPD en IPv4 et IPv6, ce qui
indique une centralisation des traces. Le processus dhclient ouvre le port 68 UDP
ce qui indique un dialogue avec un service DHCP pour configurer une réseau, et le
service sshd ouvre les ports 22 en IPv4 et IPv6 pour permettre la prise en main à
distance sur le serveur.
 Question 9

Parmi les outils suivants, lesquels permettent d'observer le trafic des cartes
réseau du serveur ?

Attention, plusieurs réponses sont possibles.

iptraf

iftop

lsof

bmon

ps
La commande lsof pour "List Open File" permet de consulter tous les fichiers
ouverts par tous les processus Linux. La commande ps permet d'analyser l'activité
des processus sur le processeur.

 Question 10

Votre serveur est équipé des cartes réseau enp0s3 pour le LAN et enp0s8 pour
le WAN et Internet. Quelle commande allez-vous lancer pour enregistrer dans
un fichier de trace le trafic Internet du serveur ?

tcpdump http

o
 tcpdump -i enp0s3 icmp -w capture.log

tcpdump -i enp0s8 http -w capture.log

tcpdump icmp
La commande tcpdump avec l'option -i permet d'indiquer en paramètre la carte
réseau sujette à la capture. Il est possible d'appliquer un filtre sur le protocole en le
passant en paramètre. Enfin l'option -w permet d'indiquer un fichier pour conserver
le trafic.