VeilGate

VeilGate est un proxy de déception open-source pour les équipes qui souhaitent augmenter le coût des sondages de sécurité automatisés sans placer de règles de blocage fragiles devant les utilisateurs réels.

Il se place devant une application web, évalue chaque requête et choisit l'une des trois issues suivantes :

Réel : transmettre le trafic propre à l'application en amont.
Défi : demander aux clients suspects mais ambigus de résoudre une preuve de travail dans le navigateur.
Piège (tarpit) : rediriger le trafic d'agents à haute confiance vers une application factice déterministe.

L'objectif n'est pas une invulnérabilité magique. L'objectif est une meilleure économie : laisser les humains et l'automatisation normale continuer, tout en faisant en sorte que les scanners assistés par IA perdent du temps, des jetons et de l'attention sur des impasses crédibles.

Ce qu'il fait

Proxy inverse avec modes observe, challenge, tarpit et auto piloté par seuil.
Signaux de détection pour les agents utilisateurs suspects, les en-têtes de navigateur incomplets, les chemins honeypot, la régularité temporelle, les chemins de scanner, les marqueurs SQLi/XSS/OOB, la rotation IP/UA, le comportement des cookies, la forme du graphe de requêtes, les empreintes TLS JA3/JA4, les empreintes HTTP/2, la relecture de leurres et le scoring ML en ligne.
Défi de preuve de travail dans le navigateur avec transports cookie et en-tête X-Veilgate-Token afin que les SPA cross-origin puissent résoudre et rattacher le jeton lors des appels API ultérieurs. La réponse 401 au défi est compatible SPA : elle renvoie du HTML pour les navigations de niveau supérieur et du JSON (avec les métadonnées PoW à résoudre en ligne) pour les contextes fetch / XHR.
Chaîne de vérificateur HMAC délivré par l'opérateur pour les clients serveur-à-serveur qui ne peuvent pas résoudre le PoW (voir docs/how-to/server-to-server-hmac.md).
Réponses d'application fantôme avec des profils clients factices stables.
Injection de prompt et injection de leurres factices dans les réponses du tarpit.
Persistance SQLite pour les événements, les cumuls de caractéristiques, les journaux d'audit et les leurres.
Métriques Prometheus et un tableau de bord léger sur l'écouteur de métriques.
Fichiers de règles YAML rechargeables à chaud, alimentés par le dépôt communautaire séparé veilgate-rules.

Démarrage rapide

Option 1 — Script d'installation (recommandé)

Télécharge le binaire, installe un service systemd, installe les règles communautaires et écrit une configuration de démarrage en mode observe.

# En une ligne
curl -sSL https://veilgate.dev/install.sh | sudo bash -s -- --upstream http://localhost:3000

# Ou téléchargez d'abord, puis exécutez
curl -sSL https://veilgate.dev/install.sh -o install.sh
sudo ./install.sh --upstream http://localhost:3000

Drapeaux :

Drapeau	Défaut	Description
`--upstream URL`	`http://127.0.0.1:3000`	Votre application en amont
`--listen ADDR`	`:8080`	Adresse d'écoute du proxy
`--metrics-listen ADDR`	`127.0.0.1:9090`	Métriques (garder privé)
`--secret SECRET`	invite ou généré	Secret de signature des défis
`--user USER`	`veilgate`	Utilisateur système pour exécuter VeilGate
`--no-service`	—	Ignorer le service systemd
`--no-rules`	—	Ignorer l'installation des règles communautaires

La configuration fournie utilise rules_dir: "~/.veilgate/rules". Sous systemd, VeilGate s'exécute en tant qu'utilisateur veilgate dont le répertoire personnel est /var/lib/veilgate, donc cela se résout en /var/lib/veilgate/.veilgate/rules.

Si --secret est omis lors d'une nouvelle installation, le programme d'installation invite sur les terminaux interactifs et génère sinon un secret aléatoire. Si l'utilisateur système n'existe pas, le programme d'installation demande avant de le créer sur les terminaux interactifs et par défaut le crée pour les installations non interactives.

Après l'installation :

systemctl status veilgate
journalctl -u veilgate -f

Option 2 — Docker

docker run -d --name veilgate \
  --network host \
  -v /etc/veilgate/veilgate.yaml:/etc/veilgate/veilgate.yaml:ro \
  -v ~/.veilgate/rules:/home/nonroot/.veilgate/rules \
  -e VEILGATE_SECRET=$(openssl rand -hex 32) \
  ghcr.io/c0oki3s/veilgate:latest -config /etc/veilgate/veilgate.yaml

Option 3 — Compiler à partir des sources

Prérequis : Go 1.25.10 ou plus récent.

git clone https://github.com/C0oki3s/veilgate.git
cd veilgate
make build
./veilgate -config configs/veilgate.yaml

Par défaut, VeilGate écoute sur :8080, proxy vers http://localhost:3000 et expose les métriques sur :9090.

La configuration par défaut démarre en mode observe — observer le trafic normal avant d'activer challenge ou tarpit.

Modes de fonctionnement

Mode	Quand l'utiliser	Comportement
`observe`	Déploiement initial et réglage	Note et enregistre le trafic, transmet toujours en amont
`challenge`	Vous êtes à l'aise pour interrompre les clients suspects	Le trafic de score moyen reçoit une preuve de travail
`tarpit`	Vous êtes prêt à tromper les agents à haute confiance	Le trafic de score élevé reçoit l'application factice
`auto`	Vous voulez que les seuils pilotent l'application par requête	Transmettre en dessous du seuil, défier les scores moyens, piéger les scores élevés

Déploiement recommandé :

Exécutez observe pendant au moins plusieurs jours.
Examinez les métriques et les échantillons d'événements pour les faux positifs.
Activez challenge pour le trafic ambigu.
Activez tarpit une fois que vos seuils correspondent à votre environnement.

Configuration

Commencez par configs/veilgate.yaml :

listen: ":8080"
upstream: "http://localhost:3000"
mode: "observe"
rules_dir: "~/.veilgate/rules"

detector:
  score_challenge_threshold: 40
  score_tarpit_threshold: 70
  trusted_ips: []
  trusted_proxies: []

metrics:
  listen: ":9090"

Référence complète : Référence de configuration.

Règles

VeilGate n'embarque aucune règle. Le binaire lit rules_dir au démarrage et recharge les modifications à chaud ; si le répertoire est vide, il démarre sans aucun signal de détection. Les règles proviennent d'un seul endroit :

veilgate-rules — le pack de règles maintenu par la communauté. Le script install.sh le clone automatiquement lors de la première installation. Vous pouvez également le mettre à jour manuellement avec la sous-commande intégrée update-rules — sans reconstruction, sans redémarrage :

	Installe les règles automatiquement ?
`install.sh` (première exécution)	Oui — clone via git
Binaire `veilgate` (démarrage)	Non — lit `rules_dir`, ne télécharge jamais
`veilgate update-rules`	Seulement lorsque vous l'appelez explicitement

# Installe le dernier pack dans ~/.veilgate/rules (emplacement par défaut)
veilgate update-rules

# Ou épinglez à un tag de version
veilgate update-rules --dir ~/.veilgate/rules --version v1.2.0

# Liste les versions disponibles
veilgate update-rules --list

veilgate

Populaires