InfraFenceInfraFence

Live Security Operations

Inizia

Cosa legge l'agente, e cosa invia

Ultimo aggiornamento:

Un agente di sicurezza gira come root sui tuoi server: devi sapere esattamente cosa fa con quell'accesso. Questa pagina elenca cosa legge l'agente InfraFence, cosa modifica, cosa invia alla dashboard e cosa succede quando la dashboard non risponde o lo rifiuta.

Non devi fidarti sulla parola: il codice dell'agente è pubblico su GitHub e ogni release si può verificare con la sua firma.

Perché serve root

L'agente gestisce il firewall (iptables e ipset), legge i log e lo stato di rete del sistema e applica le correzioni che chiedi. Tutto questo richiede root. È un unico binario Go statico, senza dipendenze, che gira come servizio e puoi fermare in qualsiasi momento.

Le sue regole di firewall stanno in catene proprie, chiamate INFRAFENCE. Non modifica mai le tue regole e non aggiunge mai una regola di accept sua: le uniche regole di accept sono quelle che crei tu dalla dashboard. Quando un altro strumento ricarica il firewall (csf -r, un reload di ufw o firewalld, iptables-restore), l'agente rimette al loro posto le sue catene.

Cosa legge, e perché

CosaPerché
Il log di autenticazione SSH (journal di systemd, /var/log/auth.log o /var/log/secure)Brute force SSH e rischio delle sessioni
I log di accesso del web server e l'audit log di ModSecurityWeb firewall e bot
I log di posta, database e FTPBrute force su quei servizi
I pacchetti DNS (porta UDP 53, in sola lettura) e le tabelle delle connessioni in /procMinacce in uscita e DNS, scansioni di porte
I file dei siti, compresi .env e i file di configurazioneScansione malware e controlli sui framework
Articoli, opzioni e utenti di WordPress, con le credenziali di wp-config.phpScansione del database WordPress
I processi in esecuzioneCrypto miner e reverse shell
I file di sistema sorvegliati (account, sudoers, chiavi SSH, cron, unità systemd)Integrità dei file
I pacchetti installati e le loro versioniVulnerabilità (CVE)
Il socket di Docker, in sola lettura, se Docker c'èLog e porte dei container

Leggere un file non vuol dire inviarlo. Tutto ciò che è in questa tabella viene analizzato sul server; la sezione seguente elenca cosa ne esce.

Cosa modifica

  • Le sue catene di firewall e i suoi ipset: ban, lista consentiti, blocchi per paese, porte chiuse.
  • Solo se attivi Consenti modifiche alla configurazione del web server: le sue regole ModSecurity e il blocco degli user agent in nginx o Apache. Non modifica mai una configurazione gestita da un pannello di hosting.
  • Solo quando lo chiedi tu, AutoMode o la modalità di emergenza: correzioni di hardening, porte chiuse, blocchi in uscita, patch virtuali, aggiornamenti di sicurezza e file in quarantena.

Ogni modifica viene verificata subito dopo e annullata se SSH o un sito smettono di rispondere. La modalità monitor rileva tutto e non blocca niente, e un solo comando disinstalla l'agente e tutto ciò che ha aggiunto.

Cosa invia alla dashboard

Tutto passa alla dashboard via HTTPS:

  • un heartbeat periodico: versione dell'agente, indirizzo, metriche di sistema (CPU, memoria, disco, carico, rete), servizi e porte in ascolto, il web server e i domini che serve, i contatori del firewall;
  • gli eventi di sicurezza: l'indirizzo dell'attaccante, il tipo e l'ora dell'attacco e i dettagli che servono a capirlo: per un attacco web la singola riga di log che l'ha fatto scattare, per un malware il percorso del file e il testo trovato;
  • l'elenco dei pacchetti installati, per il controllo delle vulnerabilità;
  • l'hash SHA-256 dei file PHP analizzati, per cercarli tra i malware noti.

I log completi e i file non lasciano mai il server. Non c'è telemetria e niente viene condiviso con terzi, con un'eccezione: le funzioni di AI. Quando chiedi un'analisi AI, usi l'assistente o prepari un report, e mentre AutoMode o la modalità di emergenza sono attivi, gli eventi necessari vengono inviati ad Anthropic per produrre la risposta. La dashboard te lo dice prima che tu invii qualcosa. L'analisi istantanea, su tutti i piani, non invia niente a nessuno.

Token, password e autenticazione a due fattori

  • Il token di installazione si usa una volta sola e vale un'ora.
  • Il token dell'agente sta in /etc/infrafence/config.json, leggibile solo da root. La dashboard ne conserva solo l'hash: una copia del suo database non contiene token di agente utilizzabili.
  • Le modifiche fatte nella dashboard arrivano all'agente su un canale che gli dice solo di sincronizzarsi. L'agente scarica poi la configurazione via HTTPS con il proprio token: un messaggio su quel canale non vale mai come istruzione.
  • Le password sono conservate solo come hash. Le nuove password vengono confrontate con le violazioni note (Have I Been Pwned): dal browser escono solo i primi 5 caratteri del loro hash SHA-1.
  • L'autenticazione a due fattori (TOTP) è disponibile per ogni utente. Una volta attiva, è il database stesso a negare i dati dell'organizzazione a una sessione che non ha superato il passaggio del codice. Per approvare un'azione di AutoMode serve una sessione con 2FA.

Release firmate, e come verificarle

Ogni release viene compilata da GitHub Actions a partire dal repository pubblico, firmata con Cosign e pubblicata con la build provenance. L'agente installa un aggiornamento solo dalle release ufficiali su GitHub, e solo se checksum e firma risultano validi con la chiave pubblica integrata nell'agente.

Per verificare tu il binario sul server, confronta il suo checksum con quello della release:

curl -sL https://github.com/infrafence/infrafence-agent/releases/latest/download/checksums.txt
sha256sum /usr/local/bin/infrafence-agent

Verifica la firma Cosign:

cosign verify-blob \
  --key https://raw.githubusercontent.com/infrafence/infrafence-agent/main/cosign.pub \
  --signature https://github.com/infrafence/infrafence-agent/releases/latest/download/infrafence-agent-linux-amd64.sig \
  /usr/local/bin/infrafence-agent

E la build provenance, con la GitHub CLI:

gh attestation verify infrafence-agent-linux-amd64 --repo infrafence/infrafence-agent

Per una versione precedente sostituisci latest/download con download/v<versione>. Anche l'immagine container e il chart Helm sono firmati: vedi SECURITY.md.

Codice su GitHub, con licenza BSL 1.1

L'agente è source-available con la Business Source License 1.1: puoi leggere e verificare ogni riga prima di installarlo. L'uso in produzione è gratuito su qualsiasi numero di server, compresi quelli dei tuoi clienti, purché tu non lo usi per offrire un prodotto concorrente. Quattro anni dopo la pubblicazione di ogni versione, quella versione passa alla licenza Apache 2.0.

Il sito e la dashboard

  • Solo HTTPS, con HSTS per due anni su infrafence.com e su ogni sottodominio.
  • Una Content Security Policy rigida: script solo dal nostro dominio, ognuno con un nonce diverso a ogni richiesta, e nessun inserimento in frame da altri siti.
  • Font serviti dal nostro dominio. I cookie di analisi o pubblicità si attivano solo se li accetti nel banner dei cookie; senza consenso non ce ne sono.

Dove sono i dati

La dashboard e il suo database girano su server di Contabo GmbH in Germania, nell'Unione europea. Stripe, per i pagamenti, e il fornitore di AI, quando usi le funzioni di AI, possono trattare dati fuori dall'UE sulla base delle Clausole contrattuali tipo della Commissione europea o di una decisione di adeguatezza. Non vendiamo né affittiamo mai dati personali.

La Privacy Policy (in inglese) elenca ogni destinatario e per quanto tempo si conserva ogni tipo di dato.

Quando la dashboard non risponde

L'agente non ha mai bisogno della dashboard per proteggere il server: rilevamento, ban e blocchi girano tutti sul server. Errori di rete, timeout, errori DNS ed errori del server non contano mai come rifiuto, quindi la protezione resta attiva per tutta la durata di un'interruzione. Ban, lista consentiti, blocchi per paese e porte chiuse restano in vigore, i nuovi attacchi vengono comunque bloccati e gli eventi aspettano in coda finché la dashboard torna a rispondere.

Il rifiuto è un'altra cosa: la dashboard rifiuta un agente il cui token è stato revocato, la cui organizzazione è sospesa o che supera il limite di server del piano, per esempio dopo una disdetta o una fattura non pagata.

  1. Per le prime 24 ore la protezione locale resta in vigore e l'agente continua a riprovare.
  2. Dopo 24 ore di rifiuto senza una sola risposta positiva, l'agente spegne la sua protezione in modo pulito: rimuove le sue catene di firewall, i suoi ipset e le sue regole nel web server, ferma il controllo malware in tempo reale, e il rilevamento continua solo in modalità monitor. Le regole degli altri strumenti non vengono mai toccate.
  3. Dove il sistema lo consente, un avviso al login dice che InfraFence non protegge più il server.
  4. L'agente continua a chiedere ogni 30 minuti. Alla prima risposta positiva la protezione si riattiva e l'avviso viene tolto.

I titolari dell'account ricevono un'email 12 ore prima dello spegnimento, allo spegnimento e quando l'accesso torna.

Segnalare una vulnerabilità

Scrivi a info@infrafence.com, il contatto indicato nel nostro security.txt. Non aprire una issue pubblica su GitHub. Se puoi, includi i passaggi per riprodurla. Rispondiamo entro 48 ore e, con il tuo permesso, ti citiamo nelle note di rilascio. La policy completa è in SECURITY.md (in inglese).

Provalo gratis su 1 server

Starter protegge completamente un server, gratis e senza carta di credito.

  1. 01

    Crea un account gratuito, poi apri Server › Aggiungi server per ottenere il token di installazione. È valido per un'ora.

    Crea il token
  2. 02

    Poi esegui questo comando come root sul server:

    curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --token <TOKEN>