**Motivations:** - Export Signet and mining wallet backups to git with only 2 versions kept - Document and add backup/restore scripts for signet and mining wallet **Correctifs:** - Backup-to-git uses SSH URL for passwordless cron; copy timestamped files only; prune to 2 versions; remove *-latest from backup repo **Evolutions:** - data/backup-to-git-cron.sh: daily export to git.4nkweb.com/4nk/backup - save-signet-datadir-backup.sh, restore-signet-from-backup.sh, export-mining-wallet.sh, import-mining-wallet.sh - features/backup-to-git-daily-cron.md, docs/MAINTENANCE.md backup section - .gitignore: data/backup-to-git.log **Pages affectées:** - .gitignore, data/backup-to-git-cron.sh, docs/MAINTENANCE.md, features/backup-to-git-daily-cron.md - save-signet-datadir-backup.sh, restore-signet-from-backup.sh, export-mining-wallet.sh, import-mining-wallet.sh - Plus autres fichiers modifiés ou non suivis déjà présents dans le working tree
61 lines
3.6 KiB
Markdown
61 lines
3.6 KiB
Markdown
# Écoute des services : IPv4 uniquement, flux reçus du proxy 192.168.1.100
|
||
|
||
**Auteur** : Équipe 4NK
|
||
**Date** : 2026-02-02
|
||
**Version** : 1.0
|
||
|
||
## Objectif
|
||
|
||
Les services backend (APIs, dashboard, etc.) doivent :
|
||
|
||
1. **Écouter en IPv4 uniquement** : aucune écoute sur IPv6 (`[::]`).
|
||
2. **Accepter les flux reçus de la machine proxy uniquement** : les connexions entrantes doivent provenir du proxy (192.168.1.100).
|
||
|
||
## Impacts
|
||
|
||
- **Sécurité** : réduction de la surface d’exposition (pas d’IPv6, pas d’accès direct depuis d’autres machines que le proxy).
|
||
- **Cohérence** : tous les accès passent par le proxy (HTTPS, certificats, routage).
|
||
- **Environnements concernés** : machine bitcoin (192.168.1.105), machine prod (192.168.1.103), et tout backend recevant du trafic du proxy.
|
||
|
||
## Règles d’écoute
|
||
|
||
### 1. Bind sur l’adresse IPv4 de la machine
|
||
|
||
Chaque service écoute sur l’adresse LAN IPv4 de la machine où il tourne, et non sur `0.0.0.0` :
|
||
|
||
- **Machine bitcoin (192.168.1.105)** : `DASHBOARD_HOST=192.168.1.105`, `API_HOST=192.168.1.105` (dashboard, api-anchorage, etc.).
|
||
- **Machine prod (192.168.1.103)** : `FAUCET_API_HOST=192.168.1.103`, `WATERMARK_API_HOST=192.168.1.103`, `CLAMAV_API_HOST=192.168.1.103`, etc.
|
||
|
||
Cela garantit une écoute IPv4 uniquement (pas d’écoute sur `[::]`).
|
||
|
||
### 2. Restriction à la source proxy (192.168.1.100)
|
||
|
||
Si la variable d’environnement `ALLOWED_SOURCE_IP=192.168.1.100` est définie, le service rejette toute requête dont l’adresse source (après normalisation IPv6-mapped → IPv4) n’est pas 192.168.1.100.
|
||
|
||
- **Middleware** : chaque service applicatif (Node/Express) peut utiliser un middleware qui lit `req.socket.remoteAddress`, normalise (ex. `::ffff:192.168.1.100` → `192.168.1.100`) et compare à `ALLOWED_SOURCE_IP`. Si différent, réponse 403.
|
||
- **Alternative** : firewall sur chaque machine (autoriser uniquement 192.168.1.100 sur les ports des services). À documenter côté infra.
|
||
|
||
## Modifications
|
||
|
||
- **Fichiers de service systemd** : `DASHBOARD_HOST`, `API_HOST`, `FAUCET_API_HOST`, `WATERMARK_API_HOST`, `CLAMAV_API_HOST` définis à l’IP LAN de la machine ; `ALLOWED_SOURCE_IP=192.168.1.100` ajouté.
|
||
- **Code** : middleware optionnel (activé si `ALLOWED_SOURCE_IP` est défini) dans signet-dashboard, api-anchorage, api-faucet, api-filigrane, api-clamav pour rejeter les requêtes dont la source n’est pas le proxy.
|
||
- **Documentation** : `docs/ENVIRONMENT.md`, `docs/DOMAINS_AND_PORTS.md` mis à jour pour décrire cette règle et les variables.
|
||
|
||
## Nginx / Mempool
|
||
|
||
- **Mempool** : si un Nginx local expose le frontend (ex. port 3015), les directives `listen` doivent être en IPv4 uniquement (ex. `listen 192.168.1.105:3015;` ou `listen 0.0.0.0:3015;` sans `listen [::]:3015`).
|
||
- **Proxy (192.168.1.100)** : inchangé ; c’est lui qui envoie les flux vers les backends.
|
||
|
||
## Modalités de déploiement
|
||
|
||
1. Mettre à jour les fichiers `.service` avec les bonnes valeurs `*_HOST` et `ALLOWED_SOURCE_IP=192.168.1.100`.
|
||
2. Redémarrer les services après déploiement des unités systemd.
|
||
3. Vérifier que le proxy peut joindre les backends (192.168.1.105 et 192.168.1.103) sur les ports concernés.
|
||
4. Ne pas définir `ALLOWED_SOURCE_IP` en dev local si les requêtes ne viennent pas du proxy.
|
||
|
||
## Modalités d’analyse
|
||
|
||
- Vérifier qu’aucun service n’écoute sur `[::]` : `ss -tlnp` / `netstat -tlnp` sur chaque machine.
|
||
- Vérifier que les services écoutent sur l’IP LAN attendue : `ss -tlnp | grep <port>`.
|
||
- Tester depuis le proxy : `curl http://192.168.1.105:3020/...` et depuis une autre machine : doit être refusé si firewall ou middleware est actif.
|