Outils analyse réseau

De Xala le 08/05/2020 - 1588948320 Réseau

Voici une liste de quelques outils de mon quotidien pour l'analyse réseau avec quelques exemples d'usage pour chacun d'eux. L'objectif n'est pas de présenter toutes les posibilitées et options de ces programmes, mais de faire une sorte de memo des "commandes" de base. Pour un usage avancé de ces programmes, je vous invite à consulter les manuels :)

De même je ne cherche pas à présenter l'ensemble des outils existant. Je me concentre surtout sur les outils que j'utilise régulièrements. Nous n'allons donc pas voir des programmes spécifique à de l'audit comme nmap ou encore des outils de visibilité comme jnettop ou vmstats.

La plupart de ces outils sont installés par défaut dans les distributions de la famille Debian. Sinon, ils sont présent dans les dépôts officiels.

Les outils entre paranthèses sont les équivalants obsolètes et donc voués à disparaitre.

ip (ifconfig, route)

La commande ip permet beaucoup de choses, de l'affichage des statistiques des cartes réseau à la modification des routes. Il faut le voir comme un regroupement des programmes arp, ifconfig, route et netstat.

Petite particularité de la commande ip, c'est qu'elle permet certaines abréviations. Par exemple on peut taper "r" à la place de "route".

Voici un extrait du man listant les abréviations possible:

OBJECTS with abbreviations
   link      l           Network device.
   address   a or addr   Protocol (IP or IPv6) address on a device. 
   addrlabel addrl       Label configuration for protocol address selection. 
   neighbour n or neigh  ARP or NDISC cache entry. 
   route     r           Routing table entry.
   rule      ru          Rule in routing policy database.
   maddress  m or maddr  Multicast address. 
   mroute    mr          Multicast routing cache entry.
   tunnel    t           tunnel over IP.
   xfrm      x           framework for IPsec protocol.

"ip" est sensible à l'ordre des arguments, se référer au man pour mieux comprendre la logique.

Les changements apportés via cet outil ne sont pas persistant. C'est à dire que la plupart des changement disparaissent après un reboot. Si besoin, ajoutez les commandes dans le fichier "interfaces" ou de voir pour le faire via systemd.

ip - ARP

Lister les équipements voisin (= arp -a)

$ ip n show
192.168.1.19 dev enp0s31f6 lladdr 00:0d:b9:2c:53:74 REACHABLE
192.168.1.254 dev enp0s31f6 lladdr 00:24:d4:a2:6f:b3 REACHABLE
fe80::20d:b9ff:fe2c:5374 dev enp0s31f6 lladdr 00:0d:b9:2c:53:74 STALE
fe80::224:d4ff:fea2:6fb3 dev enp0s31f6 lladdr 00:24:d4:a2:6f:b3 router REACHABLE

Ajouter une entrée à la table (= arp -s ...)

$ ip neigh add 192.168.1.1 lladdr 00:24:d4:a2:6f:b3 dev eth0

Supprimer une entrée à la table (= arp -i ...)

$ ip neigh del 192.168.1.1 dev eth0

Flush toute la table ARP

Attention avec cette commande brutale !

 $ ip -s neigh flush all

ip - Interfaces réseau

Lister les interfaces réseau (= ifconfig -a)

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether c8:5b:76:14:46:e7 brd ff:ff:ff:ff:ff:ff
3: wlp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether e4:b3:18:50:18:5b brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
    link/none

Afficher les stats d'une interface

$ ip -s link show dev tun0
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
    link/none 
    RX: bytes  packets  errors  dropped overrun mcast   
    16780194   17082    0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    1897139    14236    0       0       0       0

Descendre une interface (= ifconfg eth0 down)

$ ip link set eth0 down

Monter une interface (= ifconfig eth0 up)

$ ip link set eth0 up

Changer le MTU d'une interface (= ifconfig eth0 mtu 9000)

$ ip link set eth0 mtu 9000

ip - Adressage IP

Lister toutes les IPv4/6 configurées sur une ligne

$ ip -o -4 a
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
2: enp0s31f6    inet 192.168.1.1/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s31f6\       valid_lft 40553sec preferred_lft 40553sec
4: tun0    inet 10.8.0.73 peer 10.8.0.74/32 scope global tun0\       valid_lft forever preferred_lft forever
$ ip -o -6 a
1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
2: enp0s31f6    inet6 2a01:e0a:380:4980::ff/64 scope global temporary dynamic \       valid_lft 86308sec preferred_lft 65071sec
2: enp0s31f6    inet6 2a01:e0a:380:4980::ff/64 scope global dynamic mngtmpaddr noprefixroute \       valid_lft 86308sec preferred_lft 86308sec
2: enp0s31f6    inet6 fe80::5106:2cf9:97b0:aa60/64 scope link noprefixroute \       valid_lft forever preferred_lft forever
4: tun0    inet6 fe80::55db:c209:1ebe:aebc/64 scope link stable-privacy \       valid_lft forever preferred_lft forever

Ajouter une IPv4/6 à une interface

$ ip addr add 192.168.1.10 dev eth0
$ ip -6 addr add fd01::1:a/64 dev eth0

Supprimer une IPv4/6 à une interface

$ ip addr del 192.168.1.10 dev eth0
$ ip -6 addr del fd01::1:a/64 dev eth

ip - Routage statique

Afficher la route pour une IPv4/6 donnée

$ ip r get 10.78.34.4
10.78.34.4 via 10.8.0.74 dev tun0 src 10.8.0.73 uid 1000 
    cache 
$ ip -6 r get 2001:41d0:1:890c::1
2001:41d0:1:890c::1 from :: via fe80::224:d4ff:fea2:6fb3 dev enp0s31f6 proto ra src 2a01:e0a:380:4980:e0b1:5742::ff metric 100 pref medium

Afficher les tables de routage (= route -n)

$ ip r show
default via 192.168.1.254 dev enp0s31f6 proto dhcp metric 100 
10.8.0.74 dev tun0 proto kernel scope link src 10.8.0.73 
192.168.0.0/16 via 10.8.0.74 dev tun0 
192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.1 metric 100 
192.168.2.0/24 via 10.8.0.74 dev tun0 
192.168.4.0/24 via 10.8.0.74 dev tun0 
$ ip -6 r show
::1 dev lo proto kernel metric 256 pref medium
2a01:e0a:380:4980::/64 dev enp0s31f6 proto ra metric 100 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 100 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
default via fe80::224:d4ff:fea2:6fb3 dev enp0s31f6 proto ra metric 100 pref medium

Afficher les règles de routage (pratique pour du source routing)

$ ip rule show
0:    from all lookup local 
32766:    from all lookup main 
32767:    from all lookup default 
$ ip -6 rule show
0:    from all lookup local 
32766:    from all lookup main 

Ajouter une route IPv4/6 (= route add ...)

$ ip r add 195.68.250/23 dev tun0
$ ip -6 r add default via fe80::20d:b9ff:fe2c:5374

Supprimer une route IPv4/6 (route del ...)

$ ip r del 195.68.250/23 dev tun0
$ ip -6 r del default via fe80::20d:b9ff:fe2c:5374

tcpdump

tcpdump est l'outil par excellence pour l'analyse de trame. C'est aussi l'outil qui va nous permettre d'analyser un problème d'ouverture de flux firewall (iptables) en l'absence de logs.

Un cas typique; un PC qui n'arrive pas à se connecter à un serveur et dont on imagine la topology ci-dessous:

  +----+          e2 +------------+ e0           e0 +------------+ e1         e0 +-----------+
  | PC +-------------+ Routeur    +-----------------+ Firewall   +---------------+ Serveur   |
  +----+             +------------+                 +------------+               +-----------+
   10.250.1.12                                                                   10.251.20.5

Dans les logs du firewall on ne voit pas de trace de drop ou reject donc pour vérifier si le flux passe, il suffit de faire un tcpdump sur les deux interfaces du firewall (entrée et sortie).

Pour cela, ouvrir deux terminaux sur le firewall.

Terminal 1:

$ tcpdump -n -i eth0 host 10.250.1.12 and host 10.251.20.5

Terminal 2:

$ tcpdump -n -i eth1 host 20.250.1.12 and host 10.251.20.5

Puis demander au client de faire un teste de connexion pour générer du traffic.

  • Si on ne voit rien arriver sur eth0 (terminal 1) alors le problème est en amont (routeur ou pc)
  • Si on voit du traffic aller mais pas de retour sur eth0 (terminal 1) et que rien sur eth1 (terminal 2) c'est que le traffic est drop par le firewall (vérifier règles iptables)
  • Si on voit du traffic aller mais pas de retour sur eth0 (terminal 1) et pareil sur eth1 (terminal 2), c'est qu'il y a un problème au niveau du serveur (vérifier le service et/ou firewall sur serveur)

Comme on peut voir, ce type d'analyse permet en un seul teste d'isoler la source du problème et donc investiguer au bon endroit de façon rapide.

Le traffic UDP n'a pas le même comportement que le traffic TCP! Il est donc tout a fait normal de ne pas observer de retour sur ce type de flux.

  • UDP est un protocole orienté "non connexion". Pour faire simple, lorsqu'une machine A envoie des paquets à destination d'une machine B, ce flux est unidirectionnel. En effet, la transmission des données se fait sans prévenir le destinataire (la machine B), et le destinataire reçoit les données sans effectuer d'accusé de réception vers l'émetteur (la machine A).
  • TCP est orienté "connexion". Lorsqu'une machine A envoie des données vers une machine B, la machine B est prévenue de l'arrivée des données, et témoigne de la bonne réception de ces données par un accusé de réception.

Ce rappel n'est pas un troll... j'ai déjà vu un ingé réseau s'étonner de ne pas avoir de retour sur un traffic udp...

netcat (telnet)

Netcat (à ne pas confondre avec netstat) est un outil très pratique pour ouvrir ou tester des ports TCP/UDP. Il permet beaucoup choses comme le transfert de fichier, l'exécution de binaire (bash) à distance, proxy basique, messagerie instantanée etc. Bref un véritable couteau Suisse complet et plus d'actualité que telnet...

Netcat ne chiffre pas les connexions ! Pour une utilisation autre que le diagnostique, il est recommandé d'utiliser cryptcat qui n'est autre qu'un fork de netcat mais avec le chiffrement des communications.

Tester le port tcp/80:

$ nc -v -w2 -z www.clamifa.net 80
Connection to www.clamifa.net 80 port [tcp/http] succeeded!
$ # ou sans le mode verbose (pratique dans un script bash)
$ nc -w2 -z www.clamifa.net 80
$ echo $?
0

Se connecter un à port tcp/25:

$ nc mail.clamifa.net 25
220 Welcome to mail.clamifa.net! :)
helo xala@clamifa.net
250 mail.clamifa.net
quit
221 2.0.0 Bye

Noter qu'on peut faire la même chose sur un port 80 et balancer des requêtes GET, POST etc.

$ printf 'GET / HTTP/1.0\r\n\r\n' | nc www.exemple.fr 80
HTTP/1.1 200 OK
Date: Thu, 07 May 2020 20:11:26 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Mon, 01 Feb 2016 08:11:58 GMT
ETag: "10-52ab0f050ef80"
Accept-Ranges: bytes
Content-Length: 16
Connection: close
Content-Type: text/html; charset=UTF-8

en construction

Faire un scan de port tcp:

$ nc -vv -i 3000 -r -z www.exemple.fr 20-22
nc: connect to www.exemple.fr port 21 (tcp) failed: Connection timed out
nc: connect to www.exemple.fr port 20 (tcp) failed: Connection timed out
Connection to www.exemple.fr 22 port [tcp/ssh] succeeded!

Ajouter l'option -u pour l'udp.

Écouter sur le port tcp/3737 et se connecter à ce port depuis une autre machine:

cartman $ nc -l -p 3737
hello
salut

stan $ nc cartman 3737
hello
salut

Noter que le "hello" a été écrit sur stan et que le "salut" est la réponse écrite sur cartman.

Execution de bash

server $ mkfifo /tmp/foo
server $ cat /tmp/f | /bin/sh -i 2>&1 | nc -l localhost 3737 > /tmp/foo

client $ nc server 3737
$ cat /etc/hostname
server
$ 

Sur debian, l'option -e n'est pas possible car jugée trop dangereuse. L'exemple qui suit est donc une l'alternative donnée dans le man.

Ajouter l'option -k sur le serveur pour qu'il continue à écouter après la déconnexion du client

Pour effectuer un transfert de fichiers

server $ cat file.tgz | nc -l -p 3737
client $ nc server 3737 > file.tgz

On peut même aller plus loin en ajoutant une barre de progression avec l'outil pv.

server $ cat file.tgz | pv -b | nc -l -p 3737
client $ nc server 3737 | pv -b > file.tgz

Autre option intéressante, c'est -d car elle permet “démoniser” le serveur avec une sortie redirigée vers un fichier. Par exemple un fichier de log.

server $ nc -d -k -l 3737 > nc.log &
client $ nc server 3737 < commands.in

iperf

Comme son nom l'indique; iperf permet de tester les performances de transfert entre deux machines. Pratique pour tester la bande passante d'un lien xDSL ou la mise en place d'une QoS.

À partir d'une certaine version de Debian, iperf est passée en version 3 et ne fonctionne pas avec la version précédente.

Par défaut iperf utilise le port tcp/5001, ne pas oublier qu'un firewall pourrait bloquer ce flux. Dans ce cas, il est possible de changer le port d'écoute voir meme de protocole (tcp/udp) via les options consultable dans le man.

iperf fonctionne donc sur un système de serveur/client. Par défaut, le teste se fait dans un seul sens mais on peut forcer un teste bidirectionnel avec l'option -r.

Voici un teste entre un serveur et un client:

server # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.3.1.202 port 5001 connected with 10.3.1.2 port 55752
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec  46.9 MBytes  39.1 Mbits/sec
------------------------------------------------------------
Client connecting to 10.3.1.2, TCP port 5001
TCP window size: 70.9 KByte (default)
------------------------------------------------------------
[  4] local 10.3.1.202 port 51307 connected with 10.3.1.2 port 5001
[  4]  0.0-10.0 sec  79.5 MBytes  66.5 Mbits/sec
client # iperf -c 10.3.1.202 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 10.3.1.202, TCP port 5001
TCP window size:  136 KByte (default)
------------------------------------------------------------
[  5] local 10.3.1.2 port 55752 connected with 10.3.1.202 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  46.9 MBytes  39.2 Mbits/sec
[  4] local 10.3.1.2 port 5001 connected with 10.3.1.202 port 51307
[  4]  0.0-10.0 sec  79.5 MBytes  66.5 Mbits/sec

Ici nous avons 39.2Mbps dans un sens et 66.5Mbps dans l'autre.

dig

dig est probablement l'outil incontournable pour diagnostiquer la résolution DNS et/ou obtenir des inforations sur un domaine.

Par exemple, pour connaitre l'IP correspondant à www.optilian.net

$ dig www.openbrain.fr

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> www.openbrain.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26622
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.openbrain.fr.      IN  A

;; ANSWER SECTION:
www.openbrain.fr.   3259    IN  CNAME   webacc11.sd6.ghst.net.
webacc11.sd6.ghst.net.  608 IN  A   155.133.142.13

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu May 07 22:18:06 CEST 2020
;; MSG SIZE  rcvd: 96

ou la version courte:

$ dig +short www.openbrain.fr
webacc11.sd6.ghst.net.
155.133.142.13

Pareil pour l'IPv6:

$ dig +short AAAA www.openbrain.fr
webacc11.sd6.ghst.net.
2001:4b98:dc6:253::13

Pour obtenir les serveurs mail d'un domaine

$ dig +short MX openbrain.fr
50 fb.mail.gandi.net.
10 spool.mail.gandi.net.

Pareil pour connaître les serveurs DNS autoritaire du domaine

$ dig +short NS openbrain.fr
ns2.openbrain.fr.
ns0.openbrain.fr.
ns1.openbrain.fr.

Attention avec l'usage du +short car il n'affiche pas des informations qui peuvent être intéressantes lors d'une analyse.

$ dig test.openbrain.fr

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> test.openbrain.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53821
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;test.openbrain.fr.     IN  A

;; Query time: 30 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu May 07 22:20:48 CEST 2020
;; MSG SIZE  rcvd: 46

Ici le status: NXDOMAIN indique qu'il n'y a pas d'enregistrement pour toto.openbrain.fr. D'autres erreurs de debug peuvent apparaître dans les "headers" et qui ne sont pas négligeable.

Voici un exemple où nous avons un retour nous indiquant que la requête a été refusée par le serveur:

$ dig A framasoft.org @ns0.openbrain.fr

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> A framasoft.org @ns0.openbrain.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 63136
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;framasoft.org.         IN  A

;; Query time: 11 msec
;; SERVER: 2001:41d0:305:2100::6bb4#53(2001:41d0:305:2100::6bb4)
;; WHEN: Thu May 07 22:26:22 CEST 2020
;; MSG SIZE  rcvd: 42

Par défaut, dig envoit ses requêtes aux serveurs DNS configurés dans le système et qui ne sont pas forcéments les serveurs autoritaire. Mais comme on le voit dans l'exemple précédent, on peut aussi demander à dig d'envoyer ses requêtes à un serveur donné avec l'arobase (@).

Cas concret; pour tester l'ajout d'un nouvel enregistrement DNS sur un serveur autoritaire. Ou alors tester la propagation de l'enregistrement sur certains resolver public.

$ dig www.framasoft.org @ns0.fdn.fr

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> www.framasoft.org @ns0.fdn.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19695
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.framasoft.org.     IN  A

;; ANSWER SECTION:
www.framasoft.org.  3558    IN  CNAME   framasoft.org.
framasoft.org.      669 IN  A   144.76.131.212

;; Query time: 6 msec
;; SERVER: 2001:910:800::12#53(2001:910:800::12)
;; WHEN: Thu May 07 22:24:02 CEST 2020
;; MSG SIZE  rcvd: 76

ss (netstat)

ss pour "Socket Statistics", permet d'afficher des informations sur les ports TCP/UDP et bien plus encore.

Dans la plupart des cas, j'utilise la suite d'options suivante:

  • `- l pour "LISTEN"
  • - t pour "TCP"
  • - n pour "numeric" (pas de résolution DNS sur les IP)
  • - p pour "process" (afficher les info sur le process qui écoute)
$ ss -ltnp
State   Recv-Q   Send-Q      Local Address:Port       Peer Address:Port                                                 
LISTEN  0        128         127.0.0.53%lo:53              0.0.0.0:*       users:(("systemd-resolve",pid=2094,fd=13))   
LISTEN  0        128               0.0.0.0:22              0.0.0.0:*       users:(("sshd",pid=1127,fd=3))               
LISTEN  0        5               127.0.0.1:631             0.0.0.0:*       users:(("cupsd",pid=4172,fd=7))              
LISTEN  0        128             127.0.0.1:6463            0.0.0.0:*       users:(("Discord",pid=19930,fd=93))          
LISTEN  0        128                  [::]:22                 [::]:*       users:(("sshd",pid=1127,fd=4))               
LISTEN  0        5                   [::1]:631                [::]:*       users:(("cupsd",pid=4172,fd=6))

On voit ici que j'ai sshd qui écoute en ipv4 et v6 sur le port 22. De même que discord écoute sur le port 6463 mais uniquement en local.

Pour aller plus loin, voici une commande tirée du man et qui va afficher toutes les connexions ssh en cours (IPv4 et IPv6).

$ ss -o state established '( dport = :ssh or sport = :ssh )' 
NetidRecv-Q Send-Q                            Local Address:Port           Peer Address:Port                            
tcp  0      0                                     10.8.0.73:60308          192.168.2.22:ssh   timer:(keepalive,82min,0) 
tcp  0      0                                     10.8.0.73:57070          192.168.2.22:ssh   timer:(keepalive,53min,0) 
tcp  0      0                                     10.8.0.73:33854          192.168.2.22:ssh   timer:(keepalive,47min,0) 
tcp  0      0                                     10.8.0.73:60524          192.168.2.22:ssh   timer:(keepalive,99min,0) 
tcp  0      0                                     10.8.0.73:60310          192.168.2.22:ssh   timer:(keepalive,12min,0) 
tcp  0      0       [2a01:e0a:380:aaaf::ff]:37412 [2001:41d0:1:77ff::ff]:ssh   timer:(keepalive,77min,0) 

Et on constate que j'ai 5 connexions vers une même machine ipv4 et une seul vers une machine ipv6.

lsof

lsof est souvent connu pour connaître qui ou quel processus utilise un fichier. Et comme sur unix/linux tout est fichier, il peut donc s'appliquer sur les ports réseau =)

Par exemple pour le port tcp/22:

 $ lsof -i TCP:22
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
sshd     1127 root    3u  IPv4   42613      0t0  TCP *:ssh (LISTEN)
sshd     1127 root    4u  IPv6   42615      0t0  TCP *:ssh (LISTEN)
ssh     20553 xala    3u  IPv4  166593      0t0  TCP nemesis:33854->xopium:ssh (ESTABLISHED)
ssh     24846 xala    3u  IPv4 4472301      0t0  TCP nemesis:60308->xopium:ssh (ESTABLISHED)
ssh     24862 xala    3u  IPv4 4472862      0t0  TCP nemesis:60310->xopium:ssh (ESTABLISHED)
ssh     25112 xala    3u  IPv4 4473864      0t0  TCP nemesis:60524->xopium:ssh (ESTABLISHED)
ssh     26929 xala    3u  IPv6 3860104      0t0  TCP [2a01:e0a:380:aaaf::ff]:37412->clm-base1:ssh (ESTABLISHED)
ssh     29131 xala    3u  IPv4 6593920      0t0  TCP nemesis:57070->xopium:ssh (ESTABLISHED)

Globalement, on retrouve la même chose que dans l'exemple précédent pour ss. Cependant, ce dernier ne remonte pas les port cachés alors que losf le peut.

mtr

Voila un outil similaire à traceroute/ping. L'avantage de mtr est d'avoir à la fois un "traceroute" et un "ping" en une seule commande. Très pratique pour analyser le chemin utilisé et/ou localiser les pertes de paquets. Je l'tuilise aussi pour vérifier en "live" un changement de topologie (modif routage dynamique).

Son usage est simple: mtr <ip.address>

$ mtr 10.251.20.5

ou pour de l'IPv6 (l'option -4 existe aussi pour force l'IPv4)

$ mtr -6 framasoft.org

mtr utilise par défaut une interface ncurse mais on peut aussi utiliser le mode de sortie brute (-l) dans le cadre de script, par exemple,

Comme pour ping, on peut aussi définir une limite de pings (-c) ainsi que la taille du ping (-s). Sans oublier l'option -n (numérique) pour ne pas faire de résolution DNS.

curl

Le bien connu curl est un outil incontournable pour l'analyse de flux http/s. En effet, il est plus connu pour d'autres usages comme la récupération d'un fichier ou effectuer des requetes sur une API/Webservice.

Mais je l'utilise souvent pour son option -I qui permet de n'afficher que les en-têtes et ainsi avoir des informations qui peuvent être pratique.

$ curl -I http://www.openbrain.fr
HTTP/1.1 301 Moved Permanently
Date: Thu, 07 May 2020 20:41:47 GMT
Server: Varnish
Location: https://www.openbrain.fr/
Content-Length: 0
Connection: keep-alive

Ici on voit un code 301 qui indique une redirection vers l'url en https (location) et que c'est un serveur Varnish qui répond.


Article de Xala et Photo by Alexa - Unsplash

Next Post Previous Post