The Linux Craftsman - Contributions [fr]

Proxmox fail2ban

2026-07-13T09:43:20Z

Jc.forton : /* Comment bannir derrière un reverse-proxy ? */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Dans cette exemple:
* le nom de domaine utilisé est '''pve.tala-informatique.fr'''
* l'adresse du proxy est '''192.168.4.100'''
* l'adresse du serveur Proxmox est '''192.168.4.1'''
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de mod_md abordée dans cette [[Httpd_certificate_security#Let's_Encrypt |article]] et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]
<source lang=apache>
MDomain pve.tala-informatique.fr
</source>

Le bloc suivant permet de [[Httpd_redirect_reverse-proxy_mod-rewrite#http_→_https | renvoyer les utilisateurs]] se présentant sur le port 80 vers le port 443
<source lang=apache>
<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>
</source>

Dans le bloc ''443'', on est obligé de désactiver les vérifications SSL parce que le certificat du serveur Proxmox est autosigné (donc pas de cadenas vert), ce qui pousse Apache à bloquer la connexion si on ne désactive pas ces vérifications
<source lang=apache>
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
</source>
La réécriture d'url doit être configuré pour prendre en compte les ''websockets sécurisées'' (wss) utilisées pour l'affichage de l'écran des machine ou conteneurs avec ''xterm.js''
<source lang=apache>
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]
</source>
Enfin on redirige les requêtes vers le serveur Proxmox en n'oubliant pas de préciser le port 8006
<source lang=apache>
ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
</source>
== Problème lié à la proxyfication ==
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=192.168.4.100 user=root@pam msg=Authentication failure
</pre>

== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-13T09:41:48Z

Jc.forton : /* Problème lié à la proxyfication */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Dans cette exemple:
* le nom de domaine utilisé est '''pve.tala-informatique.fr'''
* l'adresse du proxy est '''192.168.4.100'''
* l'adresse du serveur Proxmox est '''192.168.4.1'''
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de mod_md abordée dans cette [[Httpd_certificate_security#Let's_Encrypt |article]] et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]
<source lang=apache>
MDomain pve.tala-informatique.fr
</source>

Le bloc suivant permet de [[Httpd_redirect_reverse-proxy_mod-rewrite#http_→_https | renvoyer les utilisateurs]] se présentant sur le port 80 vers le port 443
<source lang=apache>
<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>
</source>

Dans le bloc ''443'', on est obligé de désactiver les vérifications SSL parce que le certificat du serveur Proxmox est autosigné (donc pas de cadenas vert), ce qui pousse Apache à bloquer la connexion si on ne désactive pas ces vérifications
<source lang=apache>
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
</source>
La réécriture d'url doit être configuré pour prendre en compte les ''websockets sécurisées'' (wss) utilisées pour l'affichage de l'écran des machine ou conteneurs avec ''xterm.js''
<source lang=apache>
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]
</source>
Enfin on redirige les requêtes vers le serveur Proxmox en n'oubliant pas de préciser le port 8006
<source lang=apache>
ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
</source>
== Problème lié à la proxyfication ==
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=192.168.4.100 user=root@pam msg=Authentication failure
</pre>

== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-13T09:41:15Z

Jc.forton : /* Configuration du reverse-proxy */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Dans cette exemple:
* le nom de domaine utilisé est '''pve.tala-informatique.fr'''
* l'adresse du proxy est '''192.168.4.100'''
* l'adresse du serveur Proxmox est '''192.168.4.1'''
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de mod_md abordée dans cette [[Httpd_certificate_security#Let's_Encrypt |article]] et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]
<source lang=apache>
MDomain pve.tala-informatique.fr
</source>

Le bloc suivant permet de [[Httpd_redirect_reverse-proxy_mod-rewrite#http_→_https | renvoyer les utilisateurs]] se présentant sur le port 80 vers le port 443
<source lang=apache>
<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>
</source>

Dans le bloc ''443'', on est obligé de désactiver les vérifications SSL parce que le certificat du serveur Proxmox est autosigné (donc pas de cadenas vert), ce qui pousse Apache à bloquer la connexion si on ne désactive pas ces vérifications
<source lang=apache>
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
</source>
La réécriture d'url doit être configuré pour prendre en compte les ''websockets sécurisées'' (wss) utilisées pour l'affichage de l'écran des machine ou conteneurs avec ''xterm.js''
<source lang=apache>
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]
</source>
Enfin on redirige les requêtes vers le serveur Proxmox en n'oubliant pas de préciser le port 8006
<source lang=apache>
ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
</source>
== Problème lié à la proxyfication ==
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>

== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-13T09:39:45Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Dans cette exemple:
* le nom de domaine utilisé est '''pve.tala-informatique.fr'''
* l'adresse du proxy est '''192.168.4.100'''
* l'adresse du serveur Proxmox est '''192.168.4.1'''
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de mod_md abordée dans cette [[Httpd_certificate_security#Let's_Encrypt |article]] et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]
<source lang=apache>
MDomain pve.tala-informatique.fr
</source>

Le bloc suivant permet de [[Httpd_redirect_reverse-proxy_mod-rewrite#http_→_https | renvoyer les utilisateurs]] se présentant sur le port 80 vers le port 443
<source lang=apache>
<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>
</source>

Dans le bloc ''443'', on est obligé de désactiver les vérifications SSL parce que le certificat du serveur Proxmox est autosigné (donc pas de cadenas vert), ce qui pousse Apache à bloquer la connexion si on ne désactive pas ces vérifications
<source lang=apache>
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
</source>
La réécriture d'url doit être configuré pour prendre en compte les ''websockets sécurisées'' (wss) utilisées pour l'affichage de l'écran des machine ou conteneurs avec ''xterm.js''
<source lang=apache>
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]
</source>
Enfin on redirige les requêtes vers le serveur Proxmox en n'oubliant pas de préciser le port 8006
<source lang=apache>
ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
</source>

Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>

== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-13T09:37:55Z

Jc.forton : /* Configuration du reverse-proxy */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de mod_md abordée dans cette [[Httpd_certificate_security#Let's_Encrypt |article]] et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]
<source lang=apache>
MDomain pve.tala-informatique.fr
</source>

Le bloc suivant permet de [[Httpd_redirect_reverse-proxy_mod-rewrite#http_→_https | renvoyer les utilisateurs]] se présentant sur le port 80 vers le port 443
<source lang=apache>
<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>
</source>

Dans le bloc ''443'', on est obligé de désactiver les vérifications SSL parce que le certificat du serveur Proxmox est autosigné (donc pas de cadenas vert), ce qui pousse Apache à bloquer la connexion si on ne désactive pas ces vérifications
<source lang=apache>
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
</source>
La réécriture d'url doit être configuré pour prendre en compte les ''websockets sécurisées'' (wss) utilisées pour l'affichage de l'écran des machine ou conteneurs avec ''xterm.js''
<source lang=apache>
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]
</source>
Enfin on redirige les requêtes vers le serveur Proxmox en n'oubliant pas de préciser le port 8006
<source lang=apache>
ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
</source>

Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>

== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-13T09:36:25Z

Jc.forton : /* Configuration du reverse-proxy */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de [[Httpd_certificate_security#Let's_Encrypt |mod_md]] sur mon site et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]
<source lang=apache>
MDomain pve.tala-informatique.fr
</source>

Le bloc suivant permet de [[Httpd_redirect_reverse-proxy_mod-rewrite#http_→_https | renvoyer les utilisateurs]] se présentant sur le port 80 vers le port 443
<source lang=apache>
<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>
</source>

Dans le bloc ''443'', on est obligé de désactiver les vérifications SSL parce que le certificat du serveur Proxmox est autosigné, ce qui pousse Apache à bloquer la connexion si on ne désactive pas les vérifications
<source lang=apache>
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
</source>
La réécriture d'url doit être configuré pour prendre en compte les ''websockets sécurisées'' (wss) utilisées pour l'affichage de l'écran des machine ou conteneurs avec ''xterm.js''
<source lang=apache>
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]
</source>
Enfin on redirige les requêtes vers le serveur Proxmox en n'oubliant pas de préciser le port 8006
<source lang=apache>
ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
</source>

Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>

== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-13T09:27:56Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
== Configuration du reverse-proxy ==
Sur votre reverse-proxy Apache, vous devriez avoir une configuration qui ressemble à ça:
<source lang=apache>
MDomain pve.tala-informatique.fr

<VirtualHost *:80>
ServerName pve.tala-informatique.fr
Redirect / https://pve.tala-informatique.fr/
</VirtualHost>

<VirtualHost *:443>
ServerName pve.tala-informatique.fr

SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests off
ProxyPreserveHost On

RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) wss://192.168.4.1:8006/$1 [P,L]

ProxyPass / https://192.168.4.1:8006/ flushpackets=On connectiontimeout=300 timeout=300
ProxyPassReverse / https://192.168.4.1:8006/
ProxyTimeout 600

</VirtualHost>
</source>

La première ligne renvoie à la configuration de mod_md et permet l'obtention du certificat SSL auprès de [https://letsencrypt.org Let's encrypt]

Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-11T17:08:38Z

Jc.forton : /* Invention d'une API pour fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
[[Fichier:Warning-icon.png|40px]] Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-11T16:53:03Z

Jc.forton : /* Modification des actions fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-11T16:52:36Z

Jc.forton : /* Modification des actions fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:
* pour bannir
<source lang=bash>
# fail2ban-client set proxmox banip 1.2.3.4
</source>
* pour dé-bannir:
<source lang=bash>
# fail2ban-client unban proxmox 1.2.3.4
</source>
Et vérifier sur le reverse-proxy que les modification sont bien prises en compte:

Proxmox fail2ban

2026-07-11T16:50:54Z

Jc.forton : /* Modification des actions fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:
<source lang=bash>
# systemctl restart fail2ban
</source>
Et vous pouvez tester les commandes suivantes:

Proxmox fail2ban

2026-07-11T16:50:10Z

Jc.forton : /* Modification des actions fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/f2b-api.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Veuillez noter que:
* même si elles sont vide, les lignes ''actionstart'', ''actionstop'' et ''actioncheck'' sont obligatoires !
* l'adresse ''192.168.4.100'' doit être remplcée par celle de votre reverse-proxy
* <ip> est l'expression utilisée par fail2ban et elle sera remplacée par l'IP à bannir

Pour ce fichier d'action soit pris en compte, il faut modifier le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' pour y ajouter:
<pre>
banaction = f2b-api
</pre>
Il ne vous reste plus qu'a redémarrer le service fai2ban sur le serveur Proxmox:

Proxmox fail2ban

2026-07-11T16:37:15Z

Jc.forton : /* Invention d'une API pour fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1:8080/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>
Nous n'allons pas lancer nous même le serveur PHP, nous allons demander à SystemD de le faire et pour cela nous allons créer le fichier ''/opt/f2b-api/f2b-api.service'':
<pre>
[Unit]
Description=fail2ban API Server
After=network-online.target

[Service]
Type=simple
UMask=007
ExecStart=php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/f2b-api.php
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

Il faut maintenant demander à SystemD de s'occuper de notre service:
<source lang=bash>
# systemctl link /opt/f2b-api/f2b-api.service
</source>

Et de le lancer au démarrage du reverse-proxy:
<source lang=bash>
# systemctl enable f2b-api --now
</source>

Nous pouvons maintenant nous déplacer sur le serveur Proxmox pour modifier fail2ban !

=== Modification des actions fail2ban ===
Sur le serveur Proxmox nous allons débrayer le comportement de base de fail2ban qui est de modifier iptables. pour cela nous alons créer le fichier ''/etc/fail2ban/action.d/proxmox.conf :
<pre>
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = curl -X GET 192.168.4.100:8080/ban/<ip>
actionunban = curl -X GET 192.168.4.100:8080/unban/<ip>
</pre>
Remplacer l'adresse ''192.168.4.100'' par celle de votre reverse-proxy

Proxmox fail2ban

2026-07-11T16:31:12Z

Jc.forton : /* Invention d'une API pour fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/index.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/ban/1.2.3.4
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/1.2.3.4
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-11T16:30:50Z

Jc.forton : /* Invention d'une API pour fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/index.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/ban/@ip
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /dev/null
`- Actions
|- Currently banned: 1
|- Total banned: 10
`- Banned IP list: 1.2.3.4
</source>

Proxmox fail2ban

2026-07-11T16:29:51Z

Jc.forton : /* Invention d'une API pour fail2ban */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Toujours sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/index.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/ban/@ip
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>

Proxmox fail2ban

2026-07-11T16:29:37Z

Jc.forton : /* Création d'une prison sur le reverse-proxy */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

Après redémarrage de fail2ban :
<source lang=bash>
# systemctl restart fail2ban
</source>

Vous devriez voir la prison
<source lang=bash>
# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: proxmox, sshd
[root@proxy proxymox]#
</source>

Nous pouvons maintenant passer à l'API !

=== Invention d'une API pour fail2ban ===

Sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/index.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/ban/@ip
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>

Proxmox fail2ban

2026-07-11T16:27:51Z

Jc.forton :

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 5
findtime = 1d
bantime = 1w
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>

== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

== Comment bannir derrière un reverse-proxy ? ==
Maintenant que votre Proxmox est derrière un reverse-proxy, inutile de bannir les IP publiques avec iptables sur le serveur Proxmox, la seule IP visible est celle du reverse-proxy (dans cet exemple 192.168.4.100).

La seule machine capable capable de bannir est le reverse-proxy, il faut donc lui transmettre les IP et nous allons faire ça en trois étapes:
* la première est de créer une "prison" proxmox sur le fail2ban présent sur le reverse-proxy
* la deuxième est l'invention d'une API pour fail2ban sur le reverse-proxy
* la troisième est la modification du comportement de fail2ban pour appeler cette API au lieu de modifier iptables

=== Création d'une prison sur le reverse-proxy ===

Pour bannir nous allons créer une prison spécifique pour le / les serveurs Proxmox que nous allons appeler ''proxmox'' dans le fichier /etc/fail2ban/jail.d/proxmox.conf :
<pre>
[proxmox]
enabled = true
port = https,http
filter = do-nothing
logpath = /dev/null
maxretry = 3
findtime = 1d
bantime = 1w
</pre>

J'attire votre attention sur les paramètres ''maxretry'', ''findtime'' et ''bantime'' qui doivent concorder avec ceux du fail2ban de votre Proxmox. S'il sont plus ''court'' sur le reverse-proxy, les IP seront libérées plus tôt à l'inverse, plus long n'est pas gênant, le fail2ban de votre Proxmox les libéreras avant celui du proxy.

Vous avez remarquez le filtre ''do-nothing'' qu'il nous reste à créer dans le fichier ''/etc/fail2ban/filter.d/do-nothing.conf'' :
<pre>
[Definition]

failregex = ^<HOST>$
</pre>

=== Invention d'une API pour fail2ban ===

Sur le reverse-proxy nous allons installer PHP pour créer un mini serveur qui répondra au urls suivantes:
* /ban/<ip> pour bannir
* /unban/<ip> pour lever le banissement

Commençons par installer PHP:
<source lang=bash>
# dnf -y install php-cli
</source>

Nous allons créer un répertoire "f2b-api" dans le dossier "opt" :
<source lang=bash>
# mkdir /opt/f2b-api
</source>

Puis créer un fichier ''f2b-api.php'' dans ce dossier:
<source lang=php>
<?php

main();

function main() {
# On clean l'uri du / de début
$uri = ltrim($_SERVER['REQUEST_URI'], '/');
# On éclate l'uri en parties (action + ip)
$parts = explode('/', $uri);
# Récupération de l'action dans une variable ou false si vide
$action = empty($parts[0]) ? false : $parts[0];
# Récupération de l'ip dans une variable ou false si vide
$ip = empty($parts[1]) ? false : $parts[1];
if(!$action || !$ip){
# Si action vide => 400 Bad request
http_response_code(400);
die();
}
if(!in_array($action, ['ban', 'unban'])){
# Si action pas dans la liste => 400 Bad request
http_response_code(400);
die();
}
$cmd = '';
if($action == 'ban'){
$cmd = 'fail2ban-client set proxmox banip ' . $ip;
} else if($action == 'unban'){
$cmd = 'fail2ban-client unban proxmox ' . $ip;
}
shell_exec($cmd);
}
</source>
⚠ Gardez en tête que ce code simpliste n'est en aucun cas sécurisé et ne doit pas être accessible depuis Internet.

Pour démarrer se code en mode serveur il suffit de taper la commande suivante:
<source lang=bash>
# php -S 0.0.0.0:8080 -t /opt/f2b-api /opt/f2b-api/index.php
</source>

Vous pouvez tester directement depuis un autre terminal en tapant les commandes:
* pour bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/ban/@ip
</source>
* pour dé-bannir :
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>
Et en vérifiant dans fail2ban:
<source lang=bash>
# curl -X GET http://127.0.0.1/unban/@ip
</source>

Proxmox fail2ban

2026-07-11T15:37:47Z

Jc.forton : /* Automatisation */

Proxmox first start

2026-07-11T15:05:17Z

Jc.forton : /* Suppression du message d'abonnement */

= Introduction =

Maintenant que votre serveur Proxmox est installé, nous allons effectuer quelques opérations de configuration de bases comme :
* la modification des dépôts
* la mise à jour
* la suppression du message d'abonnement
* le nommage des cartes réseaux
* la personnalisation de l'environnement

= Modification des dépôts =
De base l'équipe de Proxmox vous incite à prendre un abonnement pour profiter des mise à jours et fonctionnalités nécessaires dans un datacenter.

[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Si comme moi, vous utilisez Proxmox dans le cadre d'un homelab, pas besoin de payer, la version ''basic'' est largement suffisante.
{|align=center
|-
|align=left|
Cliquez sur l'icône de votre serveur dans la barre à gauche
|width=10px|
|align=left|
Puis sur ''repositories''
|-
|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories menu.jpg|150px|centré]]
|}

On va dans un premier temps retirez les dépôts ''entreprise'' de Proxmox. Dès que vous voyez ''entreprise'' ou ''pve-entreprise'' dans la colonne ''Components'', il y a de grande chance que le dépôt nécessite un abonnement.

[[Fichier:proxmox repository remove.jpg|900px|centré]]

* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''
* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''

Une grosse croix rouge qui fait peur apparaît

[[Fichier:proxmox repository red corss.jpg|600px|centré]]

Pas de panique, nous allons ajouter le dépôt gratuit pour avoir quand même quelques mise à jours.

{|align=center
|-
|align=left|
Cliquez sur ''add''
|width=10px|
|align=left|
Puis sur ''No-Subscription''
|-
|valign=top|
[[Fichier:proxmox repository add.jpg|250px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories no-subscription.jpg|500px|centré]]
|}

Ouf, la méchante croix rouge à disparue :)

[[Fichier:proxmox repositories no-subscription warning.jpg|500px|centré]]

= Mise à jour =

Pour rappel, le serveur que nous allons mettre à jour vient d'être installé, et n'est donc pas encore en utilisation.

<span style=color:red>Si vous avez des serveur en production, qui sont utilisés par des clients ou dans le cadre de processus internes à votre entreprise, s'il vous plaît, ne mettez jamais, JAMAIS, jamais à jour ces serveurs.</span>

Vous n'avez aucune idée des impacts sur les versions des logiciels et vous risquez, en mettant à jour, de créer une incompatibilité et de faire tomber en panne des logiciels ou applications qui fonctionnaient parfaitement.

Les seules mise à jour que l'on s'autorise en production sont celles de sécurité qui servent à ''patcher'' une vulnérabilité. Et là encore, assurez-vous bien que rien ne va ''exploser''. Si c'est une machine virtuelle ou un conteneur, faites un snapshot ou une copie avant de procéder à la modification... surtout si c'est un vendredi à 17h 😢

Bon, vous êtes prévenu !

{|align=center
|-
|align=left|
Remontez d'un cran sur le bouton ''Updates''
|width=10px|
|align=left|
Puis cliquez sur ''Refresh'' pour mettre à jour la liste des paquetages disponibles
|-
|valign=top|
[[Fichier:proxmox update button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update refresh.jpg|100px|centré]]
|}

{|align=center
|-
|align=left|
Quand vous êtes prêt, cliquez sur ''Upgrade''
|width=10px|
|align=left|
une fenêtre et démarrer le processus de mise à jour
|-
|valign=top|
[[Fichier:proxmox upgrade button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update upgrade.jpg|600px|centré]]
|}

= Suppression du message d'abonnement =
Maintenant que les dépôt sont configuré et les mises à jour faites, on va désactiver ce message qui apparaît à chaque connexion au portail web de Proxmox.
[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Pour cela nous allons utiliser l'activateur de ''Jamesits'' disponible sur son [https://github.com/Jamesits/pve-fake-subscription GitHub]

Dans le menu de gauche, cliquez sur l’icône de votre serveur puis sur Shell
{|align=center
|-

|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
→
|valign=top|
[[Fichier:proxmox shell button.jpg|200px|centré]]
|}

Une fois dans le terminal nous allons utiliser la commande ''wget'' pour télécharger le paquetage sur la machine:

<source lang=bash>
# wget https://github.com/Jamesits/pve-fake-subscription/releases/download/v0.0.11/pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Le lien précédent est à récupérer sur la page de téléchargement du projet, assurer-vous d'y faire un tour pour vous assurer qu'il est toujours bon.

Il ne reste plus qu'a l'installer :
<source lang=bash>
# dpkg -i pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Il est recommandé de bloquer le site de vérification des clés en mettant une entrée factice dans le fichier ''hosts'' :
<source lang=bash>
# echo "127.0.0.1 shop.maurer-it.com" >> /etc/hosts
</source>

Vous pouvez vérifier que cela fonctionne en faisant un ping:
<source lang=bash>
root@pve-tuto:~# ping shop.maurer-it.com
PING shop.maurer-it.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.010 ms
...
</source>

Pour vérifier que le message à bien disparu, il vous suffit de vous déconnecter puis reconnecter !

= Nommage des cartes réseaux =

Lorsque vous ajoutez / retirez une carte sur un port PCI, les identifiants sont redistribués et cela va affecter le nom des cartes réseaux. Si la carte que vous utilisez pour vous connecter à votre serveur Proxmox (généralement sur le ''vmbr0'') change de nom, vous perdez la connexion à votre serveur... Pas très pratique !

Si vous avez une version supérieur à 9.2 et que vous avez suivie le tutoriel pour [[Proxmox_install | installer Proxmox]] vous avez déjà fixé le nom de votre carte de management, mais qu'en est-il des autres ? Vous l'aurez compris, il faut absolument fixer le noms des cartes pour éviter les surprises !

Une fois vos [[Identify_your_nic | carte identifiées]], il ne vous reste plus qu'à définir leur nom et pour cela je vous conseil d'utiliser leur rôle:
* une carte connectée à une DMZ → dmz
* une carte connectée à un LAN → lan
* une carte connectée à une box → wan

Si vous avez plusieurs cartes par rôle, utilisez des numéros: ''dmz0'', ''dmz1'', ...

Pour fixer le nom on va suivre [[Ifcfg-ethX#Que_faire_si_ma_carte_n'a_pas_le_bon_numéro_?? | le tutoriel sur udev]] et d'abord identifier l'adresse MAC de notre carte:
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 24:12:4d:01:49:20 brd ff:ff:ff:ff:ff:ff
3: enp0s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 24:12:4d:01:49:21 brd ff:ff:ff:ff:ff:ff
altname enp3s0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:8a:07:f7:ce:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.4.240/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fef7:ce9b/64 scope link
valid_lft forever preferred_lft forever
</source>

On a donc:
* enp0s0f1 en management avec l'adresse 24:12:4d:01:49:21
* enp0s0f1 connecté à une DMZ avec l'adresse 24:12:4d:01:49:20

Il ne nous reste plus qu'a créez le fichier ''/etc/udev/rules.d/70-persistent-net.rules'' avec le contenu suivant:
<source lang=bash>
# Carte Intel SFP+ management
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="mgmt"

# Carte Intel SFP+ DMZ
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
</source>

Si vous êtes à distance, n'oubliez pas de modifier votre fichier ''/etc/network/interfaces'' avant de redémarrer:
<source lang=bash>
...
iface mgmt inet manual
iface dmz inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.1/24
gateway 192.168.1.254
bridge-ports mgmt
bridge-stp off
bridge-fd 0

...
</source>

= Personnalisation de l'environnement =

Comme Proxmox est fait sur une base de Debian, certaine commandes disponible sur Rocky risque de vous manquer !

J'aime bien faire un tour dans le fichier ''/root/.bashrc'' pour y ajouter à la fin les lignes suivantes:
<source lang=bash>
alias ll='ls -l'
alias vi=vim.tiny
</source>

Une fois vos modifications terminées, il ne vous reste plus qu'a recharger le fichier ''.bashrc'':
<source lang=bash>
#. .bashrc
</source>

Proxmox fail2ban

2026-07-11T15:02:04Z

Jc.forton : /* Jail pour PVEPROXY */

The Linux Craftsman

2026-07-07T12:25:31Z

Jc.forton : /* La pratique */

= Ce wiki =
<div align="center">
{|class="wikitable" width="100%"
! Le contenu !! Public visé !! L'auteur
|-valign=top
|width="33%"|
Ce wiki propose des articles, cours, TPs et TDs sur des sujets gravitant autour des technologies du système d'information, notamment sur le système Linux, sur la distribution CentOS et maintenant Rocky Linux.

Vous y trouverez des articles traitant de la mise en place de services réseaux tels que DHCP et DNS mais également des articles sur la mise en place de pare-feu, site Web, etc... Il y a un peu de tout et je vous encourage à utiliser le champ de recherche pour trouver ce dont vous avez besoin.
|width="33%"|

Ce wiki s'adresse principalement à mes élèves mais il peut également servir à des enseignants qui désirent monter leurs cours sans se "prendre la tête".

Tout est disponible sous [http://www.gnu.org/copyleft/fdl.html licence GNU Free Documentation License 1.3] ou ultérieure et vous pouvez récupérer les contenus et en faire ce que vous voulez !
|width="33%"|

Je m'appelle Jean-Christophe FORTON et je suis professeur d'informatique depuis 2011 mais cela n'a pas toujours été mon métier, plus d'info [[jcf|ici]]...

N'hésitez pas à faire un tour sur :
{|
|-valign=middle
|align=center|
[[Image:Logo-YouTube-rouge.png|30px|link=https://www.youtube.com/@tala-informatique]]
|| ma chaîne Youtube pour découvrir mes aventures ou (re)visionner certains cours
|-valign=middle
|align=center|
[[Fichier:Logo-Tipeee.png|27px|link=https://fr.tipeee.com/tala-informatique]]
||mon Tipeee pour me remercier
|}
|}
</div>

= Les cours =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Général
|-valign=top
|width="20%"|
<hr>
<div align="center">Architecture des ordinateurs</div>
<hr>
[[:Media:materiel.pdf|Le matériel]]
<br>
[[:Media:system_exploitation.pdf|Le système d'exploitation]]
<br>
[[:Media:gestion_disques.pdf|La gestion des disques]]
<br>
[[:Media:sauvegarde.pdf|La sauvegarde]]
<hr>
<div align="center">Linux</div>
<hr>
[[:Media:intro_linux.pdf|Introduction au système Linux]]
<br>
[[:Media:tp_linux_commandes_de_bases.pdf|TP Linux : commandes de bases]]
<hr>
<div align="center">Active Directory</div>
<hr>
[[:Media:ad_intro.pdf|Les principes fondamentaux]]
<br>
[[:Media:ad_gpo.pdf|Gestion des stratégies]]
|width="20%"|
<hr>
<div align="center">Réseaux</div>
<hr>
[[:Media:Les pare-feux.pdf|Les pare-feux]]
<br>
[[:Media:Les pare-feux_tech.pdf|Les pare-feux (fiche technique)]]
<br>
[[:Media:Les VPN.pdf|Les VPN]]
<br>
[[:Media:Haute_dispo.pdf|Haute disponibilité]]
<br>
[[:Media:sauvegarde_pca.pdf|La sauvegarde]]
<hr>
<div align="center">Sécurité des Systèmes d’Information</div>
<hr>
[[:Media:principes_SSI.pdf|Les principes fondamentaux]]
<br>
[[:Media:implémentation_concrete_SSI.pdf|Implémentation concrète de la sécurité]]
<br>
[[:Media:cryptographie.pdf|Cryptographie]]
<br>
[[:Media:TD1_SSI.pdf|TD1: Principes Fondamentaux]]
<br>
[[:Media:TP1_SSI.pdf|TP1: Écoute d'une connexion]]
<br>
[[:Media:TP2_SSI.pdf|TP2: Chiffrement asymétrique avec PGP]]
<hr>
<div align="center">Web</div>
<hr>
[[:Media:apache server.pdf|Le serveur Apache]]
<br>
[[:Media:pilotage web bdd.pdf|Pilotage d'une page web]]
<br>
[[:Media:web app security.pdf|Sécurité des applications Web]]
|width="20%"|
<hr>
<div align="center">Modèle OSI</div>
<hr>
*[[:Media:OSI.pdf|Le modèle OSI en version cours]]
*[[:Media:OSI_Slides.pdf|Le modèle OSI en version slides]]
<hr>
<div align="center">OSI 1 </div>
<hr>
[[:Media:Normes_cablages.pdf|Les normes de câblage]]
<hr>
<div align="center">OSI 2</div>
<hr>
[[:Media:Ethernet-802.3.pdf|La norme Ethernet (802.3)]]
<br>
[[:Media:WiFi-802.11.pdf|La norme Wi-Fi (802.11)]]
<br>
[[:Media:Bridge.pdf|Les bridges]]
<br>
[[:Media:STP.pdf|Spanning Tree Protocol]]
<br>
[[:Media:VLAN.pdf|Les Vlans]]
<hr>
<div align="center">Routage</div>
<hr>
[[:Media:CIDR.pdf|Classless Inter-Domain Routing]]
<br>
[[:Media:resume_protocoles_vecteur_distance.pdf|Résumé sur les protocoles à vecteur de distance]]
<br>
[[:Media:EIGRP.pdf|Enhanced Interior Gateway Routing Protocol]]
<br>
[[:Media:OSPF.pdf|Open Shortest Path First]]
<br>
[[:Media:BGP.pdf|Border Gateway Protocol]]
<hr>
<div align="center">Services</div>
<hr>
[[:Media:DHCP.pdf|DHCP]]
<br>
[[:Media:DNS.pdf|DNS]]
<br>
[[:Media:SAMBA.pdf|Samba]]
<hr>
<div align="center">Qualité de service</div>
<hr>
[[:Media:QoS.pdf|La QoS]]
<br>
[[:Media:Iproute2_QoS.pdf|Iproute2 et la QoS]]
<hr>
<div align="center">Protocole</div>
<hr>
[[:Media:HTTP.pdf|HTTP]]
<br>
[[:Media:SNMP.pdf|SNMP]]
|width="20%"|
<hr>
<div align="center">L'algorithmique</div>
<hr>
[[:Media:algo_intro.pdf|Introduction]]
<br>
[[:Media:algo_langage.pdf|Le Langage]]
<hr>
<div align="center">SQL</div>
<hr>
[[:Media:conception_bdd.pdf|Conception de base de données]]
<br>
[[:Media:conception_bdd_simple.pdf|Conception de base de données (simplifié)]]
<br>
[[:Media:langage_de_requête.pdf|Langage de requête]]
<hr>
<div align="center">Langages du Web</div>
<hr>
[[:Media:HTML xHTML intro.pdf|Le langage HTML]]
<br>
[[:Media:css.pdf|Le langage CSS]]
<br>
[[:Media:javascript.pdf|Le langage JavaScript]]
<br>
[[:Media:php.pdf|Le langage PHP]]
<hr>
<div align="center">Langage bas niveau</div>
<hr>
[[:Media:C lang.pdf|Le langage C]]
<hr>
<div align="center">Architecture SOA</div>
<hr>
[[:Media:webservices.pdf|Les Web Services RESTful]]
<hr>
<div align="center">Informatique embarquée</div>
<hr>
[[:Media:arduino_avr.pdf|Arduino et AVR]]
<br>
[[:Media:IOT.pdf|L'Internet des objets]]
|width="20%"|
<hr>
<div align="center">Gestion</div>
<hr>
[[:Media:gestion_projet.pdf|Gestion de projet]]
<hr>
<div align="center">Bureautique</div>
<hr>
[[:Media:powerpoint.pdf|PowerPoint]]
<br>
[[:Media:excel.pdf|Excel]]
<br>
[[:Media:bdd_com.pdf|Les bases de données]]
<hr>
<div align="center">Histoire / évolutions</div>
<hr>
[[:Media:expertise_codage.pdf|Expertise codage]]
|}
</div>

= La pratique =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Embarquée !! Virtualisation
|-valign="top"
|align=left width="17%"|
<hr>
<div align="center">Installation / Migration</div>
<hr>
[[bootable_usb_ventoy| Clé bootable Ventoy]]
<br>
[[Installation de CentOS| CentOS]]
<br>
[[Installation de Rocky| Rocky]]
<br>
[[migration_centos8torocky8| CentOS 8 → Rocky 8]]
<br>
[[upgrade_rocky8to9| Rocky 8 → 9]]
<br>
[[WSL | WSL : Linux sur Windows 10]]
<hr>
<div align="center">Les basiques</div>
<hr>
[[Vi / Vim]]
<br>
[[linux_repository|Les dépots (EPEL, EL, ...)]]
<br>
[[cron| Gestionnaire des tâches: cron]]
<br>
[[rpm_yum| Gestionnaires de paquetages: RPM & YUM]]
<br>
[[Les logs]]
<br>
[[users_groups|Utilisateurs et groupes]]
<br>
[[Gestion des disques]]
<hr>
<div align="center">SysVInit<br>CentOS ≤ 6</div>
<hr>
[[Gestionnaire de démarrage|Gestionnaire de démarrage]]
<br>
[[start_stop_daemon|Création d'un service]]
<br>
[[ntpd| L'heure avec NTP]]
<hr>
<div align="center">SystemD<br>CentOS ≥ 7 / Rocky</div>
<hr>
[[systemctl|Systemctl]]
<br>
[[systemctl service|Création d'un service]]
<br>
[[chrony|L'heure avec Chrony]]
<hr>
<div align="center">Réseaux</div>
<hr>
[[identify_your_nic | Identifier ses cartes]]
<br>
[[ifcfg-ethX|Les interfaces réseaux]]
<br>
[[sysconfig-network|Les paramètres réseaux]]
<br>
[[resolv.conf|Configuration du client DNS]]
<hr>
<div align="center">Haute disponibilité</div>
<hr>
[[drbd|Réplication à chaud avec DRBD]]
<hr>
<div align="center">Multimédia</div>
<hr>
[[DLNA|Partage de contenu cross-platform avec DLNA]]
|width="17%"|
<hr>
<div align="center">Réseaux</div>
<hr>
<br>
[[Iptables]]
<br>
[[Squid]]
<br>
[[:Media:Chillispot.pdf|Hotspot avec Chillispot]]
<br>
[[Sécuriser un service avec Fail2ban]]
<hr>
<div align="center">VPN</div>
<hr>
[[Openvpn]]
<br>
[[Wireguard]]
<hr>
<div align="center">Système</div>
<hr>
[[SSH]]
<br>
[[SELinux]]
|align=left width="16%"|
<hr>
<div align="center">Les commandes</div>
<hr>
[[tcpdump | tcpdump]]
<br>
[[iproute2 | ip]]
<hr>
<div align="center">OSI 2</div>
<hr>
[[source routing|Le routage source]]
<br>
[[bridge|Les bridges]]
<br>
[[alias|Les alias]]
<br>
[[vlan|Les vlans]]
<br>
[[one-arm_router|La passerelle ''one-arm'']]
<br>
[[transparent_firewall|Le proxy ''transparent'']]
<hr>
<div align="center">OSI 3+</div>
<hr>
[[DHCP]]
<br>
[[DNS]]
<hr>
<div align="center">Apache httpd</div>
<hr>
[[httpd_install_start| Installation et premier démarrage ]]
<br>
[[httpd_vhost| Déploiement d'un hôte virtuel]]
<br>
[[httpd_htaccess | Le fichier .htaccess ]]
<br>
[[httpd_redirect_reverse-proxy_mod-rewrite| Redirections, réécriture d’URL (mod_rewrite)]]
<br>
[[httpd_certificate_security | Certificats et sécurité ]]
<hr>
<div align="center">Haute-disponibilité</div>
<hr>
[[Ucarp]]
<hr>
<div align="center">Services divers</div>
<hr>
[[SAMBA]]
<br>
[[xmpp | Serveur XMPP avec Ejabberd]]
<br>
[[vnc|Installer un serveur VNC]]
<hr>
<div align="center">Industrialisation</div>
<hr>
[[:Media:pxe.pdf|Monter un serveur PXE (pdf)]]
<br>
[[PXE|Monter un serveur PXE]]
<hr>
<div align="center">Supervision</div>
<hr>
[[Nagios| Nagios]]
<br>
[[Cacti| Installer un serveur Cacti]]
<br>
[[SNMP | Utiliser SNMP]]
<hr>
<div align="center">Cisco ISR (routeur)</div>
<hr>
[[ISR-basics|Les bases]]
|align=left width="17%"|
<hr>
<div align="center">Général</div>
<hr>
[[eclipse_install|Mise en place de l'environnement de développement]]
<br>
[[svn|Serveur de version SVN]]
<hr>
<div align="center">PHP, les basiques</div>
<hr>
[[php_httpd_install | Installation sous Linux]]
<br>
[[php_devel| Premier projet en ''PHP'']]
<br>
[[php_algo|Un peu d'algorithmique]]
<br>
[[php_object| Les objets]]
<br>
[[php_xdebug| Debugger avec ''Xdebug'']]
<hr>
<div align="center">PHP CLI</div>
<hr>
[[php_memcached| Memcached un serveur de cache]]
<br>
[[php_daemon | Écriture d'un démon]]
<br>
[[php_socket | Utilisation des sockets]]
<hr>
<div align="center">PHP CGI</div>
<hr>
[[php_$get_$post_$session| Passer des informations entres pages]]
<br>
[[php_pdo| Utiliser une base MySQL avec PDO]]
<br>
[[php_slim | Le framework SLIM]]
<hr>
<div align="center">JS, les basiques</div>
<hr>
[[js_devel| Premier projet en ''JavaScript'']]
<br>
[[js_algo| Un peu d'algorithmique]]
<br>
[[js_object| Les objets]]
<hr>
<div align="center">JS, les RIA (''R''ich ''I''nternet ''A''pplication)</div>
<hr>
[[js_AJAX| Client AJAX pour utiliser des Web Services]]
<br>
[[js_AJAX_auth | Authentification avec un client AJAX]]
<br>
[[js_AJAX_fetch_api | Découverte de l'API ''fetch'']]
<hr>
<div align="center">C, les basiques</div>
<hr>
[[c_devel| Premier projet en ''C'']]
<br>
[[c_devel_cross| Compilation croisée (Cross Compilation)]]
<br>
[[c_algo| Un peu d'algorithmique]]
<hr>
<div align="center">C, parallélisation</div>
<hr>
[[c_pthread| Les threads]]
<br>
[[c_fork| Les forks]]
<hr>
<div align="center">C, IPC</div>
<hr>
[[c_pipe| Les tubes]]
<br>
[[c_semaphore| Les sémaphores]]
<br>
[[c_signals| Les signaux POSIX]]
<br>
[[c_socket| Les sockets]]
<hr>
<div align="center">C, GP-GPU avec CUDA</div>
<hr>
[[cuda_install| Installation de CUDA]]
<br>
[[cuda_hello_world| Les concepts et bases]]
<hr>
<div align="center">Java, les basiques</div>
<hr>
[[java_devel| Premier projet en ''Java'']]
<br>
[[java_jar|Mon premier objet]]
<br>
[[java_algo| Un peu d'algorithmique]]
<hr>
<div align="center">Java, le web</div>
<hr>
[[java_servlet|Les Servlets]]
<br>
[[java_ws_restful| Web Service Restful]]
<hr>
<div align="center">Java, le stockage</div>
<hr>
[[java_mysql| Utiliser une base MySQL avec Java]]
<br>
[[java_memcached| Memcached un serveur de cache]]
<hr>
<div align="center">SQL</div>
<hr>
[[sql_install| Installation d'un SGBDR]]
<br>
[[SQL_import| Importation d'une base de données]]
<hr>
<div align="center">Python</div>
<hr>
[[python_devel| Premier projet en ''Python'']]
<br>
[[python_algo|Un peu d'algorithmique]]
|align=left width="16%"|
<hr>
<div align="center">Programmation</div>
<hr>
[[Arduino_Eclipse_sketch | Création d'un projet sous Eclipse]]
<br>
[[Arduino_sketch_writing | Écriture d'un sketch]]
<br>
[[atmega328_registers | Manipulation de registres ]]
<br>
[[atmega328_timers | Les timers ]]
<hr>
<div align="center">Ports série</div>
<hr>
[[Arduino_CH340_driver_install | Installation du pilote CH340 (Serial TTL)]]
<br>
[[Arduino_FTDI_driver_install | Installation du pilote FTDI(Serial TTL)]]
<br>
[[Arduino_CP210X_driver_install | Installation du pilote CP210X(Serial TTL)]]
<hr>
<div align="center">Les cartes</div>
<hr>
[[arduino_diagram | Schémas des cartes Arduino]]
<br>
[[esp8266_diagram | Schémas des cartes ESP8266]]
<br>
[[esp32_diagram | Schémas des cartes ESP32]]
<br>
[[sbc_diagram | Schémas des SBC]]
<br>
[[µc_datasheet | Fiches techniques des microcontrôleurs]]
<hr>
<div align="center">Capteurs</div>
<hr>
[[Arduino_LDR | Luminosité avec une photorésistance]]
<br>
[[Arduino_BH1750 | Luminosité avec le BH1750]]
<br>
[[Arduino_DS18B20 | Température avec le DS18B20]]
<br>
[[Arduino_LM35DZ | Température avec le LM35]]
<br>
[[Arduino_DHT11 | Température et humidité avec le DHT11]]
<br>
[[Arduino_BMP280 | Température, pression et altitude avec le BMP280]]
<br>
[[Arduino_A3144 | Effet de Hall (magnétisme) avec le A3144 ]]
<br>
[[Arduino_SR501 | Détection de mouvement avec le SR501 (PIR) ]]
<br>
[[Arduino_soil_moisture | Capteur d'humidité du sol ]]
<hr>
<div align="center">Communication sans-fil</div>
<hr>
[[Arduino_HC12 | Communication RF433 avec un HC12]]
<br>
[[Arduino_NRF24L01 | Communication 2.4Ghz avec un NRF24L01]]
<br>
[[Arduino_ESP05 | Communication Wi-Fi avec un ESP-05]]
<hr>
<div align="center">Shield Ethernet (W5100)</div>
<hr>
[[Arduino_W5100_intro | Présentation du shield]]
<br>
[[Arduino_W5100_OSI3 | Configuration OSI 3]]
<br>
[[Arduino_W5100_web_server | Utilisation du Shield Ethernet pour faire un serveur Web]]
<hr>
<div align="center">Composants et montages divers</div>
<hr>
[[ potentiometre | Potentiomètre ]]
<br>
[[ shift_register | Registre à décalage ]]
<br>
[[ Arduino_2axis_joystick_button | Joystick 2 axes avec bouton ]]
<br>
[[ Arduino_SD_CARD | Module pour cartes SD ]]
<hr>
<div align="center">ESP8266 / ESP32</div>
<hr>
[[esp_ide_arduino | Cartes ESP et IDE Arduino]]
<br>
[[esp8266_wifi | Utilisation du WiFi ]]
<br>
[[esp8266_webserver | Utilisation du serveur web ]]
<br>
[[esp8266_udp_server | Serveur UDP ]]
<br>
[[esp8266_ntp_client | Client NTP ]]
<br>
[[:Media:esp8266_tp_meteo_dht11.pdf | TP station météo avec le DHT11 ]]
<hr>
<div align="center">Raspberry / Banana / Orange Pi</div>
<hr>
[[iso_install_sdcard | Installation d'une image ]]
<br>
[[pi_java_install | Mise en place de Java ]]
<br>
[[sbc_qemu_emulation | Émulation avec Qemu ]]
<br>
[[Linux sunxi armbian gpio | Manipulation des GPIO sous Linux]]
<br>
[[Linux sunxi armbian w1 | Utilisation du protocole OneWire sous Linux]]
<br>
[[Linux uart sunxi armbian | Utilisation du protocole UART sous Linux]]
|align=left width="16%"|
<hr>
<div align="center">VmWare</div>
<hr>
[[vmware_install | Installation ]]
<br>
[[vmware_network | La partie réseau ]]
<br>
[[vmware_create_vm | Création d'une machine virtuelle ]]
<br>
[[vmware_debug_vm | Débogage réseau d'une machine virtuelle]]
<hr>
<div align="center">Proxmox</div>
<hr>
[[proxmox_install | Installation ]]
<br>
[[proxmox_first_start | Premier démarrage ]]
<br>
[[proxmox_nic_name | Les interfaces réseaux ]]
<br>
[[proxmox_iptables | Utilisation d'iptables ]]
<br>
[[proxmox_fail2ban | Fail2ban ]]
|}
</div>
<div style="visibility:hidden">
__TOC__
</div>
__NOTOC__

[[index_detailed | ]]

Fichier:Intel sfp+ nic4.jpg

2026-07-01T10:32:22Z

Jc.forton : Jc.forton a téléversé une nouvelle version de Fichier:Intel sfp+ nic4.jpg

Identify your nic

2026-07-01T10:30:15Z

Jc.forton : /* Contrôle par l'état du lien */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande ''lspci'':
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''.

Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom et notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux et pour ça nous allons utiliser l'état des liens pour déterminer le numéro de chaque port.

{|align=center
|-
|valign=top|
[[Fichier:intel sfp+ nic.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:intel sfp+ nic4.jpg|350px|centré]]
|}

Commencez par déconnecter chaque prises sauf une pour que toutes les ports soient dans un état bas ou ''down'' sauf un qui sera ''up'':
<source lang=bash>
# ip a
...
3: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 24:8a:07:f7:bd:20 brd ff:ff:ff:ff:ff:ff
4: enp1s0f1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:21 brd ff:ff:ff:ff:ff:ff
...
</source>

Vous savez que le port connecté possède la fonction 1 (''enp1s0f1'') et celui débranché à la fonction 0 (''enp1s0f0'')

Fichier:Intel sfp+ nic4.jpg

2026-07-01T10:30:08Z

Jc.forton :

Fichier:Intel sfp+ nic.jpg

2026-07-01T10:28:36Z

Jc.forton :

Identify your nic

2026-07-01T10:27:42Z

Jc.forton : /* Contrôle par l'état du lien */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande ''lspci'':
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''.

Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom et notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux et pour ça nous allons utiliser l'état des liens pour déterminer le numéro de chaque port.

[[Fichier:intel sfp+ nic.jpg|350px|centré]]

Commencez par déconnecter chaque prises sauf une pour que toutes les ports soient dans un état bas ou ''down'' sauf un qui sera ''up'':
<source lang=bash>
# ip a
...
3: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 24:8a:07:f7:bd:20 brd ff:ff:ff:ff:ff:ff
4: enp1s0f1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:21 brd ff:ff:ff:ff:ff:ff
...
</source>

Vous savez que le port connecté possède la fonction 1 (''enp1s0f1'') et celui débranché à la fonction 0 (''enp1s0f0'')

Proxmox fail2ban

2026-06-30T15:58:54Z

Jc.forton : /* Introduction */

Proxmox iptables

2026-06-30T15:51:07Z

Jc.forton : /* Persistance */

= Introduction =

Vous n'êtes pas sans savoir qu'iptables est une commande permettant configurer [https://fr.wikipedia.org/wiki/Netfilter ''netfilter''] la partie du noyau chargé du filtrage réseau. Iptables est installé de base sur Proxmox mais, comme Proxmox hérite de Debian, aucune configuration n'est faite et aucun moyen de charger la configuration n'est présent...

Si jamais vous voulez plus d'information à ce sujet, je vous invite à lire le cours sur les [[:Media:Les pare-feux.pdf|pare-feux]] ou les différents articles traitant du sujet !

Avant d'aller plus loin, veuillez configurer des noms explicite sur vos [[Proxmox_first_start#Nommage_des_cartes_réseaux | interfaces réseaux]], dans cet article, l'interface que nous allons sécuriser est l'interface de management.

= État des lieux =

Vous pouvez voir la configuration en tapant la commande suivante:
<source lang=bash>
# iptables -nvL
Chain INPUT (policy ACCEPT 8969 packets, 2422K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2885 packets, 1041K bytes)
pkts bytes target prot opt in out source destination
</source>

Vous pouvez constater que les polices sont sur ''ACCEPT'' et qu'aucune règle n'est présente dans la chaîne ''INPUT''. C'est ce que les experts appellent une configuration en mode '''passoire''' 😂

= Application des règles =

Nous allons paramétrer quelques règles de bases sur l'interface ''vmbr0'' qui nous sert de management, les mêmes qui sont présentes sur une machine Rocky à l'installation d'iptables, à savoir :
* on autorise tout ce qui fait parti d'une session déjà démarrée
* on autorise tout le trafique sur l'interface de loopback
* on autorise les messages ICMP (ping)
* on autorise le SSH (TCP/22)
* on ''drop'' tout le reste du trafique entrant
* on ''drop'' tout le trafique traversant

Et on oublie pas d'ajouter aussi le port de PveProxy (l'interface web) qui est le TCP/8006, ce qui nous donne:
<source lang=bash>
iptables -A INPUT -i vmbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i vmbr0 -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 8006 -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
</source>

Si vous n'utilisez pas d'IPv6, autant tout bloquer:
<source lang=bash>
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP
</source>

= Persistance =

Maintenant que nous avons toutes nos règles, ils faut les faire persister au redémarrage du serveur et pour cela nous allons utiliser le paquetage ''iptables-persistent'':
<source lang=bash>
apt -y install iptables-persistent
</source>
Il vous propose de sauvegarder les règles IPv4 et IPv6 mais pour ceux qui auraient raté le message, vous pouvez toujours faire:
{|align=center
|-
|align=left|
Pour IPv4
|width=10px|
|align=left|
Pour IPv6
|-
|valign=top|
<source lang=bash>
iptables-save > /etc/iptables/rules.v4
</source>
|width=10px|
|valign=top|
<source lang=bash>
ip6tables-save > /etc/iptables/rules.v6
</source>
|}

On n'oubliera pas d'enregistrer le service au démarrage de la machine:
<source lang=bash>
systemctl enable netfilter-persistent
</source>

= Les autres interfaces =

Si vous avez plusieurs cartes pour connecter vos conteneurs ou VM, vous ne devez avoir normalement qu'une seule interface d'administration. Cela veut dire que sur les autres interfaces il n'y a pas de configuration IP, donc pas de trafique qui circule.

Je vous invite à installer un pare-feu sur chaque conteneurs et VM pour plus de sécurité...

Proxmox iptables

2026-06-30T15:39:32Z

Jc.forton : /* Persistance */

Proxmox iptables

2026-06-30T15:37:05Z

Jc.forton : /* Application des règles */

Proxmox iptables

2026-06-30T15:35:50Z

Jc.forton : /* Application des règles */

= Introduction =

Vous n'êtes pas sans savoir qu'iptables est une commande permettant configurer [https://fr.wikipedia.org/wiki/Netfilter ''netfilter''] la partie du noyau chargé du filtrage réseau. Iptables est installé de base sur Proxmox mais, comme Proxmox hérite de Debian, aucune configuration n'est faite et aucun moyen de charger la configuration n'est présent...

Si jamais vous voulez plus d'information à ce sujet, je vous invite à lire le cours sur les [[:Media:Les pare-feux.pdf|pare-feux]] ou les différents articles traitant du sujet !

Avant d'aller plus loin, veuillez configurer des noms explicite sur vos [[Proxmox_first_start#Nommage_des_cartes_réseaux | interfaces réseaux]], dans cet article, l'interface que nous allons sécuriser est l'interface de management.

= État des lieux =

Vous pouvez voir la configuration en tapant la commande suivante:
<source lang=bash>
# iptables -nvL
Chain INPUT (policy ACCEPT 8969 packets, 2422K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2885 packets, 1041K bytes)
pkts bytes target prot opt in out source destination
</source>

Vous pouvez constater que les polices sont sur ''ACCEPT'' et qu'aucune règle n'est présente dans la chaîne ''INPUT''. C'est ce que les experts appellent une configuration en mode '''passoire''' 😂

= Application des règles =

Nous allons paramétrer quelques règles de bases sur l'interface ''vmbr0'' qui nous sert de management, les mêmes qui sont présentes sur une machine Rocky à l'installation d'iptables, à savoir :
* on autorise tout ce qui fait parti d'une session déjà démarrée
* on autorise tout le trafique sur l'interface de loopback
* on autorise les messages ICMP (ping)
* on autorise le SSH (TCP/22)
* on ''drop'' tout le reste du trafique entrant
* on ''drop'' tout le trafique traversant

Et on oublie pas d'ajouter aussi le port de PveProxy (l'interface web) qui est le TCP/8006, ce qui nous donne:
<source lang=bash>
iptables -A INPUT -i vmbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i vmbr0 -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 8006 -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
</source>

Si vous n'utilisez pas d'IPv6, autant tout bloquer:
<source lang=bash>
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP
</source>

= Persistance =

Maintenant que nous avons toutes nos règles, ils faut les faire persister au redémarrage du serveur et pour cela nous allons utiliser le paquetage ''iptables-persistent'':
<source lang=bash>
apt -y install iptables-persistent
</source>
Il vous propose de sauvegarder les règles IPv4 et IPv6 mais pour ceux qui auraient raté le message, vous pouvez toujours faire:
{|align=center
|-
|align=left|
Pour IPv4
|width=10px|
|align=left|
Pour IPv6
|-
|valign=top|
<source lang=bash>
iptables-save > /etc/iptables/rules.v4
</source>
|width=10px|
|valign=top|
<source lang=bash>
ip6tables-save > /etc/iptables/rules.v6
</source>
|}

Proxmox iptables

2026-06-30T15:08:48Z

Jc.forton : /* Persistance */

= Introduction =

Vous n'êtes pas sans savoir qu'iptables est une commande permettant configurer [https://fr.wikipedia.org/wiki/Netfilter ''netfilter''] la partie du noyau chargé du filtrage réseau. Iptables est installé de base sur Proxmox mais, comme Proxmox hérite de Debian, aucune configuration n'est faite et aucun moyen de charger la configuration n'est présent...

Si jamais vous voulez plus d'information à ce sujet, je vous invite à lire le cours sur les [[:Media:Les pare-feux.pdf|pare-feux]] ou les différents articles traitant du sujet !

Avant d'aller plus loin, veuillez configurer des noms explicite sur vos [[Proxmox_first_start#Nommage_des_cartes_réseaux | interfaces réseaux]], dans cet article, l'interface que nous allons sécuriser est l'interface de management.

= État des lieux =

Vous pouvez voir la configuration en tapant la commande suivante:
<source lang=bash>
# iptables -nvL
Chain INPUT (policy ACCEPT 8969 packets, 2422K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2885 packets, 1041K bytes)
pkts bytes target prot opt in out source destination
</source>

Vous pouvez constater que les polices sont sur ''ACCEPT'' et qu'aucune règle n'est présente dans la chaîne ''INPUT''. C'est ce que les experts appellent une configuration en mode '''passoire''' 😂

= Application des règles =

Nous allons paramétrer quelques règles de bases sur l'interface ''vmbr0'' qui nous sert de management, les mêmes qui sont présentes sur une machine Rocky à l'installation d'iptables, à savoir :
* on autorise tout ce qui fait parti d'une session déjà démarrée
* on autorise tout le trafique sur l'interface de loopback
* on autorise les messages ICMP (ping)
* on autorise le SSH (TCP/22)
* on ''drop'' tout le reste

Et on oublie pas d'ajouter aussi le port de PveProxy (l'interface web) qui est le TCP/8006, ce qui nous donne:
<source lang=bash>
iptables -A INPUT -i vmbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i vmbr0 -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 8006 -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
</source>

Si vous n'utilisez pas d'IPv6, autant tout bloquer:
<source lang=bash>
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP
</source>

= Persistance =

Maintenant que nous avons toutes nos règles, ils faut les faire persister au redémarrage du serveur et pour cela nous allons utiliser le paquetage ''iptables-persistent'':
<source lang=bash>
apt -y install iptables-persistent
</source>
Il vous propose de sauvegarder les règles IPv4 et IPv6 mais pour ceux qui auraient raté le message, vous pouvez toujours faire:
{|align=center
|-
|align=left|
Pour IPv4
|width=10px|
|align=left|
Pour IPv6
|-
|valign=top|
<source lang=bash>
iptables-save > /etc/iptables/rules.v4
</source>
|width=10px|
|valign=top|
<source lang=bash>
ip6tables-save > /etc/iptables/rules.v6
</source>
|}

Proxmox iptables

2026-06-30T15:07:17Z

Jc.forton : /* Application des règles */

= Introduction =

Vous n'êtes pas sans savoir qu'iptables est une commande permettant configurer [https://fr.wikipedia.org/wiki/Netfilter ''netfilter''] la partie du noyau chargé du filtrage réseau. Iptables est installé de base sur Proxmox mais, comme Proxmox hérite de Debian, aucune configuration n'est faite et aucun moyen de charger la configuration n'est présent...

Si jamais vous voulez plus d'information à ce sujet, je vous invite à lire le cours sur les [[:Media:Les pare-feux.pdf|pare-feux]] ou les différents articles traitant du sujet !

Avant d'aller plus loin, veuillez configurer des noms explicite sur vos [[Proxmox_first_start#Nommage_des_cartes_réseaux | interfaces réseaux]], dans cet article, l'interface que nous allons sécuriser est l'interface de management.

= État des lieux =

Vous pouvez voir la configuration en tapant la commande suivante:
<source lang=bash>
# iptables -nvL
Chain INPUT (policy ACCEPT 8969 packets, 2422K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2885 packets, 1041K bytes)
pkts bytes target prot opt in out source destination
</source>

Vous pouvez constater que les polices sont sur ''ACCEPT'' et qu'aucune règle n'est présente dans la chaîne ''INPUT''. C'est ce que les experts appellent une configuration en mode '''passoire''' 😂

= Application des règles =

Nous allons paramétrer quelques règles de bases sur l'interface ''vmbr0'' qui nous sert de management, les mêmes qui sont présentes sur une machine Rocky à l'installation d'iptables, à savoir :
* on autorise tout ce qui fait parti d'une session déjà démarrée
* on autorise tout le trafique sur l'interface de loopback
* on autorise les messages ICMP (ping)
* on autorise le SSH (TCP/22)
* on ''drop'' tout le reste

Et on oublie pas d'ajouter aussi le port de PveProxy (l'interface web) qui est le TCP/8006, ce qui nous donne:
<source lang=bash>
iptables -A INPUT -i vmbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i vmbr0 -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 8006 -j ACCEPT
iptables -A INPUT -i vmbr0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
</source>

Si vous n'utilisez pas d'IPv6, autant tout bloquer:
<source lang=bash>
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP
</source>

= Persistance =

Maintenant que nous avons toutes nos règles, ils faut les faire persister au redémarrage du serveur et pour cela nous allons utiliser le paquetage ''iptables-persistent'':
<source lang=bash>
apt -y install iptables-persistent
</source>
Il vous propose de sauvegarder les règles IPv4 et IPv6 mais pour ceux qui auraient raté le message, vous pouvez toujours faire:

Proxmox iptables

2026-06-30T15:03:06Z

Jc.forton : /* Application des règles */

Proxmox iptables

2026-06-30T15:01:14Z

Jc.forton : /* Application des règles */

Proxmox iptables

2026-06-30T14:56:20Z

Jc.forton : Page créée avec « = Introduction = Vous n'êtes pas sans savoir qu'iptables est une commande permettant configurer [https://fr.wikipedia.org/wiki/Netfilter ''netfilter''] la partie du noyau chargé du filtrage réseau. Iptables est installé de base sur Proxmox mais, comme Proxmox hérite de Debian, aucune configuration n'est faite et aucun moyen de charger la configuration n'est présent... Si jamais vous voulez plus d'information à ce sujet, je vous invite à lire le cours su... »

Proxmox first start

2026-06-30T14:28:36Z

Jc.forton : /* Nommage des cartes réseaux */

= Introduction =

Maintenant que votre serveur Proxmox est installé, nous allons effectuer quelques opérations de configuration de bases comme :
* la modification des dépôts
* la mise à jour
* la suppression du message d'abonnement
* le nommage des cartes réseaux
* la personnalisation de l'environnement

= Modification des dépôts =
De base l'équipe de Proxmox vous incite à prendre un abonnement pour profiter des mise à jours et fonctionnalités nécessaires dans un datacenter.

[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Si comme moi, vous utilisez Proxmox dans le cadre d'un homelab, pas besoin de payer, la version ''basic'' est largement suffisante.
{|align=center
|-
|align=left|
Cliquez sur l'icône de votre serveur dans la barre à gauche
|width=10px|
|align=left|
Puis sur ''repositories''
|-
|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories menu.jpg|150px|centré]]
|}

On va dans un premier temps retirez les dépôts ''entreprise'' de Proxmox. Dès que vous voyez ''entreprise'' ou ''pve-entreprise'' dans la colonne ''Components'', il y a de grande chance que le dépôt nécessite un abonnement.

[[Fichier:proxmox repository remove.jpg|900px|centré]]

* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''
* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''

Une grosse croix rouge qui fait peur apparaît

[[Fichier:proxmox repository red corss.jpg|600px|centré]]

Pas de panique, nous allons ajouter le dépôt gratuit pour avoir quand même quelques mise à jours.

{|align=center
|-
|align=left|
Cliquez sur ''add''
|width=10px|
|align=left|
Puis sur ''No-Subscription''
|-
|valign=top|
[[Fichier:proxmox repository add.jpg|250px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories no-subscription.jpg|500px|centré]]
|}

Ouf, la méchante croix rouge à disparue :)

[[Fichier:proxmox repositories no-subscription warning.jpg|500px|centré]]

= Mise à jour =

Pour rappel, le serveur que nous allons mettre à jour vient d'être installé, et n'est donc pas encore en utilisation.

<span style=color:red>Si vous avez des serveur en production, qui sont utilisés par des clients ou dans le cadre de processus internes à votre entreprise, s'il vous plaît, ne mettez jamais, JAMAIS, jamais à jour ces serveurs.</span>

Vous n'avez aucune idée des impacts sur les versions des logiciels et vous risquez, en mettant à jour, de créer une incompatibilité et de faire tomber en panne des logiciels ou applications qui fonctionnaient parfaitement.

Les seules mise à jour que l'on s'autorise en production sont celles de sécurité qui servent à ''patcher'' une vulnérabilité. Et là encore, assurez-vous bien que rien ne va ''exploser''. Si c'est une machine virtuelle ou un conteneur, faites un snapshot ou une copie avant de procéder à la modification... surtout si c'est un vendredi à 17h 😢

Bon, vous êtes prévenu !

{|align=center
|-
|align=left|
Remontez d'un cran sur le bouton ''Updates''
|width=10px|
|align=left|
Puis cliquez sur ''Refresh'' pour mettre à jour la liste des paquetages disponibles
|-
|valign=top|
[[Fichier:proxmox update button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update refresh.jpg|100px|centré]]
|}

{|align=center
|-
|align=left|
Quand vous êtes prêt, cliquez sur ''Upgrade''
|width=10px|
|align=left|
une fenêtre et démarrer le processus de mise à jour
|-
|valign=top|
[[Fichier:proxmox upgrade button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update upgrade.jpg|600px|centré]]
|}

= Suppression du message d'abonnement =
Maintenant que les dépôt sont configuré et les mises à jour faites, on va désactiver ce message qui apparaît à chaque connexion au portail web de Proxmox.
[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Pour cela nous allons utiliser l'activateur de ''Jamesits'' disponible sur son [https://github.com/Jamesits/pve-fake-subscription GitHub]

Dans le menu de gauche, cliquez sur l’icône de votre serveur puis sur Shell
{|align=center
|-

|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
→
|valign=top|
[[Fichier:proxmox shell button.jpg|200px|centré]]
|}

Une fois dans le terminal nous allons utiliser la commande ''wget'' pour télécharger le paquetage sur la machine:

<source lang=bash>
# wget https://github.com/Jamesits/pve-fake-subscription/releases/download/v0.0.11/pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Le lien précédent est à récupérer sur la page de téléchargement du projet, assurer-vous d'y faire un tour pour vous assurer qu'il est toujours bon.

Il ne reste plus qu'a l'installer :
<source lang=bash>
# dpkg -i pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Il est recommandé de bloquer le site de vérification des clés en mettant une entrée factice dans le fichier ''hosts'' :
<source lang=bash>
# echo "127.0.0.1 shop.maurer-it.com" > /etc/hosts
</source>

Vous pouvez vérifier que cela fonctionne en faisant un ping:
<source lang=bash>
root@pve-tuto:~# ping shop.maurer-it.com
PING shop.maurer-it.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.010 ms
...
</source>

Pour vérifier que le message à bien disparu, il vous suffit de vous déconnecter puis reconnecter !

= Nommage des cartes réseaux =

Lorsque vous ajoutez / retirez une carte sur un port PCI, les identifiants sont redistribués et cela va affecter le nom des cartes réseaux. Si la carte que vous utilisez pour vous connecter à votre serveur Proxmox (généralement sur le ''vmbr0'') change de nom, vous perdez la connexion à votre serveur... Pas très pratique !

Si vous avez une version supérieur à 9.2 et que vous avez suivie le tutoriel pour [[Proxmox_install | installer Proxmox]] vous avez déjà fixé le nom de votre carte de management, mais qu'en est-il des autres ? Vous l'aurez compris, il faut absolument fixer le noms des cartes pour éviter les surprises !

Une fois vos [[Identify_your_nic | carte identifiées]], il ne vous reste plus qu'à définir leur nom et pour cela je vous conseil d'utiliser leur rôle:
* une carte connectée à une DMZ → dmz
* une carte connectée à un LAN → lan
* une carte connectée à une box → wan

Si vous avez plusieurs cartes par rôle, utilisez des numéros: ''dmz0'', ''dmz1'', ...

Pour fixer le nom on va suivre [[Ifcfg-ethX#Que_faire_si_ma_carte_n'a_pas_le_bon_numéro_?? | le tutoriel sur udev]] et d'abord identifier l'adresse MAC de notre carte:
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 24:12:4d:01:49:20 brd ff:ff:ff:ff:ff:ff
3: enp0s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 24:12:4d:01:49:21 brd ff:ff:ff:ff:ff:ff
altname enp3s0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:8a:07:f7:ce:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.4.240/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fef7:ce9b/64 scope link
valid_lft forever preferred_lft forever
</source>

On a donc:
* enp0s0f1 en management avec l'adresse 24:12:4d:01:49:21
* enp0s0f1 connecté à une DMZ avec l'adresse 24:12:4d:01:49:20

Il ne nous reste plus qu'a créez le fichier ''/etc/udev/rules.d/70-persistent-net.rules'' avec le contenu suivant:
<source lang=bash>
# Carte Intel SFP+ management
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="mgmt"

# Carte Intel SFP+ DMZ
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
</source>

Si vous êtes à distance, n'oubliez pas de modifier votre fichier ''/etc/network/interfaces'' avant de redémarrer:
<source lang=bash>
...
iface mgmt inet manual
iface dmz inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.1/24
gateway 192.168.1.254
bridge-ports mgmt
bridge-stp off
bridge-fd 0

...
</source>

= Personnalisation de l'environnement =

Comme Proxmox est fait sur une base de Debian, certaine commandes disponible sur Rocky risque de vous manquer !

J'aime bien faire un tour dans le fichier ''/root/.bashrc'' pour y ajouter à la fin les lignes suivantes:
<source lang=bash>
alias ll='ls -l'
alias vi=vim.tiny
</source>

Une fois vos modifications terminées, il ne vous reste plus qu'a recharger le fichier ''.bashrc'':
<source lang=bash>
#. .bashrc
</source>

Proxmox first start

2026-06-30T14:24:34Z

Jc.forton :

= Introduction =

Maintenant que votre serveur Proxmox est installé, nous allons effectuer quelques opérations de configuration de bases comme :
* la modification des dépôts
* la mise à jour
* la suppression du message d'abonnement
* le nommage des cartes réseaux
* la personnalisation de l'environnement

= Modification des dépôts =
De base l'équipe de Proxmox vous incite à prendre un abonnement pour profiter des mise à jours et fonctionnalités nécessaires dans un datacenter.

[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Si comme moi, vous utilisez Proxmox dans le cadre d'un homelab, pas besoin de payer, la version ''basic'' est largement suffisante.
{|align=center
|-
|align=left|
Cliquez sur l'icône de votre serveur dans la barre à gauche
|width=10px|
|align=left|
Puis sur ''repositories''
|-
|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories menu.jpg|150px|centré]]
|}

On va dans un premier temps retirez les dépôts ''entreprise'' de Proxmox. Dès que vous voyez ''entreprise'' ou ''pve-entreprise'' dans la colonne ''Components'', il y a de grande chance que le dépôt nécessite un abonnement.

[[Fichier:proxmox repository remove.jpg|900px|centré]]

* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''
* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''

Une grosse croix rouge qui fait peur apparaît

[[Fichier:proxmox repository red corss.jpg|600px|centré]]

Pas de panique, nous allons ajouter le dépôt gratuit pour avoir quand même quelques mise à jours.

{|align=center
|-
|align=left|
Cliquez sur ''add''
|width=10px|
|align=left|
Puis sur ''No-Subscription''
|-
|valign=top|
[[Fichier:proxmox repository add.jpg|250px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories no-subscription.jpg|500px|centré]]
|}

Ouf, la méchante croix rouge à disparue :)

[[Fichier:proxmox repositories no-subscription warning.jpg|500px|centré]]

= Mise à jour =

Pour rappel, le serveur que nous allons mettre à jour vient d'être installé, et n'est donc pas encore en utilisation.

<span style=color:red>Si vous avez des serveur en production, qui sont utilisés par des clients ou dans le cadre de processus internes à votre entreprise, s'il vous plaît, ne mettez jamais, JAMAIS, jamais à jour ces serveurs.</span>

Vous n'avez aucune idée des impacts sur les versions des logiciels et vous risquez, en mettant à jour, de créer une incompatibilité et de faire tomber en panne des logiciels ou applications qui fonctionnaient parfaitement.

Les seules mise à jour que l'on s'autorise en production sont celles de sécurité qui servent à ''patcher'' une vulnérabilité. Et là encore, assurez-vous bien que rien ne va ''exploser''. Si c'est une machine virtuelle ou un conteneur, faites un snapshot ou une copie avant de procéder à la modification... surtout si c'est un vendredi à 17h 😢

Bon, vous êtes prévenu !

{|align=center
|-
|align=left|
Remontez d'un cran sur le bouton ''Updates''
|width=10px|
|align=left|
Puis cliquez sur ''Refresh'' pour mettre à jour la liste des paquetages disponibles
|-
|valign=top|
[[Fichier:proxmox update button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update refresh.jpg|100px|centré]]
|}

{|align=center
|-
|align=left|
Quand vous êtes prêt, cliquez sur ''Upgrade''
|width=10px|
|align=left|
une fenêtre et démarrer le processus de mise à jour
|-
|valign=top|
[[Fichier:proxmox upgrade button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update upgrade.jpg|600px|centré]]
|}

= Suppression du message d'abonnement =
Maintenant que les dépôt sont configuré et les mises à jour faites, on va désactiver ce message qui apparaît à chaque connexion au portail web de Proxmox.
[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Pour cela nous allons utiliser l'activateur de ''Jamesits'' disponible sur son [https://github.com/Jamesits/pve-fake-subscription GitHub]

Dans le menu de gauche, cliquez sur l’icône de votre serveur puis sur Shell
{|align=center
|-

|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
→
|valign=top|
[[Fichier:proxmox shell button.jpg|200px|centré]]
|}

Une fois dans le terminal nous allons utiliser la commande ''wget'' pour télécharger le paquetage sur la machine:

<source lang=bash>
# wget https://github.com/Jamesits/pve-fake-subscription/releases/download/v0.0.11/pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Le lien précédent est à récupérer sur la page de téléchargement du projet, assurer-vous d'y faire un tour pour vous assurer qu'il est toujours bon.

Il ne reste plus qu'a l'installer :
<source lang=bash>
# dpkg -i pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Il est recommandé de bloquer le site de vérification des clés en mettant une entrée factice dans le fichier ''hosts'' :
<source lang=bash>
# echo "127.0.0.1 shop.maurer-it.com" > /etc/hosts
</source>

Vous pouvez vérifier que cela fonctionne en faisant un ping:
<source lang=bash>
root@pve-tuto:~# ping shop.maurer-it.com
PING shop.maurer-it.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.010 ms
...
</source>

Pour vérifier que le message à bien disparu, il vous suffit de vous déconnecter puis reconnecter !

= Nommage des cartes réseaux =

Lorsque vous ajoutez / retirez une carte sur un port PCI, les identifiants sont redistribués et cela va affecter le nom des cartes réseaux. Si la carte que vous utilisez pour vous connecter à votre serveur Proxmox (généralement sur le ''vmbr0'') change de nom, vous perdez la connexion à votre serveur... Pas très pratique !

Si vous avez une version supérieur à 9.2 et que vous avez suivie le tutoriel pour [[Proxmox_install | installer Proxmox]] vous avez déjà fixé le nom de votre carte de management, mais qu'en est-il des autres ? Vous l'aurez compris, il faut absolument fixer le noms des cartes pour éviter les surprises !

Une fois vos [[Identify_your_nic | carte identifiées]], il ne vous reste plus qu'à définir leur nom et pour cela je vous conseil d'utiliser leur rôle:
* une carte connectée à une DMZ → dmz
* une carte connectée à un LAN → lan
* une carte connectée à une box → wan

Si vous avez plusieurs cartes par rôle, utilisez des numéros: ''dmz0'', ''dmz1'', ...

Pour fixer le nom on va suivre [[Ifcfg-ethX#Que_faire_si_ma_carte_n'a_pas_le_bon_numéro_?? | le tutoriel sur udev]] et d'abord identifier l'adresse MAC de notre carte:
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 24:12:4d:01:49:20 brd ff:ff:ff:ff:ff:ff
3: enp0s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 24:12:4d:01:49:21 brd ff:ff:ff:ff:ff:ff
altname enp3s0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:8a:07:f7:ce:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.4.240/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fef7:ce9b/64 scope link
valid_lft forever preferred_lft forever
</source>

On a donc:
* enp0s0f1 en management avec l'adresse 24:12:4d:01:49:21
* enp0s0f1 connecté à une DMZ avec l'adresse 24:12:4d:01:49:20

Il ne nous reste plus qu'a créez le fichier ''/etc/udev/rules.d/70-persistent-net.rules'' avec le contenu suivant:
<source lang=bash>
# Carte Intel SFP+ management
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="mgmt"

# Carte Intel SFP+ DMZ
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
</source>

Si vous êtes à distance, n'oubliez pas de modifier votre fichier ''/etc/network/interfaces'' avant de redémarrer:
<source lang=bash>
...
iface mgmt inet manual
iface dmz inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.1/24
gateway 192.168.1.254
bridge-ports mgmt
bridge-stp off
bridge-fd 0

...
</source>

Proxmox first start

2026-06-30T14:17:44Z

Jc.forton : /* Suppression du message d'abonnement */

= Introduction =

Maintenant que votre serveur Proxmox est installé, nous allons effectuer quelques opérations de configuration de bases comme :
* la modification des dépôts
* la mise à jour
* la suppression du message d'abonnement
* le nommage des cartes réseaux

= Modification des dépôts =
De base l'équipe de Proxmox vous incite à prendre un abonnement pour profiter des mise à jours et fonctionnalités nécessaires dans un datacenter.

[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Si comme moi, vous utilisez Proxmox dans le cadre d'un homelab, pas besoin de payer, la version ''basic'' est largement suffisante.
{|align=center
|-
|align=left|
Cliquez sur l'icône de votre serveur dans la barre à gauche
|width=10px|
|align=left|
Puis sur ''repositories''
|-
|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories menu.jpg|150px|centré]]
|}

On va dans un premier temps retirez les dépôts ''entreprise'' de Proxmox. Dès que vous voyez ''entreprise'' ou ''pve-entreprise'' dans la colonne ''Components'', il y a de grande chance que le dépôt nécessite un abonnement.

[[Fichier:proxmox repository remove.jpg|900px|centré]]

* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''
* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''

Une grosse croix rouge qui fait peur apparaît

[[Fichier:proxmox repository red corss.jpg|600px|centré]]

Pas de panique, nous allons ajouter le dépôt gratuit pour avoir quand même quelques mise à jours.

{|align=center
|-
|align=left|
Cliquez sur ''add''
|width=10px|
|align=left|
Puis sur ''No-Subscription''
|-
|valign=top|
[[Fichier:proxmox repository add.jpg|250px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories no-subscription.jpg|500px|centré]]
|}

Ouf, la méchante croix rouge à disparue :)

[[Fichier:proxmox repositories no-subscription warning.jpg|500px|centré]]

= Mise à jour =

Pour rappel, le serveur que nous allons mettre à jour vient d'être installé, et n'est donc pas encore en utilisation.

<span style=color:red>Si vous avez des serveur en production, qui sont utilisés par des clients ou dans le cadre de processus internes à votre entreprise, s'il vous plaît, ne mettez jamais, JAMAIS, jamais à jour ces serveurs.</span>

Vous n'avez aucune idée des impacts sur les versions des logiciels et vous risquez, en mettant à jour, de créer une incompatibilité et de faire tomber en panne des logiciels ou applications qui fonctionnaient parfaitement.

Les seules mise à jour que l'on s'autorise en production sont celles de sécurité qui servent à ''patcher'' une vulnérabilité. Et là encore, assurez-vous bien que rien ne va ''exploser''. Si c'est une machine virtuelle ou un conteneur, faites un snapshot ou une copie avant de procéder à la modification... surtout si c'est un vendredi à 17h 😢

Bon, vous êtes prévenu !

{|align=center
|-
|align=left|
Remontez d'un cran sur le bouton ''Updates''
|width=10px|
|align=left|
Puis cliquez sur ''Refresh'' pour mettre à jour la liste des paquetages disponibles
|-
|valign=top|
[[Fichier:proxmox update button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update refresh.jpg|100px|centré]]
|}

{|align=center
|-
|align=left|
Quand vous êtes prêt, cliquez sur ''Upgrade''
|width=10px|
|align=left|
une fenêtre et démarrer le processus de mise à jour
|-
|valign=top|
[[Fichier:proxmox upgrade button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update upgrade.jpg|600px|centré]]
|}

= Suppression du message d'abonnement =
Maintenant que les dépôt sont configuré et les mises à jour faites, on va désactiver ce message qui apparaît à chaque connexion au portail web de Proxmox.
[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Pour cela nous allons utiliser l'activateur de ''Jamesits'' disponible sur son [https://github.com/Jamesits/pve-fake-subscription GitHub]

Dans le menu de gauche, cliquez sur l’icône de votre serveur puis sur Shell
{|align=center
|-

|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
→
|valign=top|
[[Fichier:proxmox shell button.jpg|200px|centré]]
|}

Une fois dans le terminal nous allons utiliser la commande ''wget'' pour télécharger le paquetage sur la machine:

<source lang=bash>
# wget https://github.com/Jamesits/pve-fake-subscription/releases/download/v0.0.11/pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Le lien précédent est à récupérer sur la page de téléchargement du projet, assurer-vous d'y faire un tour pour vous assurer qu'il est toujours bon.

Il ne reste plus qu'a l'installer :
<source lang=bash>
# dpkg -i pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Il est recommandé de bloquer le site de vérification des clés en mettant une entrée factice dans le fichier ''hosts'' :
<source lang=bash>
# echo "127.0.0.1 shop.maurer-it.com" > /etc/hosts
</source>

Vous pouvez vérifier que cela fonctionne en faisant un ping:
<source lang=bash>
root@pve-tuto:~# ping shop.maurer-it.com
PING shop.maurer-it.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.010 ms
...
</source>

Pour vérifier que le message à bien disparu, il vous suffit de vous déconnecter puis reconnecter !

= Nommage des cartes réseaux =

Lorsque vous ajoutez / retirez une carte sur un port PCI, les identifiants sont redistribués et cela va affecter le nom des cartes réseaux. Si la carte que vous utilisez pour vous connecter à votre serveur Proxmox (généralement sur le ''vmbr0'') change de nom, vous perdez la connexion à votre serveur... Pas très pratique !

Si vous avez une version supérieur à 9.2 et que vous avez suivie le tutoriel pour [[Proxmox_install | installer Proxmox]] vous avez déjà fixé le nom de votre carte de management, mais qu'en est-il des autres ? Vous l'aurez compris, il faut absolument fixer le noms des cartes pour éviter les surprises !

Une fois vos [[Identify_your_nic | carte identifiées]], il ne vous reste plus qu'à définir leur nom et pour cela je vous conseil d'utiliser leur rôle:
* une carte connectée à une DMZ → dmz
* une carte connectée à un LAN → lan
* une carte connectée à une box → wan

Si vous avez plusieurs cartes par rôle, utilisez des numéros: ''dmz0'', ''dmz1'', ...

Pour fixer le nom on va suivre [[Ifcfg-ethX#Que_faire_si_ma_carte_n'a_pas_le_bon_numéro_?? | le tutoriel sur udev]] et d'abord identifier l'adresse MAC de notre carte:
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 24:12:4d:01:49:20 brd ff:ff:ff:ff:ff:ff
3: enp0s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 24:12:4d:01:49:21 brd ff:ff:ff:ff:ff:ff
altname enp3s0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:8a:07:f7:ce:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.4.240/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fef7:ce9b/64 scope link
valid_lft forever preferred_lft forever
</source>

On a donc:
* enp0s0f1 en management avec l'adresse 24:12:4d:01:49:21
* enp0s0f1 connecté à une DMZ avec l'adresse 24:12:4d:01:49:20

Il ne nous reste plus qu'a créez le fichier ''/etc/udev/rules.d/70-persistent-net.rules'' avec le contenu suivant:
<source lang=bash>
# Carte Intel SFP+ management
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="mgmt"

# Carte Intel SFP+ DMZ
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
</source>

Si vous êtes à distance, n'oubliez pas de modifier votre fichier ''/etc/network/interfaces'' avant de redémarrer:
<source lang=bash>
...
iface mgmt inet manual
iface dmz inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.1/24
gateway 192.168.1.254
bridge-ports mgmt
bridge-stp off
bridge-fd 0

...
</source>

Proxmox first start

2026-06-30T14:16:58Z

Jc.forton : /* Mise à jour */

= Introduction =

Maintenant que votre serveur Proxmox est installé, nous allons effectuer quelques opérations de configuration de bases comme :
* la modification des dépôts
* la mise à jour
* la suppression du message d'abonnement
* le nommage des cartes réseaux

= Modification des dépôts =
De base l'équipe de Proxmox vous incite à prendre un abonnement pour profiter des mise à jours et fonctionnalités nécessaires dans un datacenter.

[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Si comme moi, vous utilisez Proxmox dans le cadre d'un homelab, pas besoin de payer, la version ''basic'' est largement suffisante.
{|align=center
|-
|align=left|
Cliquez sur l'icône de votre serveur dans la barre à gauche
|width=10px|
|align=left|
Puis sur ''repositories''
|-
|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories menu.jpg|150px|centré]]
|}

On va dans un premier temps retirez les dépôts ''entreprise'' de Proxmox. Dès que vous voyez ''entreprise'' ou ''pve-entreprise'' dans la colonne ''Components'', il y a de grande chance que le dépôt nécessite un abonnement.

[[Fichier:proxmox repository remove.jpg|900px|centré]]

* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''
* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''

Une grosse croix rouge qui fait peur apparaît

[[Fichier:proxmox repository red corss.jpg|600px|centré]]

Pas de panique, nous allons ajouter le dépôt gratuit pour avoir quand même quelques mise à jours.

{|align=center
|-
|align=left|
Cliquez sur ''add''
|width=10px|
|align=left|
Puis sur ''No-Subscription''
|-
|valign=top|
[[Fichier:proxmox repository add.jpg|250px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories no-subscription.jpg|500px|centré]]
|}

Ouf, la méchante croix rouge à disparue :)

[[Fichier:proxmox repositories no-subscription warning.jpg|500px|centré]]

= Mise à jour =

Pour rappel, le serveur que nous allons mettre à jour vient d'être installé, et n'est donc pas encore en utilisation.

<span style=color:red>Si vous avez des serveur en production, qui sont utilisés par des clients ou dans le cadre de processus internes à votre entreprise, s'il vous plaît, ne mettez jamais, JAMAIS, jamais à jour ces serveurs.</span>

Vous n'avez aucune idée des impacts sur les versions des logiciels et vous risquez, en mettant à jour, de créer une incompatibilité et de faire tomber en panne des logiciels ou applications qui fonctionnaient parfaitement.

Les seules mise à jour que l'on s'autorise en production sont celles de sécurité qui servent à ''patcher'' une vulnérabilité. Et là encore, assurez-vous bien que rien ne va ''exploser''. Si c'est une machine virtuelle ou un conteneur, faites un snapshot ou une copie avant de procéder à la modification... surtout si c'est un vendredi à 17h 😢

Bon, vous êtes prévenu !

{|align=center
|-
|align=left|
Remontez d'un cran sur le bouton ''Updates''
|width=10px|
|align=left|
Puis cliquez sur ''Refresh'' pour mettre à jour la liste des paquetages disponibles
|-
|valign=top|
[[Fichier:proxmox update button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update refresh.jpg|100px|centré]]
|}

{|align=center
|-
|align=left|
Quand vous êtes prêt, cliquez sur ''Upgrade''
|width=10px|
|align=left|
une fenêtre et démarrer le processus de mise à jour
|-
|valign=top|
[[Fichier:proxmox upgrade button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update upgrade.jpg|600px|centré]]
|}

= Suppression du message d'abonnement =
Maintenant que les dépôt sont configuré et les mises à jour faites, on va désactiver ce message qui apparaît à chaque connexion au portail web de Proxmox.
[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Pour cela nous allons utiliser l'activateur de ''Jamesits'' disponible sur son [https://github.com/Jamesits/pve-fake-subscription GitHub]

Dans le menu de gauche, cliquez sur l’icône de votre serveur puis sur Shell
{|align=center
|-

|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
→
|valign=top|
[[Fichier:proxmox shell button.jpg|200px|centré]]
|}

Une fois dans le terminal nous allons utiliser la commande ''wget'' pour télécharger le paquetage sur la machine:

<source lang=bash>
# wget https://github.com/Jamesits/pve-fake-subscription/releases/download/v0.0.11/pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Le lien précédent est à récupérer sur la page de téléchargement du projet, assurer-vous d'y faire un tour pour vous assurer que le lien est toujours bon.

Il ne reste plus qu'a l'installer :
<source lang=bash>
# dpkg -i pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Il est recommandé de bloquer le site de vérification des clés en mettant une entrée factice dans le fichier ''hosts'' :
<source lang=bash>
# echo "127.0.0.1 shop.maurer-it.com" > /etc/hosts
</source>

Vous pouvez vérifier que cela fonctionne en faisant un ping:
<source lang=bash>
root@pve-tuto:~# ping shop.maurer-it.com
PING shop.maurer-it.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.010 ms
...
</source>

Pour vérifier que le message à bien disparu, il vous suffit de vous déconnecter puis reconnecter !

= Nommage des cartes réseaux =

Lorsque vous ajoutez / retirez une carte sur un port PCI, les identifiants sont redistribués et cela va affecter le nom des cartes réseaux. Si la carte que vous utilisez pour vous connecter à votre serveur Proxmox (généralement sur le ''vmbr0'') change de nom, vous perdez la connexion à votre serveur... Pas très pratique !

Si vous avez une version supérieur à 9.2 et que vous avez suivie le tutoriel pour [[Proxmox_install | installer Proxmox]] vous avez déjà fixé le nom de votre carte de management, mais qu'en est-il des autres ? Vous l'aurez compris, il faut absolument fixer le noms des cartes pour éviter les surprises !

Une fois vos [[Identify_your_nic | carte identifiées]], il ne vous reste plus qu'à définir leur nom et pour cela je vous conseil d'utiliser leur rôle:
* une carte connectée à une DMZ → dmz
* une carte connectée à un LAN → lan
* une carte connectée à une box → wan

Si vous avez plusieurs cartes par rôle, utilisez des numéros: ''dmz0'', ''dmz1'', ...

Pour fixer le nom on va suivre [[Ifcfg-ethX#Que_faire_si_ma_carte_n'a_pas_le_bon_numéro_?? | le tutoriel sur udev]] et d'abord identifier l'adresse MAC de notre carte:
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 24:12:4d:01:49:20 brd ff:ff:ff:ff:ff:ff
3: enp0s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 24:12:4d:01:49:21 brd ff:ff:ff:ff:ff:ff
altname enp3s0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:8a:07:f7:ce:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.4.240/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fef7:ce9b/64 scope link
valid_lft forever preferred_lft forever
</source>

On a donc:
* enp0s0f1 en management avec l'adresse 24:12:4d:01:49:21
* enp0s0f1 connecté à une DMZ avec l'adresse 24:12:4d:01:49:20

Il ne nous reste plus qu'a créez le fichier ''/etc/udev/rules.d/70-persistent-net.rules'' avec le contenu suivant:
<source lang=bash>
# Carte Intel SFP+ management
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="mgmt"

# Carte Intel SFP+ DMZ
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
</source>

Si vous êtes à distance, n'oubliez pas de modifier votre fichier ''/etc/network/interfaces'' avant de redémarrer:
<source lang=bash>
...
iface mgmt inet manual
iface dmz inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.1/24
gateway 192.168.1.254
bridge-ports mgmt
bridge-stp off
bridge-fd 0

...
</source>

Proxmox fail2ban

2026-06-30T11:27:29Z

Jc.forton : /* Introduction */

Proxmox first start

2026-06-30T11:27:05Z

Jc.forton : /* Nommage des cartes réseaux */

= Introduction =

Maintenant que votre serveur Proxmox est installé, nous allons effectuer quelques opérations de configuration de bases comme :
* la modification des dépôts
* la mise à jour
* la suppression du message d'abonnement
* le nommage des cartes réseaux

= Modification des dépôts =
De base l'équipe de Proxmox vous incite à prendre un abonnement pour profiter des mise à jours et fonctionnalités nécessaires dans un datacenter.

[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Si comme moi, vous utilisez Proxmox dans le cadre d'un homelab, pas besoin de payer, la version ''basic'' est largement suffisante.
{|align=center
|-
|align=left|
Cliquez sur l'icône de votre serveur dans la barre à gauche
|width=10px|
|align=left|
Puis sur ''repositories''
|-
|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories menu.jpg|150px|centré]]
|}

On va dans un premier temps retirez les dépôts ''entreprise'' de Proxmox. Dès que vous voyez ''entreprise'' ou ''pve-entreprise'' dans la colonne ''Components'', il y a de grande chance que le dépôt nécessite un abonnement.

[[Fichier:proxmox repository remove.jpg|900px|centré]]

* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''
* cliquez sur le dépôt ''ceph-squid'' puis sur le bouton ''disable''

Une grosse croix rouge qui fait peur apparaît

[[Fichier:proxmox repository red corss.jpg|600px|centré]]

Pas de panique, nous allons ajouter le dépôt gratuit pour avoir quand même quelques mise à jours.

{|align=center
|-
|align=left|
Cliquez sur ''add''
|width=10px|
|align=left|
Puis sur ''No-Subscription''
|-
|valign=top|
[[Fichier:proxmox repository add.jpg|250px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox repositories no-subscription.jpg|500px|centré]]
|}

Ouf, la méchante croix rouge à disparue :)

[[Fichier:proxmox repositories no-subscription warning.jpg|500px|centré]]

= Mise à jour =

Pour rappel, le serveur que nous allons mettre à jour vient d'être installé, et n'est donc pas encore en utilisation.

<span style=color:red>Si vous avez des serveur en production, qui sont utilisés par des clients ou dans le cadre de processus internes à votre entreprise, s'il vous plaît, ne mettez jamais, JAMAIS, jamais à jour ces serveurs.</span>

Vous n'avez aucune idée des impacts sur les versions des logiciels et vous risquez, en mettant à jour, de créer une incompatibilité et de faire tomber en panne des logiciels ou applications qui fonctionnaient parfaitement.

Les seules mise à jour que l'on s'autorise en production sont celles de sécurité qui servent à ''patcher'' une vulnérabilité. Et là encore, assurez-vous bien que rien ne va ''exploser''. Si c'est une machine virtuelle ou un conteneur, faites un snapshot ou une copie avant de procéder à la modification... surtout si c'est un vendredi à 17h 😢

Bon, vous êtes prévenu !

{|align=center
|-
|align=left|
Remontez d'un cran sur le bouton ''Updates''
|width=10px|
|align=left|
Puis cliquez sur ''Refresh'' pour mettre à jour la liste des paquetages disponibles
|-
|valign=top|
[[Fichier:proxmox update button.jpg|150px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update refresh.jpg|100px|centré]]
|}

{|align=center
|-
|align=left|
Quand vous êtes prêt, cliquez sur ''Upgrade''
|width=10px|
|align=left|
une fenêtre et démarrer le processus de mise à jour
|-
|valign=top|
[[Fichier:proxmox upgrade button.jpg|100px|centré]]
|width=10px|
|valign=top|
[[Fichier:proxmox update upgrade.jpg|500px|centré]]
|}

= Suppression du message d'abonnement =
Maintenant que les dépôt sont configuré et les mises à jour faites, on va désactiver ce message qui apparaît à chaque connexion au portail web de Proxmox.
[[Fichier:proxmox subscribe message.jpg|500px|centré]]

Pour cela nous allons utiliser l'activateur de ''Jamesits'' disponible sur son [https://github.com/Jamesits/pve-fake-subscription GitHub]

Dans le menu de gauche, cliquez sur l’icône de votre serveur puis sur Shell
{|align=center
|-

|valign=top|
[[Fichier:proxmox server menu left.jpg|350px|centré]]
|width=10px|
→
|valign=top|
[[Fichier:proxmox shell button.jpg|200px|centré]]
|}

Une fois dans le terminal nous allons utiliser la commande ''wget'' pour télécharger le paquetage sur la machine:

<source lang=bash>
# wget https://github.com/Jamesits/pve-fake-subscription/releases/download/v0.0.11/pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Le lien précédent est à récupérer sur la page de téléchargement du projet, assurer-vous d'y faire un tour pour vous assurer que le lien est toujours bon.

Il ne reste plus qu'a l'installer :
<source lang=bash>
# dpkg -i pve-fake-subscription_0.0.11+git-1_all.deb
</source>

Il est recommandé de bloquer le site de vérification des clés en mettant une entrée factice dans le fichier ''hosts'' :
<source lang=bash>
# echo "127.0.0.1 shop.maurer-it.com" > /etc/hosts
</source>

Vous pouvez vérifier que cela fonctionne en faisant un ping:
<source lang=bash>
root@pve-tuto:~# ping shop.maurer-it.com
PING shop.maurer-it.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.010 ms
...
</source>

Pour vérifier que le message à bien disparu, il vous suffit de vous déconnecter puis reconnecter !

= Nommage des cartes réseaux =

Lorsque vous ajoutez / retirez une carte sur un port PCI, les identifiants sont redistribués et cela va affecter le nom des cartes réseaux. Si la carte que vous utilisez pour vous connecter à votre serveur Proxmox (généralement sur le ''vmbr0'') change de nom, vous perdez la connexion à votre serveur... Pas très pratique !

Si vous avez une version supérieur à 9.2 et que vous avez suivie le tutoriel pour [[Proxmox_install | installer Proxmox]] vous avez déjà fixé le nom de votre carte de management, mais qu'en est-il des autres ? Vous l'aurez compris, il faut absolument fixer le noms des cartes pour éviter les surprises !

Une fois vos [[Identify_your_nic | carte identifiées]], il ne vous reste plus qu'à définir leur nom et pour cela je vous conseil d'utiliser leur rôle:
* une carte connectée à une DMZ → dmz
* une carte connectée à un LAN → lan
* une carte connectée à une box → wan

Si vous avez plusieurs cartes par rôle, utilisez des numéros: ''dmz0'', ''dmz1'', ...

Pour fixer le nom on va suivre [[Ifcfg-ethX#Que_faire_si_ma_carte_n'a_pas_le_bon_numéro_?? | le tutoriel sur udev]] et d'abord identifier l'adresse MAC de notre carte:
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 24:12:4d:01:49:20 brd ff:ff:ff:ff:ff:ff
3: enp0s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 24:12:4d:01:49:21 brd ff:ff:ff:ff:ff:ff
altname enp3s0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:8a:07:f7:ce:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.4.240/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fef7:ce9b/64 scope link
valid_lft forever preferred_lft forever
</source>

On a donc:
* enp0s0f1 en management avec l'adresse 24:12:4d:01:49:21
* enp0s0f1 connecté à une DMZ avec l'adresse 24:12:4d:01:49:20

Il ne nous reste plus qu'a créez le fichier ''/etc/udev/rules.d/70-persistent-net.rules'' avec le contenu suivant:
<source lang=bash>
# Carte Intel SFP+ management
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="mgmt"

# Carte Intel SFP+ DMZ
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="24:12:4d:01:49:21", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
</source>

Si vous êtes à distance, n'oubliez pas de modifier votre fichier ''/etc/network/interfaces'' avant de redémarrer:
<source lang=bash>
...
iface mgmt inet manual
iface dmz inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.1/24
gateway 192.168.1.254
bridge-ports mgmt
bridge-stp off
bridge-fd 0

...
</source>

Proxmox first start

2026-06-30T11:09:47Z

Jc.forton : /* Connaître ces cartes */

Identify your nic

2026-06-30T11:09:04Z

Jc.forton : /* Contrôle par l'état du lien */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande ''lspci'':
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''.

Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom et notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux et pour ça nous allons utiliser l'état des liens pour déterminer le numéro de chaque port.

Commencez par déconnecter chaque prises sauf une pour que toutes les ports soient dans un état bas ou ''down'' sauf un qui sera ''up'':
<source lang=bash>
# ip a
...
3: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 24:8a:07:f7:bd:20 brd ff:ff:ff:ff:ff:ff
4: enp1s0f1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:21 brd ff:ff:ff:ff:ff:ff
...
</source>

Vous savez que le port connecté possède la fonction 1 (''enp1s0f1'') et celui débranché à la fonction 0 (''enp1s0f0'')

Identify your nic

2026-06-30T11:04:32Z

Jc.forton : /* Contrôle par l'état du lien */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande ''lspci'':
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''.

Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom et notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux et pour ça nous allons utiliser l'état des liens pour déterminer le numéro de chaque port.

Commencez par retirer chaque prises pour que toutes les cartes soient dans un état bas ou ''down''

<source lang=bash>

</source>

{|align=center
|-
|valign=top|
La
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

On va

Identify your nic

2026-06-30T11:01:40Z

Jc.forton : /* Identifiants PCI et prédictions */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande ''lspci'':
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''.

Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom et notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux...

{|align=center
|-
|valign=top|
La
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

On va

Identify your nic

2026-06-30T11:00:34Z

Jc.forton : /* Identifiants PCI et prédictions */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande ''lspci'':
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''. Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom.
Notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux...

{|align=center
|-
|valign=top|
La
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

On va

Identify your nic

2026-06-30T11:00:17Z

Jc.forton : /* Connaître ces cartes */

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|300px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande suivante:
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''. Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom.
Notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux...

{|align=center
|-
|valign=top|
La
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

On va

Identify your nic

2026-06-30T10:59:22Z

Jc.forton : Page créée avec « = Introduction = Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire ! = La logique = Les premières lettres correspondent au type de carte: * en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet] * wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)] * ib pour [https://fr.wikipe... »

= Introduction =

Lorsque l'on arrive sur une machine qui possède plusieurs cartes réseau, il est souvent difficile de faire le lien entre une carte logique (enp1s0, eno2, wl0, ...) et une carte physique et nous allons voir comment faire !

= La logique =

Les premières lettres correspondent au type de carte:
* en pour [https://fr.wikipedia.org/wiki/Ethernet Ethernet]
* wl pour [https://fr.wikipedia.org/wiki/Wi-Fi Wireless (Wi-Fi)]
* ib pour [https://fr.wikipedia.org/wiki/Bus_InfiniBand InfiniBand]
* sl pour [https://fr.wikipedia.org/wiki/Serial_Line_Internet_Protocol Serial Line IP]
* ...

Vient ensuite le type de connexion:
* ''o'' pour ''onboard'' ou intégré
* ''p'' pour ''pci'', c'est à dire une carte branché sur des [https://fr.wikipedia.org/wiki/PCI_Express lignes PCI] au processeur

Dans le cas d'une carte en PCI on poursuit avec le numéro du ''slot'' que l'on peut assimiler au nombre de puces présente sur la carte.
Une carte possédant deux puces aura donc deux ''slot'' : ''s0'' et ''s1''

Et on termine avec la fonction que l'on peut assimiler au nombre de ports par puce. Une puce possédant deux ports aura donc deux fonctions: ''f0'' et ''f1''.

Pour résumer, les cartes intégrées possèdent des noms comme:
* ''eno0''
* ''eno1''
* ...

Et les cartes en PCI des noms comme:
* ''enp0s0f1''
* ''enp0s0f1''
* ''enp1s0f0''
* ...
= Connaître ces cartes =

Pour démarrer le travail d'identification, vous pouvez commencez par repérer le constructeur et / ou le modèle de puce utilisé, souvent mentionné:

{|align=center
|-
|valign=top|
Sur la boîte de votre carte mère...
|width=10px|
|valign=top|
ou bien dans son manuel...
|width=10px|
|valign=top|
ou dans l'annonce si c'est une carte PCI
|-
|valign=top|
[[Fichier:motherboard box Z370.jpg|400px|centré]]
|width=10px|
|valign=top|
[[Fichier:motherboard manual Z270.jpg|350px|centré]]
|width=10px|
|valign=top|
[[Fichier:amazon mellanox connect-x3.jpg|400px|centré]]
|}

= Identifiants PCI et prédictions =

Il faut maintenant faire le parallèle avec les cartes afficher dans le terminal et pour ça nous allons utiliser la commande suivante:
<source lang=bash>
# lspci | grep Ethernet
01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
</source>

On voit que la carte Realtek RTL8111 (celle de la carte mère) possède l'identifiant 03:00.0 et que la Mellanox l'identifiant 01:00.0

Il faut maintenant transposer ces identifiants en nom:
* le premier chiffre correspond a l'identifiant PCI généré par le micrologiciel de la carte mère (p3 et p1)
* le deuxième correspond au ''slot'' (s0)
* le dernier à la fonction (f0)

Un nom possible pour la carte Realtek pourrait être ''enp3s0f0''. Cependant, il est possible lorsque les cartes ne possèdent qu'une fonction, d'omettre celle-ci pour raccourcir le nom.
Notre carte pourrait donc s’appeler ''enp3s0''

On peut confirmer cela grâce à la commande ''ip'':
<source lang=bash>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 30:9c:23:20:8c:dd brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:f7:bd:22 brd ff:ff:ff:ff:ff:ff
</source>

On peut en déduire que:
* la carte Realtek en gigabit possède l'identifiant enp3s0
* la carte Mellanox de 10 gigabit possède l'identifiant enp1s0

= Contrôle par le débit =

Si vous avez toujours des doutes vous pouvez afficher le débit des cartes grâce à la commande ''ethtool'':

{|align=center
|-
|valign=top|
La Realtek aura un débit max de 1000
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

= Contrôle par l'état du lien =

Si vous possédez une carte avec plusieurs fonctions (ports), il vous reste à différencier les ports entres eux...

{|align=center
|-
|valign=top|
La
|width=10px|
|valign=top|
La Mellanox pourra monter à 10 Gigabit
|-
|valign=top|
<source lang=bash>
# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
...
</source>
|width=10px|
|valign=top|
<source lang=bash>
# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
...
</source>
|}

On va