bolbol
/
nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
nas-runbooks/common/mcp-sessions-pattern.md

2.2 KiB
Raw Blame History

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 07–12/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.