inetdoc.net

La table raw du système de filtrage Linux netfilter est principalement utilisée pour marquer les paquets qui doivent éviter le suivi des connexions. Elle intervient au tout début du traitement des paquets, ce qui permet de traiter certains flux réseau en évitant des opérations qui consomment beaucoup de ressources, comme le suivi des connexions.

La règle fib saddr . iif oif missing vérifie si l'adresse source correspond à l'interface entrante selon la FIB (Forwarding Information Base). Cette règle met en œuvre le filtrage du chemin inverse.

C'est l'option list qui permet l'affichage des règles implantées dans les différentes tables.

Voici un exemple dans le contexte de la maquette sur un routeur Spoke. Un jeu de règles a déjà été inséré dans la table raw. Elle permet de visualiser les compteurs de correspondance qui montrent que la règle a bien été utilisée.

sudo nft list table inet raw

table inet raw {
    chain rpfilter {
        type filter hook prerouting priority raw; policy accept;
        iifname "ppp0" fib saddr . iif oif 0 counter packets 10 bytes 280 drop
    }
}

	Avertissement
	Si aucune règle n'a été implantée dans une table, le résultat de la commande produit une erreur.

On débute les tests avec le protocole IPv4 et la commande hping3.

Voici un exemple de test effectué sur le routeur Hub dans lequel l'option -a désigne l'adresse IPv4 source usurpée tandis que l'adresse en bout de ligne désigne la destination. Ici, on cherche à contacter un conteneur avec l'adresse source d'un conteneur voisin en étant placé “à l'extérieur” du VLAN vert.

sudo hping3 -1 -a 10.0.10.12 --fast -c 10 10.0.10.10

HPING 10.0.10.10 (ppp0 10.0.10.10): icmp mode set, 28 headers + 0 data bytes

--- 10.0.10.10 hping statistic ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Côté routeur Hub, on constate qu'aucune réponse n'a été reçue.

Côté routeur Spoke, on affiche le jeu des règles de filtrage actif et on relève les valeurs des compteurs de paquets jetés.

sudo nft list table inet raw

table inet raw {
    chain rpfilter {
        type filter hook prerouting priority raw; policy accept;
        iifname "ppp0" fib saddr . iif oif 0 counter packets 20 bytes 560 drop
    }
}

Dans l'exemple ci-dessus, 20 paquets ont été jetés.

Pour le protocole IPv6, il n'existe pas de solution équivalente à l'utilisation de la commande hping3. De plus, le fait d'utiliser une session PPP pour acheminer le trafic ne facilite pas les tests.

C'est la raison pour laquelle on utilise un autre artifice : une interface de type dummy. Cette interface est factice et nous permet d'émettre des requêtes ICMP6 avec son adresse IPv6.

Voici comment créer une interface et lui ajouter une adresse. On commence par charger le module dummy en précisant que nous besoin d'une seule interface.

sudo modprobe -v dummy numdummies=1

sudo ip link set dev dummy0 up

On peut maintenant ajouter une adresse IPv6 appartenant au réseau d'hébergement situé au-delà du routeur Spoke à cette interface.

sudo ip -6 addr add fda0:7a62:a::e/64 dev dummy0

On modifie la table de routage pour s'assurer que les paquets partiront en direction de la session PPP.

sudo ip -6 route del fda0:7a62:a::/64 dev dummy0
sudo ip -6 route add fda0:7a62:a::/64 dev dummy0 metric 2048

On vérifie la solution d'acheminement du trafic à destination du réseau d'hébergement des conteneurs.

ip -6 route get fda0:7a62:a::a
fda0:7a62:a::a from :: dev ppp0 src fda0:7a62:a::e metric 1024 pref medium

Il ne reste plus qu'à lancer des requêtes ICMP6 avec cette adresse source.

sudo ping6 -c 10 fda0:7a62:a::a

PING fda0:7a62:a::a (fda0:7a62:a::a) from fda0:7a62:a::e dummy0: 56 data bytes

--- fda0:7a62:a::a ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9210ms

Là encore, aucune réponse n'est revenue et c'est heureux !

Si on relève le compte des paquets jetés côté routeur Spoke, on voit que toutes les requêtes sont tombées dans la règle de la table raw.

sudo nft list table inet raw

table inet raw {
    chain rpfilter {
        type filter hook prerouting priority raw; policy accept;
        iifname "ppp0" fib saddr . iif oif 0 counter packets 40 bytes 4160 drop
    }
}

	Attention
	N'oubliez pas de supprimer l'interface dummy après les tests. sudo ip link set dev dummy0 down sudo modprobe -r dummy

Il existe un réglage du sous-système réseau du noyau avec la clé rp_filter. Voici un extrait de la documentation du noyau.

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
    Each incoming packet is tested against the FIB and if the interface
    is not the best reverse path the packet check will fail.
    By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
    Each incoming packet's source address is also tested against the FIB
    and if the source address is not reachable via any interface
    the packet check will fail.

Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.

The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.

Default value is 0. Note that some distributions enable it
in startup scripts.

On peut fixer la clé à 1 et lancer un test avec une série d'adresses IPv4 source aléatoires.

sudo sysctl -w net.ipv4.conf.all.rp_filter=1

Voici un exemple de commande qui provoquera un nombre de blocages aléatoire en fonction des correspondances.

sudo hping3 -1 --rand-source --fast -c 100 10.0.10.10

Dans ce cas, c'est la fonction de protection du noyau qui a détecté des paquets “martiens” pour lesquels il n'existe aucune solution de routage.

journalctl -n 500 -f --grep martian

spoke1 kernel: IPv4: martian source 10.0.10.10 from 239.9.60.83, on dev ppp0
spoke1 kernel: IPv4: martian source 10.0.10.10 from 225.61.235.216, on dev ppp0
spoke1 kernel: IPv4: martian source 10.0.10.10 from 234.137.124.42, on dev ppp0
spoke1 kernel: IPv4: martian source 10.0.10.10 from 225.151.17.117, on dev ppp0
spoke1 kernel: IPv4: martian source 10.0.10.10 from 227.163.239.170, on dev ppp0
spoke1 kernel: IPv4: martian source 10.0.10.10 from 227.27.22.34, on dev ppp0
spoke1 kernel: IPv4: martian source 10.0.10.10 from 233.200.216.31, on dev ppp0

Il s'agit de la chaîne prerouting qui traite les flux réseau “au plus tôt”, avant qu'une décision de routage soit prise.

Voici un exemple d'envoi de requêtes ICMP en nombre à destination du deuxième conteneur hébergé sur le premier routeur Spoke.

sudo hping3 -1 --flood -c 10 10.0.10.11

Si le temps d'exécution de ces émission paraît trop long, il ne faut pas hésiter à interrompre l'émission avec Ctrl+C.

HPING 10.0.10.11 (ppp0 10.0.10.11): icmp mode set, 28 headers + 0 data bytes
hping in flood mode, no replies will be shown

--- 10.0.10.11 hping statistic ---
61492309 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Les résultats de cette commande montrent que le mécanisme de protection a bien fonctionné. On doit aussi vérifier qu'une émission “raisonnable“ de requêtes ICMP donne des résultats corrects.

ping -qc 10 10.0.10.11

PING 10.0.10.11 (10.0.10.11) 56(84) bytes of data.

--- 10.0.10.11 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.056/1.279/2.034/0.268 ms

Côté routeur Spoke “cible”, on peut relever les compteurs des règles de traitement ICMP et constater qu'un grand nombre de paquets ont été jetés.

sudo nft list table inet raw

table inet raw {
    chain rpfilter {
        type filter hook prerouting priority raw; policy accept;
        iifname "ppp0" fib saddr . iif oif 0 counter packets 0 bytes 0 drop
    }

    chain icmpfilter {
        type filter hook prerouting priority raw; policy accept;
        icmp type echo-request limit rate 10/second burst 5 packets counter packets 5378 bytes 150584 accept
        icmp type echo-request counter packets 90460174 bytes 2532884872 drop
    }
}

Voici un exemple de tentative de saturation à destination du deuxième conteneur du réseau d'hébergement du premier routeur Spoke.

sudo ping -6 -c100 -i 0.0005 -f fda0:7a62:a::b

En réponse à cette commande, on voit que le taux de perte de paquets est important.

PING fda0:7a62:a::b (fda0:7a62:a::b) 56 data bytes
..................................................................................
--- fda0:7a62:a::b ping statistics ---
100 packets transmitted, 18 received, 82% packet loss, time 1315ms
rtt min/avg/max/mdev = 0.316/0.845/2.057/0.334 ms, ipg/ewma 13.281/0.931 ms

Côte routeur “cible”, on relève à nouveau un grand nombre de paquets jetés.

sudo nft list table inet raw

table inet raw {
        chain rpfilter {
                type filter hook prerouting priority raw; policy accept;
                iifname "ppp0" fib saddr . iif oif 0 counter packets 0 bytes 0 drop
        }

        chain icmpfilter {
                type filter hook prerouting priority raw; policy accept;
                icmpv6 type echo-request limit rate 10/second burst 5 packets counter packets 93 bytes 9672 accept
                icmpv6 type echo-request counter packets 485 bytes 50440 drop
        }
}

Comme on l'a fait pour le protocole IPv4, on vérifie qu'on obtient un retour correct suite à des requêtes émises “à un rythme normal”.

ping -qc10 fda0:7a62:a::b

PING fda0:7a62:a::b (fda0:7a62:a::b) 56 data bytes

--- fda0:7a62:a::b ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9018ms
rtt min/avg/max/mdev = 0.839/1.055/1.191/0.097 ms

sudo apt -y install fail2ban

apt show fail2ban | grep  Description

Description : ban hosts that cause multiple authentication errors Fail2ban

Fail2ban est un outil de sécurité qui analyse les journaux système pour détecter et empêcher les attaques par force brute sur les serveurs. Il bloque automatiquement les adresses IP suspectes après plusieurs tentatives de connexion infructueuses au cours d'une période donnée en mettant à jour les règles du pare-feu. Cette application prend en charge différents services, dont SSH, et offre des paramètres personnalisables pour améliorer la protection des serveurs contre les attaques automatisées.

Dans le contexte de la maquette, le service SSH a été paramétré pour utiliser le port numéro 2222. On obtient la liste des ports en écoute avec les commandes lsof ou ss.

sudo lsof -i tcp:2222 -sTCP:listen

COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd    672 root    7u  IPv4   7601      0t0  TCP *:2222 (LISTEN)
sshd    672 root    8u  IPv6   7603      0t0  TCP *:2222 (LISTEN)

ss -tapl '( sport = :2222 )' | fmt -t -w80

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*
LISTEN 0      128             [::]:2222         [::]:*

Ce sont donc les tentatives de connexion au service SSH sur le port numéro 2222 que le service fail2ban doit surveiller.

Pour traiter la demande, on créé un fichier spécifique dans le répertoire dédié : /etc/fail2ban/jail.d/custom-sshd.conf qui contient tous les paramètres utiles.

cat << EOF | sudo tee /etc/fail2ban/jail.d/custom-sshd.conf
[sshd]
enabled = true
port = 2222
filter = sshd
backend = systemd
banaction = nftables-multiport
maxretry = 3
bantime = 1h
findtime = 10m
EOF

De manière classique, il convient de redémarrer le service pour que le nouveau fichier de configuration soit pris en compte.

sudo systemctl restart fail2ban

L'affichage de l'état du service n'a rien de spécifique à fail2ban, mais c'est le point de départ obligatoire.

systemctl status fail2ban.service

Les mots clé recherchés sont : enabled et active (running).

Pour la partie plus spécifique à fail2ban, on liste les fichiers contenus dans le paquet du même nom.

dpkg -L fail2ban | grep bin

/usr/bin
/usr/bin/fail2ban-client
/usr/bin/fail2ban-regex
/usr/bin/fail2ban-server
/usr/bin/fail2ban-testcases
/usr/bin/fail2ban-python

C'est la commande fail2ban-client qui nous intéresse. La recherche du mot clé status dans les pages de manuels donne le mode opératoire pour accéder au statut des services traités.

sudo fail2ban-client status

Status
|- Number of jail:      1
`- Jail list:   sshd

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

On commence par lancer plusieurs tentatives (au moins 3) de connexion SSH à partir du routeur Hub.

ssh -p 2222 etu@10.44.1.2
etu@10.44.1.2's password:
Permission denied, please try again.
etu@10.44.1.2's password:
Permission denied, please try again.
etu@10.44.1.2's password:
etu@10.44.1.2: Permission denied (publickey,password)

Une fois le mécanisme de blocage activé, il est impossible de tenter une nouvelle connexion.

ssh -p 2222 etu@10.44.1.2
ssh: connect to host 10.44.1.2 port 2222: Connection refused

On relève ensuite les résultats côté routeur Spoke.

L'état de la quarantaine montre que l'adresse IPv4 du routeur Hub sur le lien PPP est en quarantaine.

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     3
|  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   10.44.1.1

La liste des règles de filtrage montre qu'une nouvelle chaîne a été ajoutée. Dans cette chaîne, on reconnaît l'adresse IPv4 du lien PPP côté Hub.

sudo nft list ruleset

En limitant l'affichage à la table ajoutée par le service fail2ban, on obtient le jeu de règles suivant.

sudo nft list table inet f2b-table

table inet f2b-table {
    set addr-set-sshd {
        type ipv4_addr
        elements = { 10.44.1.1 }
    }

    chain f2b-chain {
        type filter hook input priority filter - 1; policy accept;
        tcp dport 2222 ip saddr @addr-set-sshd reject with icmp port-unreachable
    }
}

Enfin, on répète l'opération avec l'adresse IPv6 du routeur Spoke sur le lien PPP.

ssh -p 2222 etu@fe80::c59:5d57:7476:13cc%ppp0
etu@fe80::c59:5d57:7476:13cc%ppp0's password:
Permission denied, please try again.
etu@fe80::c59:5d57:7476:13cc%ppp0's password:
Permission denied, please try again.
etu@fe80::c59:5d57:7476:13cc%ppp0's password:
etu@fe80::c59:5d57:7476:13cc%ppp0: Permission denied (publickey,password).

ssh -p 2222 etu@fe80::c59:5d57:7476:13cc%ppp0
ssh: connect to host fe80::c59:5d57:7476:13cc%ppp0 port 2222: Connection refused

On voit apparaître une nouvelle adresse dans la liste sur le routeur Spoke.

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     6
|  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned: 2
   |- Total banned:     2
   `- Banned IP list:   10.44.1.1 fe80::f153:4881:c7c4:f371

Les règles de filtrage pour le protocole IPv6 ont aussi été complétées.

sudo nft list table inet f2b-table

table inet f2b-table {
    set addr-set-sshd {
        type ipv4_addr
        elements = { 10.44.1.1 }
    }

    set addr6-set-sshd {
        type ipv6_addr
        elements = { fe80::f153:4881:c7c4:f371 }
    }

    chain f2b-chain {
        type filter hook input priority filter - 1; policy accept;
        tcp dport 2222 ip saddr @addr-set-sshd reject with icmp port-unreachable
        tcp dport 2222 ip6 saddr @addr6-set-sshd reject with icmpv6 port-unreachable
    }
}