EOLE3 — Accès, sécurité et pare-feu

EOLE3 — Accès, sécurité et pare-feu

1. Objet du document

Cette documentation décrit l'organisation des accès et les mécanismes de sécurité du serveur EOLE3.

Elle couvre notamment :

• les comptes d'administration ;
• les comptes techniques nominatifs ;
• les comptes clients SFTP ;
• les accès réseau publics et privés ;
• le pare-feu nftables ;
• Fail2ban ;
• les procédures de maintenance et de retour arrière.

Principe général : n'exposer sur Internet que les services strictement nécessaires.

Voir également :

• EOLE3 — Administration, maintenance et flux de données
• EOLE3 — Checklist mensuelle de sécurité

2. Architecture réseau

2.1 Interfaces

Interface	Adresse	Utilisation
enp9s0f0np0	51.178.110.230	Réseau public OVH
enp9s0f1np1	192.168.123.202/24	Réseau privé OVH vRack

EOLE3 dispose également d'une connectivité IPv6 publique.

Le réseau privé vRack est utilisé pour les échanges techniques entre serveurs, notamment les accès NFS et la supervision.

2.2 Politique de sécurité

Les flux entrants sont refusés par défaut.

Seuls sont autorisés :

• les connexions déjà établies ;
• les communications locales ;
• les communications du réseau privé vRack ;
• les services publics explicitement autorisés ;
• les connexions SSH provenant des adresses administratives autorisées ;
• les protocoles nécessaires au fonctionnement réseau, notamment ICMP et ICMPv6.

Les flux sortants ne sont pas filtrés par la configuration AJLSM actuelle.

3. Politique des accès

Les comptes sont répartis en quatre catégories :

1. compte système root ;
2. compte d'administration ubuntu ;
3. comptes techniques nominatifs ;
4. comptes clients SFTP.

Cette séparation évite de mélanger les usages d'administration, de maintenance et de transfert de fichiers.

3.1 Compte root

Le compte root dispose de tous les privilèges système.

Il est utilisé pour :

• l'administration du système ;
• la gestion ZFS ;
• les modifications de configuration ;
• les opérations de migration ;
• la maintenance et le dépannage ;
• la gestion des droits et propriétaires ;
• les opérations critiques sur les données clients.

Son utilisation doit rester réservée aux opérations nécessitant réellement des privilèges administratifs.

3.2 Compte ubuntu

Le compte ubuntu constitue un point d'entrée pour l'administration distante.

Il permet notamment :

• la connexion SSH ;
• l'utilisation de sudo ;
• les opérations courantes d'administration.

Il ne doit pas être utilisé comme compte client ou compte de dépôt.

3.3 Comptes techniques nominatifs

Les comptes techniques sont individuels.

Principes :

• un compte par personne ;
• authentification par clé SSH ;
• droits attribués selon les besoins ;
• utilisation de sudo lorsque nécessaire ;
• traçabilité des interventions.

Les comptes nominatifs ne doivent pas être partagés.

3.4 Comptes clients SFTP

Les comptes clients servent aux dépôts et récupérations de fichiers.

Exemple : ad53.

Ils sont associés à la logique métier Pleade et au confinement SFTP.

La configuration OpenSSH documentée utilise notamment :

Match Group eole3-sftp
    ChrootDirectory %h
    ForceCommand internal-sftp -P setstat,fsetstat

Les restrictions complémentaires de transfert et de tunnel doivent être vérifiées dans la configuration SSH effective.

Les comptes clients concernés :

• ne disposent pas d'un shell interactif ;
• sont confinés dans leur environnement ;
• ne peuvent pas accéder librement aux données des autres clients ;
• restent soumis aux permissions Unix.

Attention : ces comptes SFTP OpenSSH ne doivent pas être confondus avec les utilisateurs gérés par le service SFTPGo sur le port 2022.

3.5 Permissions des données

Les permissions d'écriture sont définies par les droits Unix et les ACL éventuelles.

Dans l'organisation documentée, les zones de travail comprennent notamment :

/data/pleade
/data/projets

Les répertoires suivants ne doivent pas devenir librement accessibles en écriture :

/data
/data/data-private

Les droits réels doivent être contrôlés avant toute modification.

4. Pare-feu nftables

4.1 Solution retenue

EOLE3 utilise nftables pour le filtrage réseau.

Le pare-feu AJLSM est indépendant de Fail2ban.

Il utilise exclusivement :

table inet ajlsm_eole3

Fail2ban conserve sa propre table :

table inet f2b-table

Ne jamais utiliser flush ruleset pour administrer le pare-feu AJLSM.

Cette commande pourrait supprimer les règles de Fail2ban.

Le service standard nftables.service n'est pas utilisé pour charger la configuration AJLSM.

4.2 Fichiers de configuration

Fichier	Fonction
/etc/nftables/ajlsm-eole3.nft	Configuration principale du pare-feu
/etc/nftables/ajlsm-eole3-reload.nft	Rechargement atomique des règles
/etc/systemd/system/ajlsm-firewall.service	Service systemd dédié
/root/ajlsm-eole3.nft	Copie de travail historique

La configuration de référence est celle située dans /etc/nftables/.

4.3 Ports publics autorisés

Port	Protocole	Service	Origine autorisée
80	TCP	Apache HTTP	Internet
443	TCP	Apache HTTPS	Internet
2022	TCP	SFTPGo	Internet
22	TCP / IPv4	SSH administration	Adresses administratives autorisées

4.4 Adresses administratives autorisées

Adresse IPv4	Usage
109.190.129.96	Bureau AJLSM
82.66.151.165	Domicile

Toute modification de ces adresses nécessite une mise à jour du fichier nftables.

Ne jamais remplacer une adresse administrative sans avoir vérifié la possibilité de conserver un accès au serveur.

4.5 Ports interdits depuis Internet

Port	Service	Politique
111	RPC	Réseau privé uniquement
2049	NFS	Réseau privé uniquement
9001	Lighttpd	Réseau privé uniquement
9090	Cockpit	Non accessible publiquement
4330	PCP	Non accessible publiquement
44321–44323	PCP	Non accessibles publiquement

Le pare-feu autorise les communications provenant du réseau privé 192.168.123.0/24 lorsqu'elles arrivent par l'interface vRack.

4.6 Configuration nftables

Le fichier principal est :

/etc/nftables/ajlsm-eole3.nft

Configuration validée lors des tests du 16 octobre 2026 :

#!/usr/sbin/nft -f

table inet ajlsm_eole3 {

    define WAN = "enp9s0f0np0"
    define VRACK = "enp9s0f1np1"

    define ADMIN_IPS = {
        109.190.129.96,
        82.66.151.165
    }

    chain input {
        type filter hook input priority filter;
        policy drop;

        ct state established,related accept
        ct state invalid drop

        iifname "lo" accept

        iifname $VRACK ip saddr 192.168.123.0/24 accept

        iifname $WAN ip protocol udp \
            udp sport 67 udp dport 68 accept

        ip protocol icmp accept
        meta l4proto ipv6-icmp accept

        iifname $WAN tcp dport { 80, 443 } accept

        iifname $WAN tcp dport 2022 accept

        iifname $WAN ip saddr $ADMIN_IPS tcp dport 22 accept
    }
}

Cette configuration applique une politique de refus par défaut aux connexions entrantes.

Elle n'ajoute pas de règles aux chaînes forward et output.

4.7 Rechargement atomique

Le fichier :

/etc/nftables/ajlsm-eole3-reload.nft

contient :

#!/usr/sbin/nft -f

destroy table inet ajlsm_eole3
include "/etc/nftables/ajlsm-eole3.nft"

L'instruction destroy et le chargement de la nouvelle table sont exécutés dans une même transaction nftables.

Le rechargement ne modifie pas la table Fail2ban.

4.8 Service systemd

Le pare-feu est géré par :

ajlsm-firewall.service

Commandes principales :

État :

systemctl status ajlsm-firewall.service

Démarrage :

systemctl start ajlsm-firewall.service

Arrêt :

systemctl stop ajlsm-firewall.service

Rechargement :

systemctl reload ajlsm-firewall.service

Activation au démarrage :

systemctl enable ajlsm-firewall.service

Désactivation au démarrage :

systemctl disable ajlsm-firewall.service

Important : enable et disable modifient uniquement le comportement au démarrage. Ils ne démarrent ni n'arrêtent immédiatement le pare-feu.

4.9 Vérifications

Lister les tables :

nft list tables

Avec le pare-feu actif, les tables attendues sont :

table inet f2b-table
table inet ajlsm_eole3

Afficher les règles AJLSM :

nft list table inet ajlsm_eole3

Vérifier la syntaxe avant toute modification :

nft -c -f /etc/nftables/ajlsm-eole3-reload.nft

Vérifier le service :

systemctl is-active ajlsm-firewall.service
systemctl is-enabled ajlsm-firewall.service

5. Procédure de modification du pare-feu

5.1 Précautions obligatoires

Avant toute modification :

1. conserver une session SSH administrative ouverte ;
2. disposer d'un accès de secours au serveur ;
3. vérifier les adresses administratives autorisées ;
4. sauvegarder la configuration précédente ;
5. vérifier la syntaxe ;
6. programmer un retour arrière automatique ;
7. tester les services après modification.

Ne jamais modifier les règles de filtrage à distance sans possibilité de retour arrière.

5.2 Sauvegarder la configuration

cp -a /etc/nftables/ajlsm-eole3.nft \
  /etc/nftables/ajlsm-eole3.nft.bak

Pour les interventions successives, utiliser de préférence des sauvegardes horodatées.

5.3 Vérifier les règles

nft -c -f /etc/nftables/ajlsm-eole3-reload.nft

Cette commande ne modifie pas le pare-feu actif.

5.4 Programmer un retour arrière

Exemple : arrêt automatique du service après 15 minutes.

systemd-run \
  --unit=ajlsm-firewall-rollback \
  --on-active=15min \
  /usr/bin/systemctl stop ajlsm-firewall.service

Vérification :

systemctl list-timers --all | grep ajlsm-firewall-rollback

Attention : un retour arrière qui arrête uniquement le service ne restaure pas automatiquement une ancienne configuration.

Pour une modification de règles, prévoir également la restauration du fichier précédent si nécessaire.

5.5 Appliquer les modifications

systemctl reload ajlsm-firewall.service

Puis :

systemctl status ajlsm-firewall.service --no-pager
nft list tables

5.6 Vérifier les accès

Tester notamment :

• une nouvelle connexion SSH depuis une adresse administrative ;
• les accès HTTP et HTTPS ;
• SFTPGo ;
• les échanges NFS sur le vRack ;
• la supervision Centreon ;
• le blocage des ports internes depuis une connexion extérieure.

6. Tests de sécurité réalisés le 16 octobre 2026

6.1 Origine du test

Les tests ont été réalisés depuis un Mac connecté au partage de connexion mobile d'un iPhone.

Adresse IPv4 publique utilisée :

176.135.13.221

Cette adresse n'appartient pas à la liste des adresses administratives autorisées.

6.2 Résultats

Port	Résultat observé	Conforme
22	Bloqué	Oui
80	Accessible	Oui
443	Accessible	Oui
2022	Accessible	Oui
111	Bloqué	Oui
2049	Bloqué	Oui
9001	Bloqué	Oui
9090	Bloqué	Oui
4330	Bloqué	Oui
44321–44323	Bloqués	Oui

Les résultats confirment le comportement attendu des règles IPv4 pour les ports TCP testés.

6.3 Tests internes

Les vérifications précédentes ont confirmé :

• les accès NFS depuis les serveurs du vRack ;
• le fonctionnement de Lighttpd ;
• le fonctionnement de la supervision Centreon ;
• les accès publics Apache et SFTPGo ;
• l'accès SSH depuis le bureau.

6.4 Limites des tests

Les tests extérieurs ont principalement porté sur IPv4 et TCP.

Ils ne constituent pas un audit exhaustif de l'exposition IPv6, des services UDP ou de la configuration applicative.

Ces points doivent faire l'objet de contrôles complémentaires.

7. Fail2ban

7.1 Principe

Fail2ban complète le pare-feu en bloquant temporairement certaines adresses IP à partir des événements détectés dans les journaux.

Il ne remplace pas la politique de filtrage nftables.

Les règles Fail2ban sont gérées indépendamment dans :

table inet f2b-table

7.2 Vérification

systemctl status fail2ban
fail2ban-client status

Vérification de la jail SSH :

fail2ban-client status sshd

Les autres jails doivent être contrôlées selon la configuration réellement active.

Ne pas considérer qu'une jail SFTPGo ou Cockpit existe sans l'avoir vérifié.

7.3 Précautions

• Ne pas supprimer la table Fail2ban.
• Ne pas utiliser flush ruleset.
• Vérifier les exclusions d'adresses administratives.
• Contrôler régulièrement les bannissements.
• Vérifier les journaux en cas d'activité inhabituelle.

8. SSH

8.1 Politique réseau

Le port SSH 22 est accessible depuis les adresses administratives autorisées.

Il est bloqué depuis les autres adresses publiques IPv4.

Le pare-feu ne prévoit pas d'ouverture publique SSH en IPv6.

8.2 Authentification

La configuration d'authentification SSH doit être contrôlée séparément.

Commandes :

sshd -T | grep -E \
  '^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Les restrictions par groupe doivent également être vérifiées dans les fichiers de configuration SSH.

Attention : le filtrage réseau et l'authentification SSH sont deux mécanismes distincts.

9. SFTPGo

SFTPGo est accessible publiquement sur le port TCP 2022.

Son exposition est volontaire pour permettre les transferts clients.

La sécurité repose notamment sur :

• l'authentification des utilisateurs ;
• les permissions des comptes ;
• la limitation des accès aux données ;
• la journalisation ;
• les éventuelles protections Fail2ban effectivement configurées.

Vérification :

systemctl status sftpgo
journalctl -u sftpgo --since "24 hours ago"

Les interfaces d'administration de SFTPGo ne doivent pas être exposées publiquement sans justification et protection adaptées.

10. NFS et vRack

Les échanges NFS sont autorisés sur le réseau privé :

192.168.123.0/24

Les ports NFS et RPC ne sont pas accessibles depuis Internet lorsque le pare-feu AJLSM est actif.

Vérifications :

exportfs -v
showmount -e localhost
ss -tulpen

Les exports NFS doivent conserver leurs propres restrictions d'accès.

Le pare-feu ne remplace pas les contrôles définis dans la configuration NFS.

11. Supervision Centreon

La supervision d'EOLE3 doit utiliser son adresse privée vRack :

192.168.123.202

Cette configuration permet de superviser les services internes sans ouvrir leurs ports sur Internet.

Lors des tests du 16 octobre 2026, la supervision a été adaptée pour utiliser cette adresse.

12. Tests réseau depuis l'extérieur

Pour tester réellement les restrictions Internet, il faut utiliser une connexion extérieure indépendante du bureau et des VPN.

12.1 Particularité du Mac AJLSM

L'adaptateur Ethernet USB du Mac utilise :

en7

Le Wi-Fi utilise :

en0

macOS peut continuer à privilégier Ethernet même lorsque le partage de connexion de l'iPhone est activé.

12.2 Procédure

1. Désactiver les VPN.
2. Désactiver temporairement l'adaptateur Ethernet en7.
3. Connecter le Mac au partage de connexion de l'iPhone.
4. Vérifier la route et l'adresse publique.

route -n get 1.1.1.1
curl -4 https://api.ipify.org
echo

L'interface attendue est en0.

L'adresse publique doit être différente de celle du bureau.

12.3 Tester les ports

for port in 22 80 443 2022 111 2049 9001 9090 4330 44321 44322 44323; do
    nc -vz -G 3 51.178.110.230 "$port" 2>&1
done

Après les tests, réactiver Ethernet.

13. Contrôles après redémarrage

Après chaque redémarrage d'EOLE3 :

1. vérifier le service AJLSM ;
2. vérifier Fail2ban ;
3. contrôler les tables nftables ;
4. tester une nouvelle connexion SSH ;
5. vérifier Apache et SFTPGo ;
6. vérifier les échanges NFS ;
7. contrôler Centreon.

Commandes :

systemctl is-active ajlsm-firewall.service
systemctl is-enabled ajlsm-firewall.service

systemctl is-active fail2ban.service

nft list tables

14. Règles à ne jamais oublier

• Ne jamais utiliser flush ruleset.
• Ne jamais activer UFW en parallèle sans étude préalable.
• Ne jamais exposer NFS sur Internet.
• Ne jamais ouvrir Cockpit publiquement.
• Ne jamais modifier les adresses SSH autorisées sans accès de secours.
• Toujours conserver un mécanisme de retour arrière.
• Toujours tester depuis une véritable connexion extérieure.
• Toujours vérifier Fail2ban après une modification du pare-feu.
• Toujours vérifier les services internes après modification.

15. Historique

Date	Intervention
16/10/2026	Création et validation des règles nftables AJLSM
16/10/2026	Validation des accès publics et des restrictions depuis le réseau mobile
16/10/2026	Validation du démarrage, de l'arrêt et du rechargement via systemd
16/10/2026	Activation du service au démarrage ; vérification finale de persistance à confirmer