Securite Flotte SECIVDA — Reference unique¶

REGLE OPERATIONNELLE FORTE : AUCUNE action de securite ne doit etre engagee sans avoir lu ce fichier au prealable. Ouvrir une regle firewall, changer un port, exposer un service, modifier SSH, deployer un nouveau service, faire une MAJ : CONSULTER d'abord ce doc. Toute deviation = derive ; toute MAJ = mise a jour ici en meme temps.

Perimetre : couvre TOUS les serveurs SECIVDA (10 hotes : 5 Dokploy prod + 1 Dokploy tools + bastion + 2 Plesk + 1 Mail catch-all).

Mis a jour : 2026-05-13. Owner : Jeff. Audit retour : trimestriel.

0. Comment utiliser ce document¶

1. Avant action securite : ouvrir la fiche du serveur concerne (§3) + verifier surface d'attaque attendue (§4) + appliquer la procedure anti-derive (§5).
2. Apres action securite : mettre a jour la fiche du serveur + tableau §4 + historique §8.
3. Lors d'une MAJ paquets/kernel/Docker : derouler la checklist post-MAJ (§5.2). NE PAS rebooter sans verifier persistance iptables.
4. Audit periodique : tous les 3 mois, executer le scan externe (§6) et confronter au tableau §4.
5. Controle automatique : script secivda-security-check.sh deploye sur tous serveurs + cron quotidien + alerte ntfy si derive (§7).

1. Standards transverses (DOIT etre identique sur TOUS les serveurs Dokploy)¶

Tout ecart sur l'un des items ci-dessous = derive a corriger immediatement. Le controle automatique §7 verifie chaque item.

2. Pattern DOCKER-USER ISO flotte¶

Fichier : /etc/iptables/docker-user.rules

*filter
:DOCKER-USER - [0:0]
-A DOCKER-USER -s 130.180.220.25/32 -p tcp -m tcp --dport 3000 -j ACCEPT
-A DOCKER-USER -s 149.71.44.170/32 -p tcp -m tcp --dport 3000 -j ACCEPT
-A DOCKER-USER -s 172.16.0.0/12 -d 172.16.0.0/12 -p tcp -m tcp --dport 3000 -j ACCEPT
-A DOCKER-USER -p tcp -m tcp --dport 3000 -j DROP
-A DOCKER-USER -j RETURN
COMMIT

Unit systemd : /etc/systemd/system/docker-iptables-restore.service

[Unit]
Description=Restore Docker iptables DOCKER-USER chain
After=docker.service
BindsTo=docker.service

[Service]
Type=oneshot
ExecStart=/sbin/iptables-restore --noflush /etc/iptables/docker-user.rules
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Logique : DROP uniquement port 3000 (Dokploy UI). Autres ports Docker passent par DOCKER chain native. Si exposition admin custom (3001+), ajouter regle ACCEPT VPN+bastion + DROP par port dans le fichier .rules.

3. Fiches detaillees par serveur (10 hotes)¶

3.1 prod-dokploy-01 — 51.83.46.186¶

Hebergeur : OVH | OS : Debian 13 trixie | Docker : 29.x | Dokploy : v0.29.4

Role : Apps prod (portail.secivda.cloud, process.secivda.cloud, futur auth.secivda.cloud / remote.secivda.cloud post-SSO Foundation), services Coqworking (coqworking.fr, n8n.coqworking.fr, stats.coqworking.fr), cloud.addenda.fr.

Surface d'attaque externe :

Defenses en place : standards transverses §1 tous appliques. - UFW active : 80, 443 (anywhere), 2222+3000 (VPN+bastion), 21115-21119 RustDesk - DOCKER-USER chain + systemd docker-iptables-restore.service - fail2ban (jail SSH 2222, ignoreip VPN+bastion) - CrowdSec v1.4.6 (bouncer iptables) + collections linux/sshd/traefik/http-cve + ntfy - Lynis hebdo dimanche + AIDE quotidien + Docker Bench mensuel - unattended-upgrades + needrestart auto + healthcheck @reboot - Beszel agent WSS sortant vers bastion - Dozzle agent - restic backup Synology C2 + Kuma push monitor - Traefik v3.6.1 : api.insecure=false, HTTP/3, Let's Encrypt httpChallenge, healthcheck cron /5min - Docker daemon.json : live-restore=false (compat Swarm), no-new-privileges=true, log-driver json-file 50MB/3

Specifique : - Swap 4 Go sur /mnt/disk/swapfile, swappiness=10 - Audit securite : 8.5/10 (2026-02-10) — voir SECURITY_AUDIT_prod-dokploy-01.md - Futur SSO Foundation : ajout PG 17 + Redis 7 (en network bridge Docker, NE PAS exposer host)

Procedure MAJ securite : 1. Maintenance Kuma activee 2. apt update && apt upgrade (unattended fait deja critique) 3. Apres MAJ Docker : iptables -L DOCKER-USER -n doit montrer 4 regles + RETURN 4. Apres reboot : systemctl status docker-iptables-restore.service actif + Traefik UP + healthcheck post-reboot OK 5. Test acces Dokploy UI depuis VPN puis check-host.net depuis externe (port 3000 doit etre FILTERED) 6. Maintenance Kuma desactivee + log changement §8

3.2 prod-dokploy-02 — 51.83.46.172¶

Hebergeur : OVH | OS : Debian 13.3 trixie | Docker : 29.x | Dokploy : latest pinned

Role : Gitea (gitea.secivda.cloud) + 2 runners CI (DinD + Light, gitea-act-runner) + Documenso (signature.secivda.cloud) + audit.secivda.cloud + new.secivda.com staging.

Surface d'attaque externe :

Defenses en place : standards §1 + MFA TOTP admin Gitea + secret-scan deploye 30 repos + Renovate automerge.

Specifique : - Gitea compose : reseau external dokploy-network, routeur gitea explicite - Documenso : volume documenso-production_database, image pinnee au digest - Runners CI : DinD pour build images Docker SECIVDA + Light pour TS/Python - Webhook Dokploy → Gitea : flux interne (pas d'exposition supplementaire)

Sensible : compromission Gitea = compromission codes sources + workflows CI. Defense en profondeur. Restic backup critique + plan rollback Gitea documente.

Procedure MAJ : standards + verifier Gitea Actions runners UP + Documenso DB schema OK apres reboot.

3.3 prod-dokploy-03 — 135.125.205.34¶

Hebergeur : OVH | OS : Debian 13 | Docker : 29.x | Dokploy : v0.29.4

Role : Infisical master (secrets.secivda.cloud — SOURCE UNIQUE secrets flotte) + auth.secivda.cloud legacy (Guacamole — sera renommee remote.* post-P1 SSO Foundation) + moedcare + transfert.

Surface d'attaque externe : 80, 443, 2222, 3000. Pas d'autres ports publics.

Surface INTERNE : - Streaming WAL PostgreSQL 135.125.205.34 → 135.125.203.172:5432 (replica Infisical sur prod-05) - Acces SSH supplementaire depuis prod-05 (replication PG) — whitelist iptables

Defenses : standards §1 + Infisical TOTP MFA admin obligatoire + secrets chiffres at rest (AES-256 par Infisical).

Sensible : compromission = compromission TOUS les secrets flotte. Defense maximale : - 1Password vault SECIVDA = miroir des cles DR critiques (TOTP_ENC_KEY, OIDC_JWT_PRIVATE_KEY, COOKIE_SIGNING_KEYS, MAGIC_LINK_HASH_KEY) - MFA TOTP admin obligatoire + reviewer logs Infisical trimestriel - Replica prod-05 = lecture seule + DR - Backup restic chiffre + Synology C2 + Object Lock 90j

Architecture replication (resolue 2026-05-13) : - Tunnel SSH autossh depuis prod-05 (service systemd infisical-pg-tunnel.service) → cible 172.23.0.4:5432 (IP container PG master sur bridge infisical_infisical-internal) via 127.0.0.1:5433 - Cle dediee id_ed25519_replication sur prod-05, autorisee sur prod-03 /home/debian/.ssh/authorized_keys avec permitopen="172.23.0.4:5432",no-pty,no-X11-forwarding,no-agent-forwarding,command="/bin/false" - sshd /etc/ssh/sshd_config.d/99-hardening.conf : AllowTcpForwarding local (necessaire car no bloque meme avec permitopen) - Slot physique replica_prod05 sur master (evite purge WAL si replica disconnect) - Monitor cron 5 min agent-replication-monitor.sh sur master ET replica (alerte ntfy topic alertes)

Procedure MAJ : standards + JAMAIS toucher PG sans snapshot Infisical + plan rollback documente.

3.4 prod-dokploy-04 — 135.125.204.125¶

Hebergeur : OVH | OS : Debian 13 | Docker : 29.x | Dokploy : v0.29.4

Role : Dozzle hub (logs.secivda.cloud) + Backrest (backup.secivda.cloud) + Listmonk (newsletter.secivda.fr) + ChangeDetection + n8n + remote.secivda.cloud + Convert (convert.secivda.cloud) + canal-montauban + Zio-Ora on-demand.

Specificite vs autres : - PAS DE UFW (desinstalle infra#99 a cause Docker Swarm) - iptables direct + netfilter-persistent save obligatoire apres TOUT changement - Beszel agent en mode listen 45876 (legacy, non-WSS) — voir issue §7.2

Surface d'attaque externe :

Defenses : standards §1 + INPUT rules iptables saved via netfilter-persistent save.

Specifique : - Tout changement iptables → immediatement sudo netfilter-persistent save sinon perdu au reboot (feedback_iptables_persistence.md) - Kuma + Dozzle hub = critiques pour monitoring flotte - Backrest UI = dashboard restic Synology C2 (auth web) - Phase B planifiee : migration Dozzle hub vers bastion

Issue connue : Beszel listen 45876 a migrer vers WSS sortant comme tools-01 (ISO).

Procedure MAJ : 1. Maintenance Kuma activee 2. MAJ paquets/Docker/kernel 3. Apres reboot, controle : - iptables -L INPUT -n --line-numbers → ACCEPT VPN+bastion 45876/7007/2222 + DROP par defaut - iptables -L DOCKER-USER -n → ISO - systemctl status docker-iptables-restore actif - netfilter-persistent charge rules - Traefik + Kuma + Dozzle UP 4. Maintenance Kuma desactivee + log §8

3.5 prod-dokploy-05 — 135.125.203.172¶

Hebergeur : OVH | OS : Debian 13 | Docker : 29.x | Dokploy : v0.29.4

Role : NocoDB (source unique BDD flotte depuis 2026-02-07) + n8n.secivda.cloud + shlink (link.secivda.cloud) + Infisical postgres-replica + dokploy-postgres + n8n production + notifs (legacy purge 2026-05-10).

Specificite : PAS DE UFW (idem prod-04, Swarm). iptables direct + netfilter-persistent. Infisical replica en network_mode: host → expose 5432 sur IP host.

Surface d'attaque externe :

Defenses : standards §1 + INPUT iptables persistes + NocoDB MFA TOTP admin obligatoire.

Sensible : NocoDB = source unique BDD = compromission = perte data critique. Backup restic toutes les 6h + Object Lock 90j Synology C2.

Procedure MAJ : idem prod-04. Apres reboot verifier 5432 reste DROP par defaut depuis externe (check-host.net).

3.6 tools-dokploy-01 — 217.182.65.74 (NOUVEAU 2026-05-13)¶

Hebergeur : OVH | OS : Debian 13 | Docker : 29.4.3 | Dokploy : v0.29.4 | Reverse DNS : tools-dokploy-01.secivda.cloud OK

Role : DEV runtime (auth.dev. / portail.dev. / remote.dev. / process.dev.) + tools transverse (Loki, Unleash, GlitchTip, Plausible, Mailpit catch-all DEV, pgAdmin, MkDocs docs.secivda.cloud).

Surface d'attaque externe : standards 80, 443, 2222, 3000. Aucun autre port (Beszel = WSS sortant).

Defenses en place : standards transverses §1 tous appliques au bootstrap (TACHES/SSO-Foundation/BOOTSTRAP-LOG-tools-01.md) : - UFW active - DOCKER-USER ISO flotte (aligne 2026-05-13) - systemd docker-iptables-restore.service - fail2ban + ignoreip VPN+bastion - CrowdSec v1.7.x + bouncer iptables + collections + ntfy SECIVDA - unattended-upgrades + Origins-Pattern + Auto-Reboot=false - TZ Europe/Paris - restic + Synology C2 (bucket dedie + Object Lock 30j) - Beszel agent WSS sortant vers bastion (mode moderne) - Infisical client + secrets en boot uniquement - exim4 internet + mail [email protected] - post-reboot-healthcheck.sh @reboot + ntfy

Specifique : - 1Password : VPS tools-dokploy-01 (debian) + Backup - Synology C2 tools-dokploy-01 (restic, immutable 30j) - Mailpit DEV catch-all : aucun envoi reel depuis DEV apps - A faire (Phase L SSO Foundation) : enregistrer Kuma push monitor backup

Procedure MAJ : standards. Apres MAJ Docker, verifier DOCKER-USER ISO maintenu.

3.7 bastion-jotelulu (SRV-SECI02-001) — 149.71.44.170¶

Hebergeur : Jotelulu Paris PAR-FABRIC1 | OS : Debian 12 | Engine : Podman 4.3.1 (PAS Docker)

IP privee : 10.0.0.58/24. ACL Jotelulu : SSH 22 ouvert uniquement depuis VPN SECIVDA.

Role : Bastion SSH (IP secours admin) + Beszel hub (metrics.secivda.cloud) + ntfy (notifs.secivda.cloud) + Uptime Kuma (monitoring.secivda.cloud).

Specificite : Podman + Caddy + systemd (PAS Dokploy, PAS DOCKER-USER chain).

Surface d'attaque externe :

Defenses : standards adaptes Podman + Kuma MFA + Beszel MFA + ntfy auth tokens segmentes (publisher tokens specifiques par usage cf. infrastructure.md ligne 228-232).

Sensible : bastion = pivot critique. Si compromis = acces SSH a tous serveurs (depuis ACL Jotelulu). MFA obligatoire toutes UIs. Audit SECURITY_AUDIT_bastion-jotelulu.md.

Procedure MAJ : maintenance Kuma sur Kuma lui-meme. Beszel agents continueront a accumuler logs/metrics, recus a la reprise. ntfy reste UP (independance).

3.8 srv.secivda.com — 152.228.174.94 (+ 6 IPs additionnelles)¶

Hebergeur : OVH | OS : Debian 12 | Stack : Plesk Obsidian | SSH : 2222 user root (legacy, a migrer admin)

Role : Plesk pro (sites SECIVDA legacy non containerises, mail catch-all relayee vers mail.protton.fr).

Specificite : Plesk = stack legacy non containerisee. CrowdSec v1.7.6 (bouncer nftables) + fail2ban Plesk (coexistence) + AIDE + Lynis.

Surface d'attaque externe :

Defenses : - Plesk patched (CVE-2025-66430/66431 fix 2026-03-11) - CrowdSec v1.7.6 + collections linux/sshd/apache2/nginx/postfix/dovecot/mariadb/http-cve - fail2ban Plesk (avec ignoreip VPN) - AIDE quotidien (exclusions Plesk/vhosts) - Lynis hebdo - Records mail/webmail/imap/smtp en zone Plesk DNS (NE PAS sync CF cf. feedback_plesk_cf_mail_records.md) - DKIM/SPF/DMARC actifs - suexec link verifie post-dist-upgrade (psa-suexec)

Sensible : sites pros + mail. Surveillance Kuma + CrowdSec ntfy.

Procedure MAJ : plesk installer --select-product-id panel --show-components → update. Apres dist-upgrade : verifier readlink -f /usr/lib/apache2/suexec (psa-suexec) + Plesk panel UP + webmails 200.

3.9 srv.link.bzh — 141.94.71.70¶

Hebergeur : OVH | OS : Debian (migration 11→12 planifiee plesk-debian-migration.md) | Stack : Plesk Obsidian

Role : Plesk famille (5 domaines : gueritte.com, eloise.gueritte.com, mathilde-chesneau.com, olivier.gueritte.com, link.bzh).

Surface d'attaque : identique 3.8 (Plesk stack).

Defenses : standards Plesk §3.8. Patche CVE Plesk a jour.

Specifique : voir srv-link-bzh.md. Migration Debian 11→12 planifiee.

Procedure MAJ : idem 3.8.

3.10 mail.protton.fr — 51.91.77.100¶

Hebergeur : OVH | OS : Debian | Engine : Podman + Caddy + systemd

Role : Mailpit catch-all 5 domaines (fauxmail.fr, vraimail.fr, protton.fr, etc.) — capture emails sortants pour audit, pas de relai externe.

Specificite : firewall VPN-only sur 2222 → AUCUN serveur Dokploy ne peut SSH ici (pas de ProxyJump). Si ban fail2ban → console OVH ou attendre 1h. fail2ban ignoreip 130.180.220.25 A FAIRE (cf. infrastructure.md ligne 138).

Surface d'attaque externe :

Defenses : - CrowdSec v1.7.6 + collections linux/sshd/postfix/caddy + ntfy template - AIDE quotidien (exclusions Podman) - Lynis hebdo - Caddy TLS auto Let's Encrypt - exim4 internet mode (port 25 conflit Postfix mais envoie quand meme)

Specifique : Postfix v5.x boky/postfix init scripts dans /docker-init.d/ (cf. infrastructure.md ligne 276). Mailpit Podman compose specifique.

Procedure MAJ : podman stop X && podman rm X AVANT compose up (pas de --force-recreate Podman). Backup restic Synology C2.

4. Surface d'attaque externe consolidee¶

Tableau exhaustif des ports exposes a internet sur chaque serveur. Aucun autre port ne doit etre ouvert sans entree dans ce tableau + regle iptables/UFW + entree §3 + §8.

Legende : CF = Cloudflare proxied + Traefik anti-bypass | VPN+B = VPN 130.180.220.25 + bastion 149.71.44.170 | i = intra-Docker 172.16/12 | srv-com = 152.228.174.94

5. Procedures anti-derive¶

5.1 Avant tout changement securite¶

1. Ouvrir ce fichier
2. Identifier serveur cible (§3)
3. Verifier surface d'attaque actuelle (§4)
4. Activer maintenance Kuma (/usr/local/bin/kuma-maintenance.sh start <monitor-id>)
5. Documenter changement (Gitea issue idealement, labels security+infra)
6. Executer changement
7. Persister regles : ufw reload OU netfilter-persistent save (prod-04/05) OU iptables-save > /etc/iptables/rules.v4
8. Tester depuis externe (jamais depuis VPN) → check-host.net
9. Mettre a jour fiche §3 + tableau §4 + historique §8
10. Desactiver maintenance Kuma + fermer issue Gitea

5.2 Checklist post-MAJ paquets/kernel/Docker (a executer sur chaque serveur apres reboot)¶

ssh -p 2222 debian@<serveur>

# Standards SSH
sudo grep -E '^(Port|PasswordAuthentication|AllowUsers|PermitRootLogin)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf

# UFW (prod-01/02/03/tools-01)
sudo ufw status verbose

# iptables INPUT (prod-04/05)
sudo iptables -L INPUT -n --line-numbers

# DOCKER-USER chain (tous Dokploy)
sudo iptables -L DOCKER-USER -n

# systemd persistance
sudo systemctl status docker-iptables-restore.service
sudo systemctl status netfilter-persistent  # prod-04/05

# fail2ban
sudo fail2ban-client status sshd
sudo cat /etc/fail2ban/jail.d/ignoreip.conf

# CrowdSec
sudo cscli decisions list
sudo cscli bouncers list

# unattended-upgrades
sudo grep -E 'Unattended-Upgrade|Auto-Reboot' /etc/apt/apt.conf.d/50unattended-upgrades

# Services critiques
docker ps | grep -E 'traefik|dokploy'
systemctl status post-reboot-healthcheck

# TZ
timedatectl | grep 'Time zone'

Si DOCKER-USER vide apres reboot : bug systemd docker-iptables-restore.service (feedback_docker_user_persistence.md). sudo systemctl restart docker-iptables-restore.

Si iptables INPUT manque rules (prod-04/05) : sudo netfilter-persistent reload.

5.3 Tableau de bord verification (cocher apres action sensible)¶

6. Audits periodiques¶

6.1 Scan externe trimestriel (check-host.net depuis nodes NON-VPN)¶

Verifier que les ports suivants sont FILTERED (pas OPEN, pas CLOSED) : - 22, 23, 2222 (sauf 2222 depuis VPN/bastion) - 3000 (sauf VPN/bastion) - 5432 (sauf VPN/bastion/prod-03 → prod-05) - 6379, 7007, 45876 - 8080, 9090, 9100 (Prometheus metrics potentiels) - 2377, 7946, 4789 (Swarm) - 8443, 8447 (Plesk admin, sauf VPN/bastion) - Tous autres ports admin custom

Verifier que les ports suivants sont OPEN : - 80, 443/tcp, 443/udp (tous, sauf bastion qui n'a pas QUIC ?) - 25, 465, 587 (Plesk + mail) - 110, 143, 993, 995 (Plesk mail)

6.2 Re-audit ISO complet (annuel ou apres incident majeur)¶

Suivre audit_security_2026_05_11.md comme template + audit-template.md.

7. Systeme de controle automatique (anti-derive continu)¶

7.1 Script secivda-security-check.sh (a deployer flotte)¶

Objectif : controler automatiquement les 25 items §1 + DOCKER-USER pattern §2 + surface attaque §4. Alerter ntfy si derive detectee.

Deploiement : - Path : /usr/local/bin/secivda-security-check.sh sur tous serveurs - Owner : root:root mode 0750 - Cron : /etc/cron.d/secivda-security-check quotidien 04:30 local - Output : log /var/log/secivda-security-check.log + notification ntfy si derive (topic alertes)

Items controles par serveur :

# Pseudo-code du script (a developper en Phase suivante)
checks=(
  # SSH
  "sshd Port == 2222"
  "sshd PasswordAuthentication == no"
  "sshd PermitRootLogin == no"
  "sshd AllowUsers includes debian"
  "no listening on :22 (ss -tlnp)"

  # Firewall standards (selon serveur)
  "UFW active (prod-01/02/03/tools-01) OR netfilter-persistent active (prod-04/05)"
  "iptables -L DOCKER-USER -n contains 4 rules + RETURN (pattern ISO)"
  "systemctl is-active docker-iptables-restore.service"

  # fail2ban
  "systemctl is-active fail2ban"
  "fail2ban-client status sshd parses OK"
  "ignoreip contains 130.180.220.25 AND 149.71.44.170"

  # CrowdSec
  "systemctl is-active crowdsec"
  "cscli bouncers list contains iptables-bouncer (Dokploy) OR nftables-bouncer (Plesk/Mail)"
  "ntfy template name == 'secivda'"

  # OS hardening
  "timedatectl Time zone == Europe/Paris"
  "needrestart restart auto config present"
  "unattended-upgrades enabled + Auto-Reboot=false (Dokploy) ou OK"
  "post-reboot-healthcheck.sh exists + @reboot cron present"

  # Backup
  "restic latest snapshot < 12h ago"
  "restic check OK (every 7 days)"

  # Monitoring
  "beszel-agent service active (WSS or listen)"
  "dozzle agent active (Dokploy non-hub)"

  # Surface attaque (selon serveur)
  "ss -tlnp listening ports == expected set per server"
  "check-host.net last scan results match §4 (cache 24h)"
)

Output normal : aucune notification.

Output derive : ntfy notification topic alertes priority 5 :

[secivda-security] DERIVE detectee sur <serveur>
- <item> : expected <X>, got <Y>
- <item> : ...
Action requise : consulter securite-flotte-reference.md §3.<serveur>

7.2 Controle replication Infisical PG (post-resolution issue §3.3)¶

Objectif : monitorer en continu la replication WAL streaming prod-03 → prod-05.

Sur prod-03 (master) :

SELECT
  client_addr,
  state,
  sync_state,
  EXTRACT(EPOCH FROM (now() - reply_time)) AS lag_seconds,
  pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication;

Sur prod-05 (replica) :

SELECT
  status,
  sender_host,
  sender_port,
  conninfo,
  received_lsn,
  EXTRACT(EPOCH FROM (now() - last_msg_receipt_time)) AS last_msg_age_seconds
FROM pg_stat_wal_receiver;

Implementation : - Script /usr/local/bin/infisical-replication-check.sh sur prod-05 - Cron 5 minutes - Alerte ntfy si : - pg_stat_wal_receiver vide (replication arretee) - last_msg_age_seconds > 60 - replay_lag_bytes > 100 MB - Heartbeat Kuma push monitor type "Push" toutes les 5 min

Test fonctionnel hebdomadaire : - INSERT test row sur master Infisical → verifier presence sur replica < 30s - Si fail → alerte + ouvrir issue Gitea infra automatiquement

7.3 Resolution Infisical replication (2026-05-13) — RESOLU¶

Diagnostic final (5 root causes empilees) :

1. IP volatile du PG master container : 172.23.0.2 → 172.23.0.4 apres redemarrage du container (incident 2026-05-10). Le tunnel SSH cible une IP obsolete.
2. Service systemd infisical-pg-tunnel.service IP hardcodee : -L 5433:172.23.0.2:5432.
3. authorized_keys mal formee sur prod-03 : restrict,port-forwarding,... mais port-forwarding n'est PAS une option SSH valide. restrict reste actif et bloque tout forward.
4. sshd_config.d/99-hardening.conf : AllowTcpForwarding no est un kill-switch absolu, les options authorized_keys ne peuvent QUE restreindre (pas etendre).
5. Slot de replication INEXISTANT : sans slot, master purge les WAL apres 3 jours d'absence du replica → "WAL segment has already been removed".
6. Bonus : crontab agent-replication-monitor.sh configuree pour user debian qui n'a PAS acces docker.sock → script echouait silencieusement depuis le debut. Aucune alerte ntfy emise.

Fix applique 2026-05-13 :

1. ✓ Service systemd : sed IP 172.23.0.2 → 172.23.0.4 + reload + restart
2. ✓ authorized_keys prod-03 : remplace restrict,port-forwarding,command="/bin/false" par permitopen="172.23.0.4:5432",no-pty,no-X11-forwarding,no-agent-forwarding,command="/bin/false"
3. ✓ sshd_config.d/99-hardening.conf : AllowTcpForwarding no → local + sshd -t + systemctl reload ssh
4. ✓ Slot physique cree sur master : SELECT pg_create_physical_replication_slot('replica_prod05');
5. ✓ Stop container replica + mv data dir vers .bak-YYYYMMDD-HHMMSS (90M sauvegarde)
6. ✓ pg_basebackup via container temp postgres:16-alpine + --network host + -h 127.0.0.1 -p 5433 -X stream -P -R -S replica_prod05 → 83.7 MB transferes
7. ✓ Start container replica → entre en standby + streaming actif (status=streaming, last_msg_age 9-12s)
8. ✓ Test fonctionnel : INSERT sur master replique sur replica en < 3 s
9. ✓ Crontab infisical-*.sh migrees debian → root sur prod-03 ET prod-05 (fix bug detection automatique)

Verification finale : - Master pg_stat_replication : replicator | 172.23.0.1 | walreceiver | streaming | async | reply_age 3s | replay_lag 0 bytes - Replica pg_stat_wal_receiver : streaming | 127.0.0.1 | 5433 | last_msg_age 9s - Slot replica_prod05 : active=t, restart_lsn=0/2A000060 - Monitor cron : [2026-05-13 11:22:01] OK: Streaming actif (derniere transaction replay il y a 53s)

Dette technique restante : - ~~L'IP 172.23.0.4 reste volatile~~ ✓ RESOLU 2026-05-13 (Option A appliquee) : - /opt/infisical/compose.yaml : network infisical-internal declare explicitement ipam.config: - subnet: 172.23.0.0/16, gateway: 172.23.0.1 - Service postgres : networks.infisical-internal.ipv4_address: 172.23.0.4 - Backup compose : /opt/infisical/compose.yaml.bak.20260513-112732 - Recreate via docker compose up -d (recreate network + 3 containers) : downtime <30s - Replication validee post-recreate : pg_stat_wal_receiver.status=streaming, slot replica_prod05 actif (restart_lsn avance), INSERT/SELECT test (_replication_check id=2) replique en <3s - Au prochain redemarrage container PG master, l'IP reste 172.23.0.4 → permitopen authorized_keys + tunnel SSH restent valides definitivement - Nettoyer /var/lib/docker/volumes/infisical_postgres-replica-data/_data.bak-* apres validation 7 jours (90M) - DROP table _replication_check apres usage (ou la garder comme heartbeat fonctionnel pour §7.2 monitor)

Lecons retenues (a integrer dans §1 standards transverses + §7.1) : - Tout crontab d'agent monitoring DOIT tourner en root (ou groupe docker), sinon docker ps echoue silencieusement - Tout script monitor qui peut echouer silencieusement DOIT envoyer un heartbeat positif a Kuma (push monitor) pour detecter l'absence de retour - Toute connexion replication PG DOIT utiliser un slot physique (sinon WAL purge = re-basebackup obligatoire apres downtime) - IP volatile container Docker = anti-pattern pour services critiques. Toujours fixer IP statique OU passer par DNS docker via sidecar

7.4 Dashboard centralise (Phase ulterieure)¶

A terme, integration des controles §7.1 + §7.2 dans : - Kuma : push monitors par serveur + service - Beszel : dashboards custom metrics - MkDocs docs.secivda.cloud : copie automatique de ce doc + status temps reel

8. Historique des changements securite¶

9. Issues connues a tracker¶

10. Liens memoires reference¶

11. Maintenance ce document¶

• Maj obligatoire apres : tout nouveau serveur, toute regle firewall, toute exposition de port, toute modification SSH, toute MAJ securite majeure, tout incident, tout fix issue §9.
• Format : ligne §8 (historique) + maj fiche serveur §3 + maj tableau §4 + items §1 si applicable.
• Propagation : copier dans docs.secivda.cloud (P0bis MkDocs) une fois deploye, pour visibilite collab.
• Reviewer : agent security-iso en lecture systematique avant toute action sensible. Hook potentiel : pre-action securite → bloque si fichier non lu dans la session.
• Versioning : ce doc est en memory persistante Claude Code (/Users/jeff/.claude/projects/-Users-jeff-CLAUDE/memory/securite-flotte-reference.md).