c0oki3s/veilgateDifesa asimmetrica contro agenti AI avversari. VeilGate valuta ogni richiesta in arrivo, reindirizza gli agenti sospetti in un ambiente honeypot coerente per IP e quantifica il costo computazionale imposto all'attaccante.
VeilGate è un proxy di decoy open-source per team che vogliono aumentare il costo delle sonde di sicurezza automatizzate senza mettere fragili regole di blocco davanti agli utenti reali.
Si colloca davanti a un'applicazione web, valuta ogni richiesta e sceglie uno di tre esiti:
L'obiettivo non è un'invulnerabilità magica. L'obiettivo è un'economia migliore: tenere in movimento gli umani e l'automazione normale, mentre si fa sì che gli scanner assistiti da IA spendano tempo, token e attenzione su vicoli ciechi credibili.
observe, challenge, tarpit e auto guidata da soglie.X-Veilgate-TokenfetchXHRScarica il binario, installa un servizio systemd, installa le regole comunitarie e scrive una configurazione iniziale in modalità observe.
# One-liner
curl -sSL https://veilgate.dev/install.sh | sudo bash -s -- --upstream http://localhost:3000
# Or download first, then run
curl -sSL https://veilgate.dev/install.sh -o install.sh
sudo ./install.sh --upstream http://localhost:3000
Opzioni:
| Flag | Default | Descrizione |
|---|---|---|
--upstream URL | http://127.0.0.1:3000 | La tua applicazione a monte |
--listen ADDR | :8080 | Indirizzo di ascolto del proxy |
--metrics-listen ADDR | 127.0.0.1:9090 | Metriche (tenere private) |
--secret SECRET | richiesto o generato | Segreto per la firma della sfida |
--user USER | veilgate | Utente di servizio con cui eseguire VeilGate |
--no-service | — | Salta il servizio systemd |
--no-rules | — | Salta l'installazione delle regole comunitarie |
La configurazione inclusa usa rules_dir: "~/.veilgate/rules". Con systemd, VeilGate gira come utente veilgate la cui home è /var/lib/veilgate, quindi il percorso risolve in /var/lib/veilgate/.veilgate/rules.
Se --secret viene omesso in una nuova installazione, l'installer chiede il valore sui terminali interattivi e altrimenti genera un segreto casuale. Se l'utente di servizio non esiste, l'installer chiede prima di crearlo sui terminali interattivi e per impostazione predefinita lo crea nelle installazioni non interattive.
Dopo l'installazione:
systemctl status veilgate
journalctl -u veilgate -f
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
Prerequisito: Go 1.25.10 o successivo.
git clone https://github.com/C0oki3s/veilgate.git
cd veilgate
make build
./veilgate -config configs/veilgate.yaml
Di default VeilGate ascolta su :8080, fa da proxy verso http://localhost:3000 ed espone le metriche su :9090.
La configurazione predefinita parte in modalità observe: registra il traffico normale di base prima di abilitare challenge o tarpit.
| Modalità | Usala quando | Comportamento |
|---|---|---|
observe | Prima implementazione e ottimizzazione | Valuta e registra il traffico, inoltra sempre a monte |
challenge | Sei a tuo agio nell'interrompere i client sospetti | Il traffico con punteggio medio riceve una proof of work |
tarpit | Sei pronto a ingannare gli agenti ad alta confidenza | Il traffico con punteggio alto riceve l'app finta |
auto | Vuoi che le soglie guidino l'applicazione per ogni richiesta | Inoltra sotto la soglia, sfida i punteggi medi, tarpit i punteggi alti |
Implementazione consigliata:
observe per almeno diversi giorni.challenge per il traffico ambiguo.tarpit quando le soglie corrispondono al tuo ambiente.Inizia con 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"
Riferimento completo: Riferimento alla configurazione.
VeilGate non include nessuna regola incorporata. Il binario legge rules_dir all'avvio e ricarica a caldo le modifiche; se la directory è vuota, parte senza segnali di rilevamento. Le regole arrivano da un unico posto:
install.sh lo clona automaticamente alla prima installazione. Puoi anche aggiornarlo manualmente con il sottocomando update-rules integrato: nessuna ricompilazione, nessun riavvio:| Installa le regole automaticamente? | |
|---|---|
install.sh (prima esecuzione) | Sì — clona tramite git |
binario veilgate (avvio) | No — legge rules_dir, non recupera mai |
veilgate update-rules | Solo quando lo chiami esplicitamente |
# Install the latest pack into ~/.veilgate/rules (the default location)
veilgate update-rules
# Or pin to a release tag
veilgate update-rules --dir ~/.veilgate/rules --version v1.2.0
# List available releases
veilgate update-rules --list
Dopo l'installazione, il watcher fsnotify di VeilGate rileva i nuovi file entro ~500 ms. Ogni file esistente viene salvato come <name>.bak prima di essere sovrascritto (passa --no-backup per saltare). La versione installata viene registrata in <rules_dir>/.rules-version.json, così CI e operatori possono verificare cosa è in esecuzione senza consultare i metadati git.
Tratta entrambe le directory come policy di sicurezza: verifica le modifiche prima di distribuirle in produzione, in particolare detector.yaml e ip_reputation.yaml. Guida completa e procedura di rollback: docs/how-to/install-community-rules.md.
veilgate.yaml e file di regole.veilgate update-rules.VEILGATE_SECRET o challenge.secret prima di usare la modalità challenge o tarpit. VeilGate rifiuta di avviarsi al di fuori della modalità observe con il segreto di sfida predefinito.rules/ come policy di sicurezza. Verificali e versionali.make test
make fmt
make build
La cartella tests di primo livello contiene test di integrazione black-box. Gli unit test privati dei pacchetti vivono accanto ai loro pacchetti perché verificano helper non esportati per detector, impronte TLS, tarpit e ML.
Apache-2.0. Vedi LICENSE.