Come installare SafeLine WAF su un VPS Linux

Le applicazioni web esposte a Internet vengono costantemente sondate alla ricerca di SQL injection, abusi di credenziali e pattern di vulnerabilità note. SafeLine è un WAF self-hosted con licenza GPL-3.0 che gira come stack Docker Compose e filtra il traffico HTTP/S prima di inoltrare all'origine le richieste consentite. Il suo piano Personal gratuito supporta fino a 10 applicazioni.

Questo tutorial copre l'installazione e tre aspetti che richiedono particolare attenzione: la scelta dell'architettura di reverse proxy, la configurazione della rete Docker quando SafeLine si trova dietro un proxy esistente come Nginx Proxy Manager e un comando di verifica da eseguire dopo l'installazione per confermare che il WAF stia effettivamente intercettando gli attacchi.

La versione breve

• Installa SafeLine su un VPS Linux con Docker Compose. Usa l'installer a riga singola oppure scegli il percorso manuale con Docker Compose per ispezionare la definizione Compose e la configurazione dell'ambiente prima di avviare lo stack.
• Decidi l'architettura di reverse proxy prima di installare: SafeLine come unico proxy, SafeLine dietro un Nginx Proxy Manager esistente oppure SafeLine che condivide il server con Caddy. Ogni configurazione richiede assegnazioni di porta e impostazioni X-Forwarded-For diverse.
• Dopo l'installazione, verifica il WAF inviando con curl una sonda di SQL injection all'URL protetto. In modalità Balanced o Strict, una risposta 403 più una voce corrispondente in Attack Events confermano il blocco. In modalità Monitor, la voce corrispondente conferma il rilevamento anche se la risposta potrebbe restare andata a buon fine.
• Il piano Personal gratuito copre fino a 10 applicazioni e il motore di rilevamento di base. Il geo-blocco, l'esportazione dei log di attacco e le notifiche esterne richiedono il piano Lite; un rilevamento degli attacchi più potente e il bilanciamento del carico richiedono Pro.

Prima di iniziare: prerequisiti e contenuti di questo tutorial

Questo tutorial presuppone che tu disponga di un VPS Linux a cui accedere via SSH con accesso root o sudo e che Docker sia installato. Al termine avrai un'istanza SafeLine funzionante che protegge almeno un sito e un comando di verifica che potrai rieseguire in qualsiasi momento.

Ti serve:

• Un VPS Linux. I comandi seguenti presuppongono un sistema in stile Debian o Ubuntu con systemd; verifica i nomi dei pacchetti e dei servizi su altre distribuzioni.
• Almeno 1 vCPU, 1 GB RAM e 5 GB di disco secondo i requisiti ufficiali di installazione. Per un margine pratico in produzione, questa guida consiglia 2 vCPU, 4 GB RAM e 20 GB di disco.
• Docker 20.10.14 o successivo e Docker Compose 2.0 o successivo.
• Una CPU x86_64 con supporto SSSE3; verificalo con lscpu | grep ssse3 invece di dare per scontato che l'istruzione sia presente.
• Un dominio o sottodominio con DNS che punta all'IP pubblico del VPS, se prevedi di esporre l'applicazione protetta su HTTPS pubblico.
• Porte adeguate alla topologia scelta. Le configurazioni A e C assegnano normalmente a SafeLine le porte 80 e 443, mentre la configurazione B lascia quelle porte a Nginx Proxy Manager e assegna a SafeLine un listener diverso, come 10080.
• Accesso root o sudo.

Nel firewall o security group del provider VPS, esponi solo le porte pubbliche necessarie alla topologia scelta. Limita SSH e la porta TCP 9443 a fonti di amministrazione fidate. Nella configurazione B, mantieni la porta TCP 10080 chiusa a IPv4 e IPv6 pubblici e mantieni private in ogni topologia le porte di backend come 8080. Un accesso diretto alla 10080 bypasserebbe NPM e invaliderebbe il confine di fiducia X-Forwarded-For.

Nota: Per un'installazione manuale su ARM64, imposta ARCH_SUFFIX=-arm. La documentazione ufficiale di installazione di SafeLine afferma che ARM richiede una licenza Pro e che la Personal Edition non è supportata su ARM. Usa un VPS x86_64 per la Personal Edition.

Verifica Docker prima di iniziare:

docker --version
docker compose version

Entrambi i comandi dovrebbero restituire le versioni installate. Prosegui solo se Docker è alla versione 20.10.14 o successiva e Docker Compose è alla versione 2.0.0 o successiva; in caso contrario aggiorna prima di installare SafeLine.

Scegli prima l'architettura di reverse proxy

Un VPS appena creato lascia a SafeLine il pieno controllo delle porte 80 e 443. Un VPS che esegue già Nginx Proxy Manager, Caddy o l'Nginx dell'applicazione stessa no, e la scelta dell'architettura fa la differenza tra un'installazione senza intoppi e un conflitto di porta al primo avvio. Fai bene questa scelta una volta all'inizio e il resto dell'installazione è meccanico.

Le tre configurazioni:

• Configurazione A, SafeLine come unico reverse proxy. SafeLine controlla le porte 80 e 443 e gestisce il TLS per l'applicazione protetta. Le versioni CE attuali includono un flusso di lavoro Free Cert, mentre il caricamento manuale del certificato resta disponibile; verifica le opzioni esatte relative ai certificati nella versione installata. Il backend gira su una porta non pubblica e SafeLine vi instrada il traffico.
• Configurazione B, SafeLine dietro Nginx Proxy Manager (NPM). NPM mantiene le porte 80 e 443 e gestisce l'SSL. SafeLine è in ascolto sulla porta 10080 (solo HTTP, dato che NPM ha già terminato il TLS). NPM inoltra a SafeLine; SafeLine inoltra al backend. È una configurazione comune quando NPM è già installato.
• Configurazione C, SafeLine affiancato a Caddy. L'HTTPS automatico di Caddy compete con SafeLine per la porta 443. Una soluzione praticabile assegna a SafeLine le porte 80 e 443 e sposta Caddy su una porta HTTP interna non pubblica, come 8080, per il salto da SafeLine a Caddy all'applicazione.

Punto chiave: La configurazione A è la più semplice per un VPS nuovo; la configurazione B è la scelta giusta quando NPM è già in esecuzione; la configurazione C richiede una riassegnazione deliberata della porta di Caddy.

Installa SafeLine sul tuo VPS

L'installazione in sé è la parte facile. SafeLine offre due percorsi di installazione: un installer automatizzato che scarica uno script remoto da waf.chaitin.com e un percorso manuale con Docker Compose che ti permette di ispezionare tutto prima dell'esecuzione. Scegli quello che si adatta alla tua policy di sicurezza.

Passaggio 1: verifica che Docker sia pronto

Ricontrolla la versione di Docker e che il demone Docker sia in esecuzione:

docker --version
docker compose version
sudo systemctl status docker

L'output atteso include active (running) per il demone Docker. Se non è in esecuzione, avvialo con sudo systemctl start docker e abilitalo all'avvio con sudo systemctl enable docker.

Passaggio 2: esegui l'installer di SafeLine

Ci sono due sotto-percorsi. Scegline uno.

Passaggio 2a, installazione automatizzata. Esegui l'installer con privilegi di root:

sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Lo script chiede dove collocare la directory dati di SafeLine, scarica le immagini Docker e avvia lo stack. Dopo l'installazione, esegui sudo docker exec safeline-mgt resetadmin per recuperare o reimpostare le credenziali dell'amministratore, come descritto nella guida ufficiale di installazione. Conserva in modo sicuro le credenziali ottenute.

Nota: Questo comando scarica ed esegue come root uno script shell remoto da waf.chaitin.com. Il comando a riga singola ufficiale include curl -k, che disabilita la verifica del certificato TLS. Esamina lo script scaricato prima di eseguirlo, oppure usa il Passaggio 2b se quel rischio è inaccettabile. SafeLine è disponibile anche come installazione Cloudzy con un clic, ma quell'immagine usa /opt/safeline, /opt/safeline/.env, e /opt/safeline/docker-compose.yml. Non usare i /data/safeline percorsi di questa guida senza modifiche sull'immagine Cloudzy.

Passaggio 2b, installazione manuale con Docker Compose. Scarica e ispeziona il file Compose ufficiale, poi avvia lo stack:

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

Dopo docker compose up -d termina, elenca i container in esecuzione per conferma:

sudo docker compose ps

Dovresti vedere i container per safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi e safeline-chaos. Se un container mostra Exited, consulta il Passaggio 3 per le due cause più comuni.

Passaggio 3: risolvi gli errori di installazione più comuni

Due errori si presentano abbastanza spesso da meritare un passaggio dedicato.

Sovrapposizione di subnet. Se l'installazione fallisce con Pool overlaps with other one on this address space, la subnet predefinita di SafeLine è in conflitto con una rete Docker esistente. Come documentato in una guida alla risoluzione dei problemi di installazione di SafeLine, risolvilo modificando /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

Errore del resolver IPv6. Se safeline-tengine va in crash con nginx: [emerg] invalid IPv6 address in resolver, ispeziona prima il file del resolver e stabilisci chi lo gestisce:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Non modificare /etc/resolv.conf direttamente se è generato da systemd-resolved, NetworkManager o dal provider VPS. Correggi il valore nameserver malformato nella configurazione del servizio che lo gestisce, rigenera il file del resolver e quindi riavvia Tengine:

sudo docker restart safeline-tengine

Passaggio 4: accedi alla dashboard

La dashboard di gestione di SafeLine è in ascolto sulla porta TCP 9443 tramite HTTPS. Non lasciare questa porta amministrativa aperta all'intera rete Internet. Limitala a un indirizzo di origine fidato o a una VPN, oppure blocca l'accesso pubblico e usa un tunnel SSH:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Apri https://localhost:9443 attraverso il tunnel. Al primo accesso è previsto un avviso di certificato autofirmato; verifica che la connessione SSH abbia raggiunto il server previsto prima di proseguire.

Se hai perso le credenziali iniziali, reimposta la password dell'amministratore dall'host:

sudo docker exec safeline-mgt resetadmin

Il comando stampa le credenziali dell'amministratore che puoi usare per accedere di nuovo.

Configura SafeLine per la tua architettura

SafeLine ora è in esecuzione, ma non sta ancora proteggendo nulla. La pagina Applications della dashboard è dove indichi a SafeLine quali siti proteggere e dove inoltrare il traffico ripulito. La configurazione varia in base all'architettura scelta in precedenza, quindi ogni configurazione ha una propria sottosezione. Segui solo quella corrispondente alla tua impostazione.

Configurazione A: SafeLine come unico reverse proxy

Nella configurazione A, SafeLine è in ascolto direttamente sulle porte 80 e 443 e inoltra il traffico ripulito all'applicazione di backend su una porta non pubblica. Nella dashboard:

1. Vai a Applications, poi Add Application.
2. Imposta la porta di ascolto a 443 e abilita l'SSL. Usa il flusso di lavoro per i certificati disponibile nella versione di SafeLine che hai installato. Le versioni CE attuali includono la richiesta Free Cert e la gestione del rinnovo, mentre il caricamento manuale del certificato resta disponibile.
3. Imposta l'upstream su http://127.0.0.1:8080. Se il backend gira in Docker, pubblica la sua porta solo sul loopback, ad esempio "127.0.0.1:8080:8080" nella sezione ports del servizio. Evita un IP di container fisso come 172.17.0.5 perché può cambiare quando il container viene ricreato.
4. Salva l'applicazione. SafeLine inizia immediatamente ad ascoltare sulla porta 443 e a inoltrare il traffico ripulito al backend.
5. Verifica che il record DNS A del tuo dominio punti all'IP pubblico del VPS e che le porte 80 e 443 siano raggiungibili dall'esterno.

Se la porta 443 era già occupata da un altro processo, il container di SafeLine non riuscirà a effettuare il bind e la dashboard mostrerà un errore su quell'applicazione. Arresta il processo in conflitto, o scegli una porta diversa, prima di aggiungere l'applicazione.

Configurazione B: SafeLine dietro Nginx Proxy Manager

La configurazione B lascia che NPM continui a fare ciò che già fa (controllare le porte 80 e 443, gestire Let's Encrypt) e inserisce SafeLine dietro di esso come livello di sicurezza dedicato. Il flusso del traffico è: client, poi NPM (porta 443, terminazione TLS), poi SafeLine (porta 10080, HTTP), poi l'applicazione di backend.

Dentro la dashboard di SafeLine:

1. Applications, poi Add Application. Imposta la porta di ascolto a 10080 e lascia l'SSL disattivato (NPM ha già terminato il TLS).
2. Imposta l'upstream sull'indirizzo interno dell'applicazione, come descritto nella configurazione A.
3. Salva l'applicazione.

In Nginx Proxy Manager:

1. Hosts, poi Proxy Hosts, poi Add Proxy Host.
2. Scheda Details: imposta il nome di dominio, lo schema http, e la porta di inoltro 10080. Se NPM gira direttamente sull'host, usa 127.0.0.1 come hostname di inoltro. Se NPM gira in Docker su Linux, 127.0.0.1 punta al container NPM anziché all'host VPS. Aggiungi la mappatura host-gateway di Docker al servizio Compose di NPM, quindi usa host.docker.internal come hostname di inoltro:

extra_hosts:
  - "host.docker.internal:host-gateway"

Dalla directory Compose di NPM, esegui sudo docker compose up -d in modo che il container venga ricreato con la nuova mappatura dell'host.

3. Scheda SSL: richiedi un certificato Let's Encrypt, forza l'SSL e abilita HTTP/2.
4. Lascia vuota la scheda Advanced di NPM per X-Forwarded-For. Nel template NPM attuale, il contenuto di Advanced viene inserito a livello di server e non sovrascrive gli header generati a livello di location secondo le regole di ereditarietà di NGINX. La location generata invia:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

La seconda direttiva aggiunge l'indirizzo osservato da NPM come valore più a destra nell'header.

5. Salva il Proxy Host.

Tornato in SafeLine, configura l'estrazione dell'IP di origine solo dopo aver confermato la catena di header effettiva. SafeLine 9.3.1 ha introdotto un'estrazione XFF flessibile con selezione di direzione e indice.

1. Settings, poi Advanced, poi Real IP from Header. Imposta il nome dell'header su X-Forwarded-For.
2. Usa l'estrazione personalizzata dalla fine dell'header e seleziona l'indirizzo più a destra aggiunto da NPM. Le etichette esatte degli indici variano in base alla versione, quindi verifica il risultato in Logs, poi Access. Se la versione installata è precedente alla 9.3.1, aggiornala prima di seguire questa topologia.
3. Se Cloudflare o un'altra CDN si trova prima di NPM, configura innanzitutto NPM in modo che si fidi solo degli intervalli di proxy pubblicati da quel provider, così che l'indirizzo aggiunto da NPM sia affidabile. Non selezionare una posizione fissa finché non hai ispezionato e testato la catena di header effettiva.
4. Salva e ricarica l'applicazione.

Testa la configurazione da una macchina esterna al VPS:

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

Il log di accesso di SafeLine dovrebbe mostrare il tuo vero indirizzo pubblico, non 1.2.3.4 né l'indirizzo bridge di NPM.

Impedisci agli utenti di bypassare SafeLine mantenendo privato il listener del backend. Per un backend Docker Compose, pubblica la porta solo sul loopback:

ports:
  - "127.0.0.1:8080:8080"

Per un servizio in esecuzione direttamente sull'host, configuralo perché ascolti su 127.0.0.1:8080 invece di 0.0.0.0:8080. Verifica entrambe le porte interne da una macchina esterna al VPS:

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

Le connessioni TCP dovrebbero essere rifiutate o andare in timeout. Un errore HTTP o "Empty reply from server" significa comunque che la porta è raggiungibile pubblicamente e deve essere protetta. Se il binding sul loopback non è possibile, crea regole del firewall specifiche per l'interfaccia, la rete Docker e il container di destinazione effettivi anziché applicare una regola DOCKER-USER generica.

Configurazione C: SafeLine con Caddy

Nella configurazione C, SafeLine prende le porte 80 e 443; Caddy si sposta su una porta HTTP interna non pubblica. Il flusso del traffico è: client, poi SafeLine (443, TLS), poi Caddy (8080, HTTP interno), poi il backend dell'applicazione.

Modifica /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

L' :8080 il blocco del sito è la parte importante: Caddy ora ascolta su una porta HTTP interna invece di competere con SafeLine per la porta 443. La bind 127.0.0.1 riga mantiene quel listener locale al VPS. Ricarica Caddy con sudo systemctl reload caddy e conferma con sudo ss -ltnp | grep -E ':(443|8080)' che Caddy sia in ascolto sulla porta 8080, non sulla 443.

In SafeLine, aggiungi un'applicazione che ascolti sulla porta 443 con SSL abilitato, poi imposta l'upstream su http://127.0.0.1:8080. L'impostazione X-Forwarded-For può restare sull'opzione predefinita basata sulla connessione di rete, perché Caddy si trova dietro SafeLine, non davanti.

Scegli una modalità di protezione e verifica che il WAF blocchi gli attacchi

SafeLine ha tre modalità di protezione che decidono cosa succede quando il motore contrassegna una richiesta come dannosa. La modalità di partenza giusta dipende dall'applicazione; il passaggio di verifica è lo stesso in qualsiasi modalità.

Modalità di protezione: Monitor, Balanced, Strict

Ogni applicazione in SafeLine ha la propria impostazione della modalità di protezione, configurabile in Applications, poi la tua app, poi Protection Mode:

• Monitor. SafeLine registra le richieste che altrimenti bloccherebbe, ma non le blocca. È il punto di partenza più sicuro per un'applicazione di produzione complessa con moduli di input articolati (un forum, un pannello di amministrazione con campi WYSIWYG, un'API che accetta payload JSON in forma libera). Esegui Monitor per qualche giorno, esamina la pagina Attack Events e conferma che non ci siano falsi positivi verso utenti reali prima di passare a Balanced.
• Balanced. La modalità predefinita. Le cifre GitHub pubblicate dal fornitore riportano per la modalità Balanced un rilevamento del 71.65%, un'accuratezza del 99.45% e un tasso di falsi positivi dello 0.07%. Per la modalità Strict sono riportati un rilevamento del 76.17%, un'accuratezza del 99.38% e un tasso di falsi positivi dello 0.22%. Si tratta di risultati dichiarati dal fornitore e non di un benchmark indipendente, e il README non identifica il dataset come WAF-Eval. Consideralo come dato comparativo di prodotto, non come prestazione garantita in produzione.
• Strict. Un set di regole più aggressivo con euristiche più severe e il compromesso tra rilevamento e falsi positivi mostrato sopra. Vale la pena provarlo dopo una o due settimane di funzionamento pulito in Balanced, una volta compreso il tuo traffico.

Consiglio: Balanced per un'installazione nuova senza traffico live da disturbare. Per un'applicazione di produzione esistente, parti da Monitor per qualche giorno, cerca falsi positivi nel log Attack Events e passa a Balanced una volta messe a punto eventuali eccezioni. Vale la pena provare Strict dopo una o due settimane di Balanced, una volta compreso il tuo traffico.

Verifica il WAF con un test SQLi via curl

L'ultimo passaggio prima di considerare conclusa l'installazione è confermare che il WAF intercetti davvero un attacco. Esegui una sonda di SQL injection innocua contro il tuo sito protetto da una qualsiasi macchina esterna al VPS:

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Questo è il vettore di test per SQL injection pubblicato da SafeLine. In modalità Balanced o Strict, aspettati uno stato 403 e una risposta di blocco di SafeLine. In modalità Monitor, aspettati che la richiesta venga registrata senza essere bloccata. La versione HTTP e il corpo esatto della risposta possono variare, quindi conferma il risultato con una voce corrispondente in Attack Events.

Poi apri la dashboard tramite il metodo di accesso ristretto del Passaggio 4 e vai in Logs, poi Attack Events. Dovresti vedere una nuova voce con timestamp corrispondente, tipo di attacco SQL Injection, IP di origine corrispondente alla macchina da cui hai eseguito curl e la query string incriminata nel dettaglio della richiesta. Clicca sull'evento per vedere la richiesta e la risposta complete catturate da SafeLine.

Se la richiesta curl ha restituito 200 OK, interpreta il risultato insieme al log Attack Events:

• Un evento SQL Injection corrispondente significa che l'applicazione è probabilmente in modalità Monitor; la registrazione senza blocco è prevista.
• Se non c'è alcun evento corrispondente, verifica che il DNS risolva verso il VPS previsto, controlla la configurazione del listener e dell'upstream di SafeLine e correla l'orario della richiesta con il log di accesso di SafeLine.
• Conferma inoltre che la protezione sia abilitata e che nessuna whitelist di IP, regola di consenso personalizzata o eccezione di percorso copra la richiesta di test.

Punto chiave: Se la sonda curl restituisce 403 con la pagina di intercettazione di SafeLine e in Attack Events compare una voce con tipo di attacco SQL Injection, il WAF sta intercettando il traffico correttamente.

Cosa copre il piano gratuito e cosa richiede un piano a pagamento

Il piano Personal gratuito è sufficiente a proteggere la maggior parte delle installazioni su singolo VPS. I piani a pagamento iniziano a contare quando ti servono funzionalità operative (notifiche, esportazione dei log, geo-blocco) o quando superi il limite di 10 applicazioni.

Il dettaglio, tratto dalla pagina dei prezzi di CyberServal:

• Personal, gratuito. Fino a 10 applicazioni. Include il motore di rilevamento semantico (SQLi, XSS, command injection, path traversal, SSRF, XXE, CRLF), il rate limiting, la sfida CAPTCHA anti-bot, la cifratura dinamica HTML/JS contro gli scraper automatizzati, le regole web ACL e la gestione dei certificati. Le versioni CE attuali includono anche la richiesta Free Cert e la gestione del rinnovo.
• Lite, $10/mese o $100/anno. Aggiunge il geo-blocco, il database IP di threat intelligence, l'integrazione delle notifiche Discord e Telegram, l'esportazione dei log di attacco e alza il limite delle applicazioni a 20.
• Pro, $100/mese o $1,000/anno. Aggiunge un rilevamento degli attacchi più potente, configurazioni per servizio e globali, pagine di intercettazione personalizzate, bilanciamento del carico degli upstream, sincronizzazione dei nodi master-slave e applicazioni illimitate. Consulta la tabella dei prezzi attuale per eventuali variazioni.
• Ultimate, prezzo personalizzato. Condizioni enterprise su misura con supporto personale su più canali e sviluppo di funzionalità personalizzate.

SafeLine elabora e archivia i dati delle applicazioni all'interno del suo stack Compose locale. Tuttavia, le note di rilascio della CE attuali menzionano il Threat Intelligence Sharing, quindi gli operatori dovrebbero esaminare i controlli UEP, privacy e condivisione della versione installata e osservare le connessioni in uscita prima di considerare l'installazione a egress zero.

Come proseguire da qui

L'installazione è completa e il WAF è verificato. Alcune attività successive aiuteranno a mantenere l'installazione in salute.

• Per qualsiasi applicazione di produzione con input utente articolato (un forum, un pannello di amministrazione, un'API in forma libera), imposta la modalità di protezione su Monitor per un periodo da tre a sette giorni, esamina quotidianamente la pagina Attack Events e passa a Balanced una volta messi a punto eventuali falsi positivi.
• Nel piano Lite, configura l'integrazione delle notifiche Discord o Telegram in modo che gli avvisi di attacco ti raggiungano al di fuori della dashboard.
• Pianifica una finestra di manutenzione mensile. Prima di aggiornare, esegui il backup dei dati e della configurazione dell'ambiente di SafeLine, leggi le note di rilascio attuali, e usa la procedura di aggiornamento supportata per la versione installata. Non affidarti solo a docker compose pull seguito da docker compose up -d, perché la definizione Compose o le variabili d'ambiente richieste possono cambiare tra una versione e l'altra. Gli utenti Cloudzy con installazione a un clic dovrebbero partire da /opt/safeline e seguire le istruzioni dell'immagine del marketplace.
• Iscriviti alla pagina delle release di SafeLine per le notifiche delle patch di sicurezza e al repository del progetto per il tracciamento dei problemi.

Se non hai ancora un VPS per questa installazione, SafeLine è disponibile come installazione a un clic nel Il marketplace di Cloudzy. Un piano con 4 GB RAM offre il margine pratico consigliato in questa guida; ricontrolla la tabella dei prezzi attuale su Cloudzy al momento della pubblicazione, poiché le specifiche dei piani possono cambiare. L'immagine con un clic utilizza /opt/safeline e i piani /opt/safeline/docker-compose.yml, quindi le istruzioni relative all'architettura e alla dashboard restano valide, ma i /data/safeline comandi di questa guida non si applicano in modo identico.

Domande frequenti

SafeLine WAF sostituisce Nginx Proxy Manager, o devo usarli entrambi?

SafeLine può sostituire Nginx Proxy Manager quando viene installato come unico reverse proxy. Tuttavia non deve necessariamente sostituire NPM. Una configurazione comune mantiene NPM davanti per SSL e routing e mette SafeLine dietro come livello di sicurezza dedicato. Entrambe funzionano; la scelta dipende dal fatto che tu voglia uno strumento che svolga entrambi i compiti o due strumenti che ne svolgano bene uno ciascuno.

Il piano gratuito è sufficiente per un singolo sito WordPress o un piccolo SaaS?

Sì, per la protezione. Il piano Personal gratuito include il motore di rilevamento semantico, il rate limiting, la sfida CAPTCHA anti-bot e la cifratura dinamica HTML/JS, che sono difese fondamentali per un singolo sito. I piani a pagamento aggiungono funzionalità operative come il geo-blocco, l'esportazione dei log di attacco, le notifiche esterne, limiti di applicazioni più alti, un rilevamento più potente e il bilanciamento del carico. Se un piano a pagamento sia necessario dipende dalle funzionalità richieste e dal numero di applicazioni, non dal solo volume di traffico.

SafeLine funziona su un VPS con 1 GB di RAM?

Il minimo ufficiale di SafeLine è 1 GB di RAM. Può bastare per test o carichi di lavoro molto leggeri, ma la capacità in produzione dipende dal traffico, dalle funzionalità abilitate e dalla conservazione dei log. Per una piccola installazione di produzione, 2 vCPU e 4 GB RAM sono un punto di partenza prudente; monitora l'uso della memoria e dimensiona in base al carico misurato.

Perché ARM64 richiede una licenza a pagamento?

Il documentazione ufficiale di installazione afferma che le installazioni su ARM richiedono una licenza Pro e che la Personal Edition non è supportata su ARM. Se vuoi la Personal Edition, scegli un VPS x86_64; se ti serve ARM, prevedi una licenza Pro.

Cosa riceve Chaitin Tech dalla mia istanza SafeLine?

I dati esatti in uscita possono variare in base alla versione e alle funzionalità abilitate. Le note di rilascio della CE attuali menzionano il Threat Intelligence Sharing, mentre la versione installata potrebbe esporre anche UEP o altri controlli di condivisione. Esamina tali impostazioni e le note di rilascio della tua versione installata, quindi verifica l'egress a livello di rete. I container locali di SafeLine gestiscono i dati delle applicazioni, ma questo dato da solo non dimostra che rifiutare UEP fermi ogni richiesta in uscita.