docs: pattern IP sessions Claude-User mcp-vps/mcp-nas + incident exposition tokens Gitea

This commit is contained in:
bolbol 2026-07-12 08:01:13 +00:00
parent 7ae2c4c510
commit 81ee26443a
1 changed files with 45 additions and 0 deletions

View File

@ -0,0 +1,45 @@
# Pattern IP sessions MCP (mcp-vps / mcp-nas) — Claude-User
**Date** : 12/07/2026
**Sphère** : common (transverse aux 3 instances)
## Contexte
Alerte remontée par Nabil : nouvelles sessions MCP inhabituelles vues dans les logs
(`mcp-vps` audit.log, connexions SSH Best0f sur le NAS).
## Constat
- `mcp-vps` (serveur MCP sur Contabo, `/data/audit.log`) : chaque appel d'outil MCP
ouvre un **nouveau transport HTTP** (`NEW_SESSION`). Anthropic fait tourner l'IP
de sortie sur une petite plage dynamique — observé : **160.79.106.34 à .39**,
toutes taguées `ua=Claude-User`. C'est le comportement normal de l'infra Claude
côté exécution d'outils, **pas une IP fixe par session/utilisateur**.
- Connexions SSH NAS sous le compte **Best0f** (clé `mcp-nas-bestof`, container
mcp-nas) : normales, c'est l'identité utilisée par Claude via mcp-nas — à ne
pas confondre avec les comptes applicatifs hermes-nyora / hermes-perso.
- Une IP hors plage (`102.158.232.77`, `ua=curl/8.7.1`) correspondait à un test
manuel de Nabil (curl direct depuis son réseau).
## Conclusion
Aucune intrusion. Pattern à connaître pour éviter une fausse alerte future :
- `ua=Claude-User` + IP dans la plage `160.79.106.32/28` (à affiner si de
nouvelles IP apparaissent) = trafic Claude légitime (tool calling).
- SSH Best0f depuis mcp-nas = Claude, pas un agent Hermes.
## Incident lié (à part) — exposition tokens Gitea
Lors de cette investigation (12/07/2026), une commande mal construite (sed de
redaction insuffisant) a affiché en clair dans une conversation Claude les
valeurs de `GITEA_TOKEN_TT`, `GITEA_TOKEN_NYORA`, `GITEA_TOKEN_PERSO`
(`GITEA_DEPLOY_TOKEN` partiellement masqué).
**Action requise** : rotation des 4 tokens Gitea ci-dessus, à ajouter à la
liste de rotation `2L2u519w*` en cours suite à l'incident du 0712/07/2026.
**Leçon** : ne jamais faire confiance à un pipe `sed` de redaction non testé
avant affichage — toujours valider le masquage sur une valeur factice d'abord,
ou mieux, ne jamais imprimer un fichier `.env` complet même redacté : cibler
uniquement les noms de variables, ou consommer la valeur côté serveur (dans
la commande SSH elle-même) sans jamais la faire remonter dans la sortie.