L'internet rapide et permanent

Outils pour utilisateurs

Outils du site

Vous êtes ici : L'internet rapide et permanent » Un pare-feu adaptatif » Surveillance de sshd

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
140-pare-feu-fail2ban:20-config-sshd [le 30/06/2025 à 15:56] – [Dans les journaux] prof140-pare-feu-fail2ban:20-config-sshd [le 05/07/2025 à 14:25] (Version actuelle) – [fail2ban a-t-il de la mémoire ?] prof
Ligne 43: Ligne 43:
 31 tentatives en 16 heures. La configuration de fail2ban est telle que des adresses repérées deux fois en moins de 600 secondes sont bannies 1 mois. Il n'est donc pas paranoïaque de protéger sévèrement sshd. 31 tentatives en 16 heures. La configuration de fail2ban est telle que des adresses repérées deux fois en moins de 600 secondes sont bannies 1 mois. Il n'est donc pas paranoïaque de protéger sévèrement sshd.
 ===== Une configuration possible ===== ===== Une configuration possible =====
 +En relisant les divers fichiers de configuration, nous voyons que:
  
 Dans ''jail.conf'': Dans ''jail.conf'':
Ligne 53: Ligne 54:
   - action = %(action_)s   - action = %(action_)s
  
-Debian installe un unique fichier dans ce répertoire ''defaults-debian.conf'' qui contient:+Dans ''jail.d'' Debian installe un unique fichier dans ce répertoire ''defaults-debian.conf'' qui contient:
 <html><pre class="code"> <html><pre class="code">
 [DEFAULT] [DEFAULT]
Ligne 66: Ligne 67:
 Debian protège donc ssh par défaut. Nous allons modifier un peu, mais avant, voyons le principe: Debian protège donc ssh par défaut. Nous allons modifier un peu, mais avant, voyons le principe:
   - la source des informations (backend), c'est le journal géré par systemd   - la source des informations (backend), c'est le journal géré par systemd
-  - ce qu'il faut observer dans le journal (journalmatch) c'est :\  ''SYSTEMD_UNIT=ssh.service + _COMM=sshd''+  - ce qu'il faut observer dans le journal (journalmatch) c'est :\  ''SYSTEMD_UNIT=ssh.service + _COMM=sshd'' que nous avons eu l'occasion de tester plus haut, sur les logs d'un serveur en production.
   - le filtre est actif (enabled = true)   - le filtre est actif (enabled = true)
 Toutes les autres directives sont données dans les divers paragraphes [DEFAULT] déjà rencontrés lors de la lecture séquentielle de la configuration. Toutes les autres directives sont données dans les divers paragraphes [DEFAULT] déjà rencontrés lors de la lecture séquentielle de la configuration.
  
-Nous allons casser le fichier ''defaults-debian.conf'', renommé en ''000-defaults.conf'' et qui contiendra:+Nous allons casser le fichier ''defaults-debian.conf'', renommé en ''000-defaults.conf'' et qui ne contiendra plus que :
 <html><pre class="code"> <html><pre class="code">
 [DEFAULT] [DEFAULT]
Ligne 97: Ligne 98:
  
  
- 
-Commençons pas dissocier dans le répertoire ''jail.d''  
  
  
Ligne 124: Ligne 123:
 </code> </code>
 Nous pouvons désormais supprimer le fichier ''defaults-debian.conf''. Nous pouvons désormais supprimer le fichier ''defaults-debian.conf''.
 +==== Tests ====
 +Pour rappel, le filtre installé au démarrage du serveur de test est le suivant:
 +<code>table inet filter {
 + chain input_ipv4 {
 + icmp type echo-request limit rate 5/second burst 5 packets accept
 + }
 +
 + chain input_ipv6 {
 + icmpv6 type { nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
 + icmpv6 type echo-request limit rate 5/second burst 5 packets accept
 + }
 +
 + chain input {
 + type filter hook input priority filter; policy drop;
 + iifname "lo" accept
 + ct state vmap { invalid : drop, established : accept, related : accept }
 + meta protocol vmap { ip : jump input_ipv4, ip6 : jump input_ipv6 }
 + tcp dport { 22, 80, 443 } accept
 + }
 +}
 +</code>
 +Un attaquant, lui aussi virtuel, dont la configuration IP est la suivante:
 +      inet 192.168.60.76/24 brd 192.168.60.255 scope global dynamic
 +      inet6 2a01:e0a:875:b1d0:f80d:77c3:5e30:243a/64 scope global dynamic
 +Va essayer (maladroitement) de forcer ssh sur le serveur de test.
 +
 +Nous observons pendant ce temps les logs au fil de l'eau, tel que les voit fail2ban:
 +
 +<html><pre class="code">
 +<b>journalctl _SYSTEMD_UNIT=ssh.service + _COMM=sshd -f</b>
 +
 +<span class="hly">juin 30 18:19:13 trixie-nft sshd-session[1040]: Invalid user admin from 2a01:e0a:875:b1d0:5054:ff:fefe:c099 port 55938
 +juin 30 18:19:18 trixie-nft sshd-session[1040]: pam_unix(sshd:auth): check pass; user unknown
 +juin 30 18:19:18 trixie-nft sshd-session[1040]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=2a01:e0a:875:b1d0:5054:ff:fefe:c099
 +juin 30 18:19:20 trixie-nft sshd-session[1040]: Failed password for invalid user admin from 2a01:e0a:875:b1d0:5054:ff:fefe:c099 port 55938 ssh2</span>
 +<span class="hlo">juin 30 18:21:01 trixie-nft sshd-session[1065]: Invalid user admin from 192.168.60.76 port 45056
 +juin 30 18:21:09 trixie-nft sshd-session[1065]: pam_unix(sshd:auth): check pass; user unknown
 +juin 30 18:21:09 trixie-nft sshd-session[1065]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.76
 +juin 30 18:21:11 trixie-nft sshd-session[1065]: Failed password for invalid user admin from 192.168.60.76 port 45056 ssh2</span>
 +<span class="hlg">juin 30 18:21:13 trixie-nft sshd[750]: Timeout before authentication for connection from 2a01:e0a:875:b1d0:5054:ff:fefe:c099 to 2a01:e0a:875:b1d0:5054:ff:fe79:7d6f, pid = 1040
 +juin 30 18:23:01 trixie-nft sshd[750]: Timeout before authentication for connection from 192.168.60.76 to 192.168.60.5, pid = 1065</span>
 +</pre></html>
 +L'attaquant, ce bourrin, s'est fait planter avec son adresse IPv6, mail il a insisté avec son adresse IPv4, ce qui a produit le même résultat.
 +
 +Sur le serveur, la configuration «nftables» a été dynamiquement mise à jour par fail2ban. Nous pouvons observer le résultat:
 +
 +<html><pre class="code">
 +<b>nft list ruleset</b>
 +
 +table inet filter {
 + chain input_ipv4 {
 + icmp type echo-request limit rate 5/second burst 5 packets accept
 + }
 +
 + chain input_ipv6 {
 + icmpv6 type { nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
 + icmpv6 type echo-request limit rate 5/second burst 5 packets accept
 + }
 +
 + chain input {
 + type filter hook input priority filter; policy drop;
 + iifname "lo" accept
 + ct state vmap { invalid : drop, established : accept, related : accept }
 + meta protocol vmap { ip : jump input_ipv4, ip6 : jump input_ipv6 }
 + tcp dport { 22, 80, 443 } accept
 + }
 +}
 +<span class="hly">table inet f2b-table {
 + set addr6-set-sshd {
 + type ipv6_addr
 + elements = { 2a01:e0a:875:b1d0:5054:ff:fefe:c099 }
 + }
 +
 + set addr-set-sshd {
 + type ipv4_addr
 + elements = { 192.168.60.76 }
 + }
 +
 + chain f2b-chain {
 + type filter hook input priority filter - 1; policy accept;
 + tcp dport 22 ip6 saddr @addr6-set-sshd reject with icmpv6 port-unreachable
 + tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable
 + }
 +}</span>
 +</pre></html>
 +
 +Fail2ban a créé une nouvelle table : «table inet f2b-table»
 +Dans cette table, il a créé:
 +  * deux «sets»:
 +    * **set addr6-set-sshd** destiné à collectionner les adresses IPv6 à bloquer;
 +    * **set addr-set-sshd** la même chose, mais pour les adresses IPv4.
 +  * une chaîne «chain f2b-chain» qui par défaut accepte tout sauf:
 +    * les adresses IPv6 collectées qui n'ont plus accès au port 22,
 +    * la même chose, mais pour les adresses IPv4.
 +Du bon vieux temps d'IPtables, fail2ban aurait créé une chaîne «f2b-ssh» dans laquelle il aurait ajouté une règle de blocage complète pour chaque adresse repérée, dans le style:
 +<code>
 +-A f2b-ssh -s 80.240.252.168/32 -j REJECT --reject-with icmp-port-unreachable
 +-A f2b-ssh -s 157.254.54.192/32 -j REJECT --reject-with icmp-port-unreachable
 +-A f2b-ssh -s 8.222.168.120/32 -j REJECT --reject-with icmp-port-unreachable
 +-A f2b-ssh -s 65.108.211.181/32 -j REJECT --reject-with icmp-port-unreachable
 +-A f2b-ssh -s 154.209.4.36/32 -j REJECT --reject-with icmp-port-unreachable
 +-A f2b-ssh -s 157.10.252.119/32 -j REJECT --reject-with icmp-port-unreachable
 +-A f2b-ssh -s 14.103.114.20/32 -j REJECT --reject-with icmp-port-unreachable
 +....
 +</code>
 +Et le même procédure pour les adresses IPv6. Si les «sets» existaient déjà avec iptables, fail2ban ne les utilisait pas (l'exemple est pris sur une Debian 11 mise à jour en Debian 12).
 +
 +La technique exposée avec fail2ban et nftables sur la trixie donne un résultat bien plus concis.
 +
 +Et du temps nécessaire à la rédaction de ces lignes, les 5 minutes de bannissement sont passées, et désormais:
 +<html><pre class="code">
 +<b>nft list table inet f2b-table</b>
 +
 +table inet f2b-table {
 +<span class="bhly"> set addr6-set-sshd {
 + type ipv6_addr
 + }
 +
 + set addr-set-sshd {
 + type ipv4_addr
 + }</span>
 +
 + chain f2b-chain {
 + type filter hook input priority filter - 1; policy accept;
 + tcp dport 22 ip6 saddr @addr6-set-sshd reject with icmpv6 port-unreachable
 + tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable
 + }
 +}
 +</pre></html>
 +Si la structure ajoutée par fail2ban est toujours intacte, les sets ont quant-à-eux été purgés.
 +
 +==== Aménagement du filtre ====
 +Certains filtres, dont ''sshd.conf'', proposent des modes de fonctionnement. Ces modes agissent sur le choix des expressions régulières utilisées pour le filtrage.
 +
 +Des explications, plus ou moins sibyllines, peuvent se trouver dans le fichier de filtre lui-même. Pour ''sshd.conf'', nous trouvons:
 +<html><pre class="code">
 +<span class="txtb"># Parameter "mode": normal (default), ddos, extra or aggressive (combines all)
 +# Usage example (for jail.local):
 +#   [sshd]
 +#   mode = extra
 +#   # or another jail (rewrite filter parameters of jail):
 +#   [sshd-aggressive]
 +#   filter = sshd[mode=aggressive]
 +#</span>
 +<span class="hly">mode = normal</span>
 +</pre></html>
 +Hélas, la maîtrise de ces modes suppose non seulement celle des expressions régulières, mais également celle des [[https://fail2ban.readthedocs.io/en/latest/filters.html|règles de création des filtres]]. Si le mode «ddos» peut laisser supposer qu'il s'intéresse essentiellement aux attaques par déni de service distribuées, le mode «extra» est plus obscur.
 +
 +Le mode «normal» sélectionné par défaut est généralement satisfaisant.
 +===== Analyse plus profonde =====
 +
 +
 +
 +==== fail2ban a-t-il de la mémoire ? ====
 +Nous allons considérablement rallonger la durée de bannissement, pour vérifier ce qu'il se passerait pour les adresses bannies en cas de redémarrage de l'hôte:
 +  findtime = 10minutes
 +  bantime = 1hour
 +Le fait de changer la configuration oblige à la faire relire par fail2ban. La commande «fail2ban-client» permet de le faire de façon élégante:
 +<html>pre class="code">
 +<b>fail2ban reload sshd</b>
 +
 +OK
 +</pre></html>
 +(«OK» étant le signe que la commande a bien été prise en compte).
 +
 +
 +Le même pirate va re-tenter sa chance, va se faire de nouveau coincer. Nous retrouvons son adresse dans le «set» idoine:
 +<code>
 +table inet f2b-table {
 + set addr6-set-sshd {
 + type ipv6_addr
 + elements = { 2a01:e0a:875:b1d0:f80d:77c3:5e30:243a }
 + }
 +
 + chain f2b-chain {
 + type filter hook input priority filter - 1; policy accept;
 + tcp dport 22 ip6 saddr @addr6-set-sshd reject with icmpv6 port-unreachable
 + }
 +}
 +</code>
 +Reboot de la machine et contrôle de l'état du pare-feu. Nous retrouvons bien le bannissement:
 +<html><pre class="code">
 +<b>nft list table inet f2b-table</b>
 +
 +table inet f2b-table {
 + set addr6-set-sshd {
 + type ipv6_addr
 + elements = { 2a01:e0a:875:b1d0:f80d:77c3:5e30:243a }
 + }
 +
 + chain f2b-chain {
 + type filter hook input priority filter - 1; policy accept;
 + tcp dport 22 ip6 saddr @addr6-set-sshd reject with icmpv6 port-unreachable
 + }
 +}
 +</pre></html>
 +
 +fail2ban a bonne mémoire.
 +
 +Dans la foulée, nous pouvons également vérifier qu'une commande comme:
 +  systemctl restart fail2ban
 +n'efface pas pour autant sa mémoire.
 +==== L'outil «fail2ban-client» ====
 +Cet outil sert essentiellement à contrôler le fonctionnement du serveur fail2ban. Le manuel fournit (en anglais) tous les détails de son utilisation.
 +Voici quelques-uns de ses usages:
 +  * **fail2ban-client ping** permet de savoir si le serveur est vivant. S'il l'est, il répond simplement: «pong»,
 +  * **fail2ban-client status** retourne l'état du serveur. exemple:\\ <code>Status
 +|- Number of jail: 1
 +`- Jail list: ssh</code>
 +  * **fail2ban-client start/stop/reload <JAIL>** permet de démarrer, arrêter, recharger la configuration d'une prison,
 +  * **fail2ban-client get <JAIL> banned** retourne la liste des adresses IP bannies dans la prison indiquée. Exemple: \\  <code>['1.202.223.2', '101.126.14.37', '101.126.151.131', '101.126.81.188', '101.126.88.203', '101.126.89.164', '101.126.91.34', '101.36.108.134', '101.36.122.23', '101.36.231.231', '102.140.97.134', '102.210.80.6', '102.215.218.114', '103.106.194.74', '103.112.54.86', '103.113.105.228', '103.116.177.252', '103.117.56.152', '103.120.227.88', '103.123.227.244', '103.137.194.125', '103.139.192.247']</code>Notons que le résultat est sous la forme d'un tableau python (fail2ban est écrit en python).
 +  * **fail2ban-client unban <IP> ... <IP>** Permet de sortir une liste d'adresses IP de prison, quelle que soit sa prison.
 +  * etc.
  
Surveillance de sshd: Dernière modification le: 30/06/2025 à 15:56 par prof