Cosa fa WardPane 2.0
WardPane 2.0 ospita siti statici, PHP e Node.js con certificati automatici e supporto per Cloudflare. Protezione e controllo del traffico funzionano per sito dentro il web server. Nella maggior parte degli otto pannelli della pagina di confronto, queste funzioni arrivano da ModSecurity o da un componente aggiuntivo a pagamento.
Per chi inizia e per gli amministratori esperti
Chi inizia ha un solo comando per installare, certificati che si emettono da soli, siti in sandbox e impostazioni spiegate in parole semplici. Gli amministratori esperti hanno ogni opzione, un terminale nel browser, PM2 per proprietario, .htaccess, regole per sito in un ordine noto, la Cloudflare API, esportazione e importazione, checksum delle release e il codice sorgente.
Hosting
I siti seguono una struttura in stile ISPmanager, appartengono a un utente Linux e sono serviti da WardPane stesso sulle porte 80 e 443.
- Siti e alias
- Un sito è un dominio più fino a 99 alias (un certificato Let's Encrypt contiene al massimo 100 nomi). Un alias serve il sito principale oppure, se ha una propria cartella, quella cartella. I siti possono avere un nome visualizzato.
- Struttura per proprietario
- I file si trovano in /var/www/<owner>/data/www/<domain>, con log e file temporanei accanto. Il proprietario predefinito è www-root, un utente Linux creato da WardPane. I siti della 1.x mantengono le loro vecchie cartelle.
- Tre handler
- Nessun handler (hosting statico), PHP o Node.js, scelto per ogni sito e modificabile in qualsiasi momento. Le impostazioni degli altri handler vengono conservate, quindi tornando indietro vengono ripristinate.
- File statici
- Modalità SPA (i percorsi sconosciuti vanno a index.html), un proprio 404.html, ETag forti con download riprendibili, reindirizzamento da HTTP a HTTPS e link simbolici che non possono mai uscire dalla cartella del sito.
- Runtime
- Il pannello elenca le versioni di PHP installate sul server e le versioni principali di Node.js supportate: 20, 22, 24 e 26, con la 24 come predefinita (la 20 è arrivata a fine vita ad aprile 2026). Le build di Node.js provengono da nodejs.org e vengono verificate con le somme SHA256 pubblicate.
- Un menu su ogni sito
- Ogni riga della tabella dei siti ha un menu con tutte le azioni per quel sito, e un interruttore spegne il sito e lo riaccende senza eliminare nulla.
- Shell nel browser
- Un terminale direttamente nel pannello: una shell root in una sessione root, oppure la shell del proprietario del sito nella cartella del sito. pm2 list e pm2 restart funzionano lì per i siti Node.js.
- Esportazione e importazione
- Ogni sito con tutte le impostazioni, più la blocklist globale, finisce in un unico file JSON. L'importazione unisce o sostituisce, verifica prima l'intero file e non tocca mai i file in /var/www.
PHP e Node.js
Ogni sito dinamico viene eseguito con un proprio utente Linux all'interno di una sandbox systemd. Un sito danneggiato o compromesso non può leggere i siti vicini.
- Un pool php-fpm per sito
- Nessun pool condiviso, nessuna opcache o sessione condivisa. Il codice è in sola lettura per PHP; può scrivere solo in tmp/, logs/, data/ e nelle cartelle che indica, e PHP non viene mai eseguito da quelle cartelle.
- Una sandbox PHP rigorosa
- L'intero file system è in sola lettura e noexec tranne php-fpm stesso, open_basedir è impostato, exec, system, shell_exec, proc_open, popen e putenv sono disattivati e le chiamate di sistema sono filtrate.
- .htaccess senza Apache
- Regole di riscrittura, reindirizzamenti, regole di accesso, Basic auth, intestazioni e cache dei siti reali funzionano così come sono: WordPress, Laravel e i consueti reindirizzamenti HTTPS e www. Le righe che non può applicare vengono mostrate, mai indovinate.
- Node.js con PM2
- Scelga una versione principale di Node.js, uno script npm o un file di avvio, variabili d'ambiente e limiti. Un daemon PM2 per proprietario esegue le app, quindi pm2 funziona dalla shell del proprietario.
- Il proxy davanti all'app
- Se vuole, i file in public/ vengono serviti direttamente, il resto va all'app con l'IP reale del visitatore in X-Forwarded-For e X-Real-IP. I WebSocket passano dopo gli stessi controlli di protezione.
- Riavvio, npm install e log
- La scheda Handler ha i pulsanti per il riavvio e per npm install (npm ci quando c'è un lockfile), i log di output, di errore e di installazione, e gli script di package.json tra cui scegliere.
Certificati e Cloudflare
I certificati vengono emessi e rinnovati senza passaggi manuali, anche per i siti dietro Cloudflare.
- Let's Encrypt, completamente automatico
- Un certificato per sito con tutti i suoi alias, rinnovato quando resta un terzo della sua validità. I nomi il cui DNS non punta al server vengono saltati e aggiunti quando lo fa, e il pannello ne mostra il motivo.
- Anche IPv6 verificato
- Let's Encrypt prova prima IPv6, quindi ogni record AAAA deve puntare al server. WardPane li controlla prima di ordinare un certificato.
- Un certificato per l'IP
- L'IP del server riceve un certificato di breve durata, rinnovato ogni pochi giorni. Il pannello su https://<ip>:1500 si apre senza avvisi.
- Limiti di frequenza di Let's Encrypt
- Il pannello non ordina certificati duplicati, segnala tutti insieme i nomi non riusciti di un ordine, attende più a lungo dopo ogni errore e sostituisce un account ACME disattivato.
- Un token Cloudflare con un clic
- Il pulsante Crea token Cloudflare apre Cloudflare con i permessi giusti già compilati. Incolli il token nel pannello, che potrà così controllare e correggere le zone dei suoi siti.
Protezione
Ogni sito ha i propri controlli, eseguiti all'interno del web server prima che PHP o Node.js vedano la richiesta. Un indirizzo viene bannato solo per un attacco evidente.
- Limite di richieste e ban
- Ogni indirizzo può inviare 150 richieste in 10 secondi per impostazione predefinita. Oltre il limite riceve un 404 e un ban per i minuti impostati. I visitatori IPv6 vengono conteggiati e bannati per il loro /64, quindi cambiare indirizzo non serve. Ogni sito ha un elenco di indirizzi consentiti.
- Bot Fight
- Blocca crawler AI, crawler SEO, scanner di vulnerabilità, script e browser headless, user agent vuoti e il suo elenco personale. Motori di ricerca e anteprime dei link solo se lo sceglie. Monitoraggio e lettori RSS non vengono toccati.
- Sonde e payload
- Le richieste di /.env, /.git, /wp-login.php e nomi simili che non esistono sul sito bannano l'indirizzo. Payload evidenti di SQL injection, XSS, path traversal e Log4Shell nell'URL portano al ban; quelli ambigui fanno solo rifiutare quella richiesta.
- Rilevamento delle scansioni
- Molti errori di fila (25 in 60 secondi per impostazione predefinita) sembrano gobuster o ffuf e portano al ban dell'indirizzo. Un'immagine mancante conta come un decimo di errore, quindi una vecchia pagina con immagini rotte non è una scansione.
- Crawler verificati
- Google, Bing, DuckDuckGo, Apple, OpenAI, Anthropic, Perplexity e Ahrefs pubblicano i propri intervalli IP. WardPane li scarica ogni giorno e banna chiunque dichiari di essere uno di loro da un altro indirizzo. Può anche bloccare questi crawler in base all'IP anche quando si nascondono dietro lo user agent di un browser.
- Feed IP pubblici
- Spamhaus DROP, FireHOL level 1 e blocklist.de, aggiornati ogni giorno, applicati per sito con un interruttore.
- Geo con gruppi
- Consenta o neghi i paesi uno per uno o per gruppi: ex URSS, CSI, UEE, UE, SEE, Schengen, NATO, G7, G20, OCSE, BRICS, SCO, ASEAN, Lega araba, Mercosur, continenti e altro. Aggiunga eccezioni e veda l'elenco finale dei paesi.
- Reti di hosting e AS number
- Blocchi le richieste da AWS, Azure, Google Cloud, Hetzner, OVH, DigitalOcean, Vultr e altri cloud, da cui proviene la maggior parte dell'automazione, o da qualsiasi AS number che indica.
- Filtro per lingua
- Consenta o neghi in base alla lingua del browser, con un interruttore separato per le richieste che non inviano alcuna lingua. Un utile segnale in più accanto al paese, per esempio dietro una VPN.
- Dispositivi
- Lasci entrare solo Windows, macOS, Linux, Android, iOS o altri, come filtro per i browser comuni.
- Solo tramite link
- Parametri URL obbligatori: il sito si apre solo a chi arriva con il suo link, per esempio ?ref=metaads da un annuncio. Un cookie firmato e, facoltativamente, l'IP del visitatore mantengono l'accesso. I percorsi per webhook e callback di pagamento restano aperti.
- Password
- Accesso HTTP Basic per bozze e copie di prova di un sito. Le password sono salvate come hash scrypt e verificate fuori dal thread principale, dopo tutti gli altri filtri.
- Protezione dall'hotlinking
- Gli altri siti non possono incorporare le sue immagini e i suoi file. Scelga le estensioni, i siti consentiti (i caratteri jolly funzionano) e che cosa fare con le richieste senza Referer.
- Intestazioni di sicurezza
- X-Frame-Options, Referrer-Policy, HSTS con includeSubDomains e preload, Content-Security-Policy e Permissions-Policy per sito.
- Honeypot
- Un percorso vietato da robots.txt. Una persona non lo apre mai, quindi chi lo richiede viene bannato subito.
- Pagine di blocco personalizzate
- Una sua pagina e un codice di stato (404, 403 o 200) per i blocchi su dispositivi, bot, geo e accesso solo tramite link, servite con no-store.
- Blocklist globale
- Indirizzi e reti bloccati su tutti i siti, salvati su disco e mantenuti tra i riavvii. Si applica anche dove un sito ha la protezione disattivata.
Controllo del traffico
Decida chi raggiunge ogni sito, in quale ordine si applicano le regole e che cosa vede un visitatore bloccato.
L'ordine dei controlli su ogni richiesta
- Cloudflare: IP reale del visitatore, solo tramite Cloudflare
- Blocklist globale, poi l'elenco di indirizzi consentiti del sito
- Limite di richieste e ban attivi
- Bot Fight: user agent, crawler verificati, feed IP, sonde, payload, scansioni, honeypot
- Geo: paesi e gruppi, reti di hosting, AS number, lingua del browser
- Dispositivi
- Intestazioni di sicurezza e protezione dall'hotlinking
- Solo tramite link
- Password
- Regole .htaccess, poi l'handler: file, PHP o Node.js
- IP reale con supporto per Cloudflare
- L'indirizzo del visitatore viene preso da CF-Connecting-IP solo quando la connessione arriva davvero da Cloudflare. L'elenco delle reti viene aggiornato ogni giorno da cloudflare.com.
- Solo tramite Cloudflare
- Le richieste dirette all'IP del server ricevono un 404, così nessuno può saltare la CDN e le sue regole.
- Quando l'interruttore è spento
- Un sito dietro Cloudflare che non è indicato come tale non banna mai gli indirizzi Cloudflare e ha un limite dieci volte più alto per ogni server Cloudflare. Il log suggerisce la correzione.
- Cloudflare Workers
- Le richieste da un Worker vengono conteggiate in base alla sua zona con limiti e ban normali; il Worker della sua zona viene trattato come Cloudflare.
- Codici delle pagine di blocco
- Usi 404 per sembrare un indirizzo vuoto, 403 per dire che la richiesta è rifiutata, oppure 200 con una sua pagina. I client limitati o bannati ricevono sempre un semplice 404.
- Risposte sicure per la cache
- Le risposte che dipendono dal pass del link ricevono Cache-Control: private e Vary: Cookie, così una CDN non le consegna mai a chi non ha il link.
Sicurezza del pannello
Il pannello gira come utente non privilegiato wardpane, e la sua pagina di accesso ha limiti propri contro gli attacchi brute force.
- Accesso come root
- Facoltativamente può accedere come root con la password root del server. Viene verificata da unix_chkpwd tramite un piccolo helper root su un socket che solo il pannello può aprire. Disattivato per impostazione predefinita.
- Limiti contro il brute force
- 5 errori bloccano un indirizzo (per IPv6, il suo /64) per 15 minuti, e 50 errori bloccano il suo /48. Un'ondata di errori da molti indirizzi chiude l'accesso agli indirizzi sconosciuti per 5 minuti. Gli indirizzi che hanno effettuato l'accesso negli ultimi 30 giorni continuano a funzionare.
- Elenco di IP consentiti
- Con PANEL_ALLOW_IPS impostato, il pannello non risponde affatto agli altri indirizzi. Rifiuta un elenco che escluderebbe l'indirizzo che sta usando.
- Isolamento dell'helper root
- Il pannello scrive lo stato desiderato; un helper root avviato da systemd ricontrolla ogni valore prima di creare utenti, cartelle e unit.
- PHP e Node.js in sandbox
- Utenti Linux per sito, sistema in sola lettura, /tmp privata, nessun nuovo privilegio, limiti di memoria e CPU e, facoltativamente, nessuna connessione in uscita.
- Checksum delle release
- Ogni archivio è pubblicato con il suo checksum SHA-256 e contiene il codice sorgente completo. Il programma di installazione lo scarica via HTTPS e verifica lo SHA-256 prima di eseguire qualsiasi cosa.
- Aggiornamenti reversibili
- Ogni aggiornamento crea un backup con uno script di ripristino, verifica che la nuova versione si avvii e, se non si avvia, torna indietro da solo.
- Recupero dell'accesso
- Se resta chiuso fuori, un comando sul server reimposta l'accesso al pannello e l'elenco degli IP consentiti, e rimuove i blocchi di accesso.
Lo provi su un server di prova
L'installazione richiede pochi minuti su un Ubuntu 24.04 pulito.