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 :

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

Déploiement recommandé :

1. Exécutez observe pendant au moins plusieurs jours.
2. Examinez les métriques et les échantillons d'événements pour les faux positifs.
3. Activez challenge pour le trafic ambigu.
4. 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 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

Après l'installation, le watcher fsnotify de VeilGate détecte les nouveaux fichiers en environ 500 ms. Chaque fichier existant est sauvegardé sous <name>.bak avant d'être remplacé (passez --no-backup pour ignorer). La version installée est enregistrée dans <rules_dir>/.rules-version.json afin que les CI et les opérateurs puissent vérifier ce qui est exécuté sans consulter les métadonnées git.

Traitez les deux répertoires comme une politique de sécurité — examinez les modifications avant de les déployer en production, en particulier detector.yaml et ip_reputation.yaml. Guide complet et procédure de restauration : docs/how-to/install-community-rules.md.

Documentation

• Premiers pas : exécution locale et premières vérifications.
• Référence de configuration : veilgate.yaml et fichiers de règles.
• Déploiement : installation Linux/systemd.
• Architecture : flux de requêtes et conception des sous-systèmes.
• Opérations : métriques, tableaux de bord, alertes, vérifications de routine.
• Fiche technique du modèle : comportement et limites du signal ML.
• Index de référence : pages de référence complètes orientées consultation.
• Règles communautaires : installer et mettre à jour les ensembles de règles maintenus par la communauté via veilgate update-rules.
• Modèle de menace : ce que VeilGate protège et ne protège pas.

Notes de sécurité

• Déployez VeilGate uniquement devant des systèmes que vous possédez ou exploitez.
• N'exposez pas l'écouteur de métriques directement sur Internet public.
• Définissez VEILGATE_SECRET ou challenge.secret avant d'utiliser les modes challenge ou tarpit. VeilGate refuse de démarrer en dehors du mode observe avec le secret de défi par défaut.
• Traitez les fichiers sous rules/ comme une politique de sécurité. Examinez-les et versionnez-les.
• Commencez avec des seuils prudents et ajustez-les en fonction du trafic observé.

Développement

make test
make fmt
make build

Le dossier tests de premier niveau contient des tests d'intégration boîte noire. Les tests unitaires privés aux packages se trouvent à côté de leurs packages car ils vérifient des helpers de détection, d'empreinte TLS, de tarpit et de ML non exportés.

Licence

Apache-2.0. Voir LICENSE.