Les commandes et les écrans ci-dessous ont été vérifiés sur Debian 13 (Trixie) avec sngrep 1.8.2.

Installation

apt install sngrep

La capture réseau demande les droits root : lancé par un utilisateur normal, sngrep s’arrête avec Couldn't activate capture: socket: Operation not permitted. Utilisez sudo pour la capture en direct. La lecture d’un fichier pcap, elle, ne demande aucun droit particulier.

Capture en direct

sudo sngrep

Par défaut, sngrep écoute sur toutes les interfaces (any) et affiche tous les paquets SIP qu’il reconnaît. Pour restreindre :

sudo sngrep -d eth0                      # une seule interface
sudo sngrep -d eth0 port 5060            # filtre BPF, même syntaxe que tcpdump
sudo sngrep -d eth0 host 192.168.1.1 and udp
sudo sngrep -c                           # uniquement les dialogues qui commencent par un INVITE

L’option -c est la plus utile sur un serveur chargé : elle masque les REGISTER, OPTIONS et autres messages qui noient les appels.

La liste des dialogues

L’écran principal liste un dialogue SIP par ligne : méthode, appelant, appelé, nombre de messages, source et destination.

                         sngrep - SIP messages flow viewer
  Current Mode: Offline          Dialogs: 2          Filename: test.pcap
  Match Expression:              BPF Filter:
  Display Filter:
      ^Idx Method     SIP From            SIP To                  Msgs  Source              Destination
  [ ] 1    INVITE     101@192.168.1.1     102@192.168.1.1         7     192.168.1.20:5060   192.168.1.1:5060
  [ ] 2    INVITE     101@192.168.1.1     0600000000@192.168.1.1  5     192.168.1.20:5060   192.168.1.1:5060

Esc Quit   Enter Show   Space Select   F1 Help   F2 Save   F3 Search   F4 Extended   F5 Clear   F7 Filter

Touches principales sur cet écran :

Entrée    afficher le diagramme du dialogue sélectionné
Espace    sélectionner plusieurs dialogues (Entrée les affiche ensemble)
F3 ou /   filtre d'affichage : ne garder que les lignes contenant un texte
F4 ou x   diagramme étendu (le dialogue et ceux qui lui sont liés)
F6 ou R   messages bruts du dialogue sélectionné
F7 ou F   filtres : SIP From, SIP To, source, destination, contenu, méthodes
F2 ou S   enregistrer la capture
F5        vider la liste (irréversible)
p         suspendre ou reprendre la capture
F1 ou h   aide
Échap, q  revenir à l'écran précédent ou quitter

Le filtre F7 permet notamment de décocher REGISTER, OPTIONS ou NOTIFY pour ne garder que les appels.

Le diagramme d’un appel

Entrée sur un dialogue affiche son diagramme de séquence, avec l’horodatage et le délai entre chaque message. Le message sélectionné est affiché en entier sur la droite.

                   Call flow for c1@192.168.1.20 (Color by Request/Response)
                                                        │INVITE sip:102@192.168.1.1 SIP/2.0
            192.168.1.20:5060      192.168.1.1:5060     │Via: SIP/2.0/UDP 192.168.1.20:5060;branch=...
          ──────────┬─────────  ──────────┬─────────    │From: <sip:101@192.168.1.1>;tag=ac1
  00:16:40.000000   │        INVITE       │             │To: <sip:102@192.168.1.1>
        +0.010000   │ ──────────────────> │             │Call-ID: c1@192.168.1.20
  00:16:40.010000   │      100 Trying     │             │CSeq: 1 INVITE
        +0.490000   │ <────────────────── │             │Content-Length: 0
  00:16:40.500000   │     180 Ringing     │
        +2.500000   │ <────────────────── │
  00:16:43.000000   │        200 OK       │
        +0.050000   │ <────────────────── │
  00:16:43.050000   │         ACK         │
       +16.950000   │ ──────────────────> │
  00:17:00.000000   │         BYE         │
        +0.020000   │ ──────────────────> │
  00:17:00.020000   │        200 OK       │
                    │ <────────────────── │

Touches sur cet écran :

↑ ↓       passer d'un message à l'autre
Entrée    afficher le message sélectionné en brut
Espace    sélectionner deux messages pour les comparer
F2 ou d   afficher le détail SDP (codecs, adresses et ports média)
F3 ou m   afficher ou masquer les flux RTP (avec la capture RTP activée)
s         diagramme compressé
c         changer le mode de couleur
Échap     revenir à la liste

Ce que l’on lit dans le diagramme :

• Un INVITE répété sans réponse : les retransmissions indiquent que le message n’arrive pas ou que la réponse ne revient pas. On regarde alors le pare-feu ou le routage.
• Un 200 OK répété après le décroché : l’ACK n’arrive pas au destinataire. Classique avec un NAT mal géré, l’appel est souvent coupé au bout d’une trentaine de secondes.
• Une réponse 4xx, 5xx ou 6xx : le code donne la cause du refus (401/407 authentification, 404 numéro inconnu, 486 occupé, 488 codecs incompatibles, 503 service indisponible…).
• Un appel établi sans son : comparez les adresses IP du SDP (touche F2) dans l’INVITE et dans le 200 OK. Une adresse privée qui part vers l’extérieur trahit un problème de NAT.

Expression de recherche : ne capturer que certains appels

Un texte donné en argument filtre les dialogues dès la capture : si la requête qui ouvre le dialogue contient ce texte, tout le dialogue est conservé, réponses comprises.

sudo sngrep -c 0600000000

Seuls les appels contenant ce numéro sont affichés. Attention, la recherche porte sur la requête initiale (l’INVITE) : sngrep 486 ne trouvera pas les appels rejetés en « 486 Busy Here », car ce code n’apparaît que dans la réponse. Pour cela, utilisez le filtre d’affichage F3 une fois la capture lancée.

Autres options :

-i        rendre la recherche insensible à la casse
-v        inverser la recherche (exclure les dialogues qui correspondent)

Enregistrer et relire une capture

Enregistrer tout ce qui est capturé dans un fichier pcap, tout en gardant l’interface :

sudo sngrep -d eth0 -O /tmp/sip-$(date +%F-%H%M).pcap port 5060

Capturer sans interface, par exemple pendant qu’on reproduit un problème depuis un poste :

sudo sngrep -N -c -O /tmp/appels.pcap

sngrep affiche seulement le nombre de dialogues capturés ; on arrête avec Ctrl+C. Avec une expression de recherche, seuls les dialogues correspondants sont écrits dans le fichier :

sudo sngrep -N -O /tmp/appel-client.pcap 0600000000

Relire ensuite le fichier, sur le serveur ou sur un autre poste, sans droits root :

sngrep -I /tmp/appels.pcap

Le fichier est au format pcap standard : il s’ouvre aussi dans Wireshark ou avec tcpdump -r. Les filtres BPF fonctionnent aussi en lecture : sngrep -I capture.pcap host 192.168.1.1.

Depuis l’interface, F2 ouvre la fenêtre d’enregistrement. On y choisit les dialogues à garder (tous, sélectionnés avec Espace, ou filtrés) et le format : pcap avec le SIP seul, pcap avec SIP et RTP, ou texte.

  ┌─ Dialogs ───────────────────┐ ┌─ Format ────────────────────┐
  │(*) all dialogs              │ │(*) .pcap (SIP)              │
  │( ) selected dialogs [0]     │ │(-) .pcap (SIP + RTP)        │
  │( ) filtered dialogs [2]     │ │( ) .txt                     │
  └─────────────────────────────┘ └─────────────────────────────┘

Le format « SIP + RTP » n’est disponible que si la capture a été lancée avec -r, qui conserve le contenu des paquets RTP en mémoire :

sudo sngrep -c -r -O /tmp/appel-avec-son.pcap

Le son peut ensuite être écouté dans Wireshark (menu Telephony > VoIP Calls). Attention à la mémoire : avec -r, chaque appel occupe nettement plus de place.

Longues captures

sngrep garde les dialogues en mémoire, avec une limite par défaut de 20 000 dialogues. Pour le laisser tourner longtemps sur un serveur chargé :

sudo sngrep -c -l 5000 -R

-l fixe la limite et -R supprime les dialogues les plus anciens quand elle est atteinte, au lieu d’arrêter la capture.

Configuration

Les réglages par défaut se placent dans /etc/sngreprc (pour tout le système) ou ~/.sngreprc (pour un utilisateur). Le fichier livré par Debian contient tous les réglages possibles, en commentaire. Exemple :

vi ~/.sngreprc

# Interface et filtre par défaut
set capture.device eth0
set filter.methods INVITE
# Dossier proposé à l'enregistrement (F2)
set sngrep.savepath /tmp/sngrep-captures
# Ne pas demander de confirmation en quittant
set cl.noexitprompt on

Pour afficher la configuration active : sngrep -D.

Pour aller plus loin

• SIP sur TLS : l’option -k accepte la clé privée RSA du serveur pour déchiffrer les paquets capturés.
• HEP/EEP : sngrep peut recevoir des paquets encapsulés envoyés par un IPBX ou un SBC (-L udp:0.0.0.0:9060) ou en envoyer vers un serveur Homer (-H udp:192.168.1.50:9060). Pratique pour observer un équipement sur lequel on ne peut pas installer sngrep.

En résumé

sudo sngrep -c                               # voir les appels en direct
sudo sngrep -c 0600000000                    # suivre un numéro
sudo sngrep -N -c -O /tmp/appels.pcap        # capturer sans interface
sngrep -I /tmp/appels.pcap                   # relire une capture

Sources

• sngrep sur GitHub (Irontec)
• sngrep(8), Debian Trixie
• Paquet sngrep, Debian Trixie
• RFC 3261 : SIP

Les commandes ci-dessous ont été vérifiées sur Debian 13 (Trixie) avec gping 1.19.0, oping 1.10.0 et fping 5.1.

Lequel choisir ?

• gping : un graphique de latence en temps réel, une courbe colorée par hôte. Idéal pour comparer 2 à 6 cibles.
• noping : un tableau de bord ncurses, un cadre de statistiques par hôte. Reste lisible avec une dizaine de cibles ou plus.
• fping : pas d’interface, une sortie texte. Parfait pour balayer une plage d’adresses ou pour un script.

gping : le graphique de latence

gping trace le temps de réponse de chaque hôte sous forme de courbe dans le terminal. Il s’appuie sur la commande ping du système, il ne demande donc aucun droit particulier.

apt install gping

gping 192.168.1.254 192.168.1.10 1.1.1.1

Chaque hôte reçoit sa propre couleur. On quitte avec Ctrl+C.

Options utiles :

-n 1          intervalle entre deux pings, en secondes (0.2 par défaut)
-b 120        durée affichée dans le graphique, en secondes (30 par défaut)
-4 / -6       forcer IPv4 ou IPv6
-i eth0       choisir l'interface de sortie
-s            graphisme simple, pour les terminaux sans caractères braille Unicode
-c red,blue   imposer les couleurs, dans l'ordre des hôtes
--clear       effacer le graphique en quittant

Exemple : surveiller une coupure pendant deux minutes, un ping par seconde :

gping -n 1 -b 120 192.168.1.254 1.1.1.1

gping sait aussi mesurer la durée d’exécution d’une commande plutôt qu’un ping, avec --cmd :

gping --cmd "curl -so /dev/null https://www.debian.org"

Au-delà de cinq ou six courbes, le graphique devient difficile à lire : passez alors à noping.

noping : le tableau de bord ncurses

noping est fourni par le paquet oping, avec oping, son équivalent en sortie texte. Il envoie les requêtes ICMP en parallèle, en IPv4 et IPv6, et affiche un cadre par hôte : paquets envoyés et reçus, pourcentage de perte, latence, et un graphique.

apt install oping

noping 192.168.1.254 192.168.1.10 192.168.1.20 1.1.1.1

Pas besoin de sudo : à l’installation, le paquet Debian donne la capacité cap_net_raw aux binaires (ou le bit setuid si setcap n’est pas disponible). Vérification :

getcap /usr/bin/noping
# /usr/bin/noping cap_net_raw=ep

Les temps de réponse sont colorés : vert pour les valeurs habituelles, jaune pour les valeurs inhabituelles, rouge pour les valeurs aberrantes. Un paquet perdu s’affiche sous forme de point d’exclamation rouge.

Touches pendant l’exécution :

g     changer le type de graphique
+ -   agrandir ou réduire les cadres
a     ajouter un hôte à la volée

On quitte avec Ctrl+C.

Pour une liste d’équipements à surveiller régulièrement, mettez-les dans un fichier, une adresse par ligne :

vi ~/hotes.txt

192.168.1.254
192.168.1.10
192.168.1.20
192.168.1.30

noping -f ~/hotes.txt

Options utiles :

-i 0.5        intervalle entre deux pings, en secondes
-g histogram  type de graphique : prettyping (défaut), histogram, boxplot ou none
-H 3          hauteur des cadres, de 1 à 5 lignes (réduire pour voir plus d'hôtes)
-O ping.csv   enregistrer chaque mesure dans un fichier CSV (horodatage, hôte, latence)
-b            bip à chaque réponse, pratique pour suivre le redémarrage d'une machine

Exemple : cadres compacts pour faire tenir plus d’hôtes à l’écran, avec enregistrement des mesures :

noping -H 2 -O ~/ping-$(date +%F).csv -f ~/hotes.txt

fping : balayer une plage et scripter

fping n’a pas d’interface graphique, mais il est imbattable pour savoir rapidement qui répond sur un réseau.

apt install fping

Lister les machines actives d’un sous-réseau, avec leur temps de réponse :

fping -a -e -g 192.168.1.0/24 2>/dev/null

192.168.1.10 (0.164 ms)
192.168.1.20 (0.059 ms)
192.168.1.254 (0.201 ms)

La plage peut aussi s’écrire avec une adresse de début et de fin : fping -a -g 192.168.1.1 192.168.1.50. L’option -u fait l’inverse et liste les cibles qui ne répondent pas.

Envoyer 3 pings à chaque hôte et n’afficher que le bilan :

fping -c 3 -q 192.168.1.254 192.168.1.10 192.168.1.20

192.168.1.254 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.201/0.253/0.303
192.168.1.10  : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.118/0.139/0.153
192.168.1.20  : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.043/0.048/0.053

Surveiller en continu avec un bilan toutes les 10 secondes :

fping -l -Q 10 -f ~/hotes.txt

Le même fichier d’hôtes que pour noping fonctionne avec -f.

En résumé

gping 192.168.1.254 1.1.1.1                # comparer quelques hôtes sur un graphique
noping -f ~/hotes.txt                       # tableau de bord pour une liste d'équipements
fping -a -e -g 192.168.1.0/24 2>/dev/null   # qui répond sur le réseau ?

Sources

• gping sur GitHub
• noping(8), Debian Trixie
• liboping (oping et noping) sur GitHub
• fping.org

Point de départ, la commande manuelle que l’on connaît déjà :

apt install cifs-utils
mount -t cifs //192.168.1.1/shared /mnt/ssd -o credentials=/etc/smbcredentials,uid=1000,gid=1000

On va transposer ces informations dans des fichiers d’unité systemd.

Fichier d’identifiants

Ne mettez pas le mot de passe dans l’unité : les fichiers de /etc/systemd/system sont lisibles par tous. Créez un fichier dédié, lisible par root uniquement :

vi /etc/smbcredentials

username=myuser
password=MotDePasse

chmod 600 /etc/smbcredentials

Nommer les unités

Le nom du fichier doit correspondre au chemin du point de montage. Pour /mnt/ssd, les unités s’appellent mnt-ssd.mount et mnt-ssd.automount ; pour /media/star, ce serait media-star.mount. Si le chemin contient des caractères spéciaux (un tiret par exemple), laissez systemd calculer le nom :

systemd-escape -p --suffix=mount /data/home-backup
# data-home\x2dbackup.mount

Création du fichier mnt-ssd.mount

vi /etc/systemd/system/mnt-ssd.mount

[Unit]
Description=Partage CIFS distant (SSD)
Wants=network-online.target
After=network-online.target

[Mount]
What=//192.168.1.1/shared
Where=/mnt/ssd
Type=cifs
Options=credentials=/etc/smbcredentials,uid=1000,gid=1000,iocharset=utf8
TimeoutSec=30

[Install]
WantedBy=multi-user.target

Pour un système de fichiers réseau comme CIFS, systemd ajoute de lui-même ces dépendances vers network-online.target ; les écrire explicitement ne fait que rendre l’intention lisible.

Option : montage à la demande (mnt-ssd.automount)

Avec une unité automount, le partage n’est monté qu’au premier accès à /mnt/ssd, et peut être démonté après une période d’inactivité. Le démarrage n’attend plus le serveur distant.

vi /etc/systemd/system/mnt-ssd.automount

[Unit]
Description=Montage automatique du partage CIFS (SSD)

[Automount]
Where=/mnt/ssd
TimeoutIdleSec=600

[Install]
WantedBy=multi-user.target

Ne mettez pas After=network-online.target dans l’unité automount : la documentation systemd précise que cela peut créer un cycle de dépendances. Les dépendances réseau restent dans le .mount.

Activation

Choisissez un des deux modes.

# Montage au démarrage
systemctl daemon-reload
systemctl enable --now mnt-ssd.mount

# OU montage à la demande (le .mount n'est alors pas activé)
systemctl daemon-reload
systemctl enable --now mnt-ssd.automount
ls /mnt/ssd    # déclenche le montage

Gestion

systemctl status mnt-ssd.mount
systemctl stop mnt-ssd.mount
systemctl restart mnt-ssd.mount
journalctl -u mnt-ssd.mount

stunnel chiffre en TLS une connexion TCP qui ne l’est pas. Il peut aussi aider à franchir un pare-feu : on peut par exemple faire passer dans stunnel un VPN, tant que celui-ci utilise TCP. L’exemple ci-dessous protège un service Telnet (port 23), avec authentification mutuelle : le serveur n’accepte que le client dont il connaît le certificat, et inversement.

Génération des certificats

Sur une machine disposant d’OpenSSL, créez un certificat autosigné pour le serveur et un pour le client :

openssl req -x509 -newkey rsa:3072 -sha256 -days 825 -nodes \
  -subj "/CN=stunnel-serveur" -keyout serveur.key -out serveur.crt
openssl req -x509 -newkey rsa:3072 -sha256 -days 825 -nodes \
  -subj "/CN=stunnel-client" -keyout client.key -out client.crt

Copiez sur le serveur : serveur.key, serveur.crt et client.crt. Sur le client : client.key, client.crt et serveur.crt. Les clés privées doivent rester lisibles par root uniquement (chmod 600).

Serveur (Debian/Ubuntu)

apt install stunnel4
vi /etc/stunnel/services.conf

cert = /etc/stunnel/serveur.crt
key = /etc/stunnel/serveur.key
; seul le certificat du client est accepté
CAfile = /etc/stunnel/client.crt
verifyPeer = yes
sslVersionMin = TLSv1.2

[telnet]
; port exposé sur Internet
accept = 4443
; service local à protéger
connect = 127.0.0.1:23

Le paquet Debian fournit un modèle d’unité : l’instance services lit /etc/stunnel/services.conf.

systemctl enable --now stunnel@services
journalctl -u stunnel@services

Autorisez le port 4443/TCP sur le pare-feu (et redirigez-le sur le routeur si le serveur est derrière du NAT).

Client Debian/Ubuntu

apt install stunnel4
vi /etc/stunnel/services.conf

client = yes
cert = /etc/stunnel/client.crt
key = /etc/stunnel/client.key
; seul le certificat du serveur est accepté
CAfile = /etc/stunnel/serveur.crt
verifyPeer = yes
sslVersionMin = TLSv1.2

[telnet]
; le client Telnet local se connecte ici
accept = 127.0.0.1:2323
connect = IP_PUBLIQUE_DU_SERVEUR:4443

systemctl enable --now stunnel@services

Client Windows

Téléchargez stunnel, lancez l’installeur, puis placez client.crt, client.key et serveur.crt dans le dossier config du répertoire d’installation. Ajoutez au fichier stunnel.conf de ce dossier la même configuration que ci-dessus, avec des chemins relatifs :

client = yes
cert = client.crt
key = client.key
CAfile = serveur.crt
verifyPeer = yes
sslVersionMin = TLSv1.2

[telnet]
accept = 127.0.0.1:2323
connect = IP_PUBLIQUE_DU_SERVEUR:4443

Test

Depuis le client, ouvrez une session Telnet vers 127.0.0.1, port 2323. Le trafic entre les deux machines passe chiffré dans le tunnel. En cas d’échec, les journaux (journalctl sous Linux, fenêtre de log sous Windows) indiquent si le certificat du pair a été refusé.

lsof : lister les fichiers ouverts

lsof signifie « LiSt Open Files ». Il indique quels fichiers sont ouverts, et par quels processus. Sous Linux, presque tout est un fichier : fichiers ordinaires, répertoires, périphériques, tubes (pipes), sockets réseau et sockets Unix. lsof permet donc de répondre à des questions très variées.

Lancez-le en root pour voir les fichiers de tous les utilisateurs. Les options -n (pas de résolution DNS) et -P (numéros de port au lieu des noms) accélèrent nettement l’affichage.

apt install lsof

Par fichier, répertoire ou périphérique

lsof | less

Liste tous les fichiers ouverts. La liste est longue, d’où le less.

lsof /var/log/apache2/access.log

Processus qui utilisent ce fichier.

lsof +D /var/log

Fichiers ouverts dans ce répertoire et ses sous-répertoires. Pratique quand un umount répond « target is busy ».

lsof /dev/sda1

Fichiers ouverts sur ce périphérique (ou sur le système de fichiers qu’il porte).

lsof /dev/tty1

Processus attachés au terminal tty1.

Par utilisateur ou par commande

lsof -u root

Fichiers ouverts par les processus de l’utilisateur root.

lsof -u ^root

Fichiers ouverts par tous les processus qui n’appartiennent pas à root.

lsof -c nginx

Fichiers ouverts par les processus dont le nom commence par nginx.

lsof -t -u ansible

L’option -t n’affiche que les PID, ce qui permet de les passer à une autre commande. Par exemple, pour arrêter tous les processus de l’utilisateur ansible :

kill $(lsof -t -u ansible)

Commencez par un kill simple (signal TERM), qui laisse aux programmes le temps de se fermer proprement. Ne passez à kill -9 que pour les processus qui refusent de s’arrêter.

Combiner les critères : OU ou ET

Par défaut, les critères de sélection se combinent en OU : la commande suivante liste les fichiers de root et ceux de toutes les commandes bash, quel que soit leur propriétaire.

lsof -u root -c bash

L’option -a les combine en ET : ici, uniquement les processus bash appartenant à root.

lsof -a -u root -c bash

Fichiers supprimés mais encore ouverts

Si l’on supprime un fichier qu’un processus garde ouvert (un gros fichier de log, typiquement), l’espace disque n’est pas libéré tant que le processus ne l’a pas fermé. df indique alors un disque plein alors que du ne trouve rien. Pour retrouver ces fichiers et le processus qui les tient :

lsof +L1

+L1 sélectionne les fichiers ouverts dont le nombre de liens est inférieur à 1, c’est-à-dire supprimés. Redémarrer le service concerné (ou lui faire rouvrir ses logs) libère l’espace.

Réseau

lsof -i -n -P

Tous les fichiers réseau (sockets TCP et UDP).

lsof -i 4
lsof -i 6

Uniquement IPv4, ou uniquement IPv6.

lsof -i TCP:80 -n -P

Processus qui utilisent le port TCP 80, en écoute ou connectés.

lsof -i TCP:1-1024 -n -P

Processus sur les ports TCP 1 à 1024 (les ports « privilégiés »).

lsof -i TCP -s TCP:LISTEN -n -P

Uniquement les sockets TCP en écoute.

lsof -i@10.0.10.19 -n -P

Connexions avec l’adresse IP 10.0.10.19.

lsof -U

Sockets Unix (communication locale entre processus).

Pour une vue réseau rapide, ss -tulpn (paquet iproute2) donne aussi les ports en écoute et les processus associés.

pstree : l’arbre des processus

pstree affiche les processus sous forme d’arbre, ce qui montre immédiatement qui a lancé quoi. Il fait partie du paquet psmisc, qui n’est pas toujours installé par défaut :

apt install psmisc

pstree -p

Arbre complet avec les PID.

pstree -a

Affiche aussi les arguments de chaque commande.

pstree -u

Signale les changements d’utilisateur (un processus root qui lance un processus www-data, par exemple).

pstree -p -s 1234

Remonte la lignée du processus 1234 jusqu’à systemd : utile pour savoir d’où vient un processus inconnu.

pstree www-data

Uniquement les processus d’un utilisateur.

last : l’historique des connexions

last liste les dernières ouvertures de session et les redémarrages.

last
last -n 10
last amgv
last reboot

Respectivement : tout l’historique, les 10 dernières entrées, les sessions d’un utilisateur, et les redémarrages.

last -F
last -x
last -s "2026-09-01 00:00:00" -t "2026-09-30 23:59:59"

Dates complètes, arrêts du système inclus, et filtre sur une période.

À savoir sous Debian 13 : last est désormais fourni par le paquet wtmpdb, qui enregistre les sessions dans une base SQLite au lieu de l’ancien fichier /var/log/wtmp. Les options courantes restent les mêmes, mais lastb (tentatives de connexion échouées) n’existe plus. Pour ces échecs, consultez le journal :

journalctl -u ssh --since today | grep -i "failed"

sort : trier une sortie

sort fichier.txt
sort -r fichier.txt
sort -u fichier.txt

Tri alphabétique, tri inverse, tri en supprimant les doublons.

sort -n nombres.txt

Tri numérique (sinon 10 arrive avant 9).

du -sh /var/* | sort -h

Tri de tailles « humaines » (K, M, G) : trouve les plus gros répertoires.

sort -t: -k3 -n /etc/passwd

Tri sur un champ : -t: définit le séparateur, -k3 le 3^e champ (ici l’UID).

cut -d' ' -f1 /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Combinaison classique : les 10 adresses IP les plus fréquentes dans un journal d’accès. uniq -c compte les lignes identiques consécutives, d’où le premier sort.

grep : chercher dans des fichiers

grep "error" /var/log/apache2/error.log
grep -i "error" /var/log/apache2/error.log

Recherche simple, puis insensible à la casse. grep fonctionne aussi en sortie d’une autre commande, par exemple journalctl -b | grep -i error pour les journaux système.

grep -n "Listen" /etc/apache2/ports.conf
grep -c "/bin/bash" /etc/passwd

Affiche les numéros de ligne, ou seulement le nombre de lignes trouvées (ici, les comptes dont le shell est bash).

grep -rn "PermitRootLogin" /etc/ssh/
grep -rl "192.168.31.5" /etc/

Recherche récursive dans un répertoire, avec numéros de ligne, ou en listant seulement les fichiers concernés.

grep -rn --include="*.conf" "ServerName" /etc/apache2/

Recherche limitée à certains types de fichiers.

grep -w "root" /etc/passwd

Mot entier uniquement (root, mais pas chroot).

journalctl -k | grep -A3 -B2 "Out of memory"

Affiche 3 lignes après et 2 lignes avant chaque résultat (-C3 pour 3 lignes de part et d’autre).

grep -Ev '^\s*(#|$)' /etc/ssh/sshd_config

Affiche un fichier de configuration sans les commentaires ni les lignes vides. -v inverse la sélection, -E active les expressions régulières étendues.

ps aux | grep "[n]ginx"

Astuce : les crochets empêchent grep de se trouver lui-même dans la liste des processus.

systemctl et journalctl : gérer les services

État et contrôle

systemctl status nginx
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl reload nginx

reload relit la configuration sans couper le service, quand celui-ci le permet ; restart l’arrête puis le relance.

systemctl enable --now nginx
systemctl disable --now nginx

Active (ou désactive) le démarrage automatique et démarre (ou arrête) le service dans la même commande.

systemctl is-active nginx
systemctl is-enabled nginx

Réponses courtes (active, enabled…), utiles dans un script.

Inventaire

systemctl --failed
systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled
systemctl list-timers

Services en échec, services en cours d’exécution, services activés au démarrage, et tâches planifiées par des timers systemd.

Configuration des unités

systemctl cat nginx

Affiche le fichier d’unité et ses éventuelles surcharges.

SYSTEMD_EDITOR=vi systemctl edit nginx

Crée une surcharge (override.conf) sans toucher au fichier fourni par le paquet, qui serait écrasé à la prochaine mise à jour. La variable SYSTEMD_EDITOR choisit l’éditeur.

systemctl daemon-reload

À lancer après avoir modifié ou créé un fichier d’unité à la main.

systemctl mask nginx
systemctl unmask nginx

mask empêche totalement le démarrage du service, même manuel ou comme dépendance d’un autre service.

Journaux

journalctl -u nginx
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"
journalctl -b -p err
journalctl --disk-usage

Journaux d’un service, en suivi continu (comme tail -f), sur la dernière heure, erreurs depuis le dernier démarrage, et place occupée par les journaux.

Ce problème peut avoir plusieurs causes ; celle dont je parle ici est liée au MTU sur un lien IPsec.

Contexte

Sur le site A, un PC Linux est connecté à un pare-feu qui monte le tunnel IPsec, lui-même derrière une passerelle Internet. Le site B dispose des mêmes équipements. Depuis le PC du site A, on se connecte en SSH au PC du site B.

Les petits paquets (l’ouverture de session, les commandes) passent. Les gros paquets d’un transfert de fichier, eux, dépassent la taille maximale que le tunnel peut transporter une fois l’en-tête IPsec ajouté. Si les messages ICMP « fragmentation nécessaire » sont filtrés quelque part sur le chemin, les deux machines ne l’apprennent jamais et le transfert s’arrête.

Diagnostic

Depuis le PC A, envoyez vers le PC B des pings de taille fixe en interdisant la fragmentation. 1472 octets de données + 28 octets d’en-têtes IP et ICMP = 1500, le MTU Ethernet standard.

# Linux
ping -M do -s 1472 pc-site-b

# Windows
ping -f -l 1472 pc-site-b

Si la réponse est une erreur (« Frag needed and DF set », « message too long ») ou si aucune réponse n’arrive, diminuez la valeur de -s jusqu’à ce que le ping passe. La plus grande valeur qui passe, plus 28, donne le MTU réel du chemin.

Correction

Deux approches, selon ce que vous maîtrisez :

• Sur le poste : baisser le MTU de l’interface à la valeur trouvée (ici 1400 en exemple) :

  ip link set dev eth0 mtu 1400

• Sur le pare-feu (préférable, corrige tous les postes) : réduire le MSS annoncé dans les ouvertures de connexion TCP qui traversent le tunnel. Avec iptables :

  iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

  La plupart des pare-feu (OPNsense, pfSense, FortiGate…) proposent un réglage équivalent de MSS sur l’interface ou le tunnel.

Laissez aussi passer les messages ICMP de type 3 code 4 (« fragmentation needed ») : ils sont indispensables à la découverte automatique du MTU.

<Directory /var/www/monsite>
    Require ip 127.0.0.1 192.168.2.253
</Directory>

Toutes les autres adresses reçoivent une erreur 403. On peut aussi autoriser un sous-réseau entier :

Require ip 192.168.2.0/24

ou seulement la machine locale :

Require local

Vérifiez la syntaxe puis rechargez Apache :

apachectl configtest
systemctl reload apache2

Et l’ancienne syntaxe ?

La version initiale de cet article utilisait Order deny,allow, Allow from et Deny from all. C’était la syntaxe d’Apache 2.2. Depuis Apache 2.4, elle n’est acceptée qu’avec le module de compatibilité mod_access_compat, et la documentation Apache déconseille de mélanger les deux syntaxes, qui peuvent produire des résultats inattendus.

Dans ce PLF il y a bien évidemment d’autres paquets : Acrobat Reader 7.0.9, Google Earth 4.0.2735, skype, w32codecs

Tout ceci se trouve sur le site Medibuntu. Sur ce site qui est très joli et « unbuntis », il y a la liste complète des paquets et un didacticiel pour ajouter le dépôt à votre « source list ». Les paquets sont disponibles pour Ubuntu breezy, dapper, edgy et feisty. En ce qui concerne les plateformes supportées, là aussi il n’y a pas de problèmes : amd64, i386 et powerpc.