Ogni server KapsuleHost è dotato di un firewall gestito che nega il traffico in ingresso per impostazione predefinita, oltre a protezione contro attacchi di forza bruta, un firewall per applicazioni web e applicazione automatica di patch di sicurezza, il tutto controllato da una pagina in KPanel.
Le impostazioni predefinite sono scelte in modo che un nuovo server sia sicuro prima di qualsiasi intervento da parte tua. Quello che aggiungi in seguito di solito sono solo le porte di cui ha bisogno la tua applicazione. Questa guida illustra l'intera pagina Gestione server, perché il firewall è una sezione di essa e le altre sezioni sono ciò che ti evita di aver bisogno del firewall in primo luogo.
Apertura della pagina di gestione
- Accedi a KPanel.
- Fai clic su Cloud Servers nella barra laterale sinistra, quindi fai clic sul tuo server.
- Fai clic su Management nei pulsanti di azione nella parte superiore della pagina.
L'indirizzo diretto è /cloud-servers/<server-id>/management. La pagina si descrive come "Firewall, patch del sistema operativo, fail2ban e ModSecurity. Le modifiche vengono applicate tramite SSH in pochi secondi."
Se un banner recita "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", il pannello non può raggiungere il server in questo momento. Le tue impostazioni vengono comunque salvate, semplicemente non vengono applicate ancora. Verifica che il server sia in esecuzione e raggiungibile.
La politica firewall predefinita
La sezione Firewall (UFW) afferma la politica in una riga: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
In pratica significa:
- Niente può raggiungere il tuo server da internet a meno che una regola non lo consenta.
- La porta 22 è sempre aperta, quindi una modifica al firewall non potrà mai bloccarti dalla macchina.
- Le porte di cui ha bisogno lo stack dell'app, come 80 e 443 per un'applicazione web, vengono aperte automaticamente.
- Il traffico in uscita dal server non è limitato.
Senza regole personalizzate, la sezione mostra "No custom rules. Defaults: SSH + app-stack ports." Questo è uno stato sano, non una configurazione mancante.
Aggiunta di una regola personalizzata
Aggiungi una regola quando esegui qualcosa su una porta che la politica predefinita non copre: un'applicazione Node sulla porta 3000, un database che devi raggiungere direttamente sulla porta 5432, un server di giochi o media su una porta UDP.
- Apri la sezione Firewall (UFW).
- Digita il numero della Port nel primo campo. I valori validi vanno da 1 a 65535.
- Scegli TCP o UDP.
- Scegli Allow o Deny.
- Fai clic su Add.
La regola appare nell'elenco con un badge ALLOW o DENY e la porta e il protocollo, ad esempio 3000/tcp. Viene inviata al server sulla connessione di gestione entro pochi secondi.
Per rimuovere una regola, fai clic sulla X alla fine della sua riga. La rimozione di una regola Allow chiude quella porta di nuovo immediatamente.
Esporre una porta di database a tutta internet è uno dei modi più comuni in cui un server viene compromesso. Prima di consentire 3306, 5432, 6379 o 27017, chiediti se la cosa che si connette potrebbe raggiungere il database tramite l'interfaccia loopback del server stesso o una rete privata. Se deve veramente essere raggiungibile dall'esterno, assicurati che il servizio stesso richieda un'autenticazione e una crittografia forti.
Aggiungi la regola prima, quindi avvia il servizio. Un servizio che si avvia dietro una porta chiusa sembra rotto esattamente nello stesso modo in cui sembrerebbe un servizio che non è riuscito ad avviarsi, e potresti perdere molto tempo a eseguire il debug del livello sbagliato.
Stack di applicazioni
La sezione App stack comunica alla piattaforma che tipo di applicazione esegue questo server, in modo che il preset di hardening possa essere regolato di conseguenza. L'installazione di un'applicazione tramite il pannello imposta questa opzione automaticamente.
Gli stack riconosciuti sono WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web e No app stack. La sezione si spiega da sola come: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
Lo stack influisce su quali porte si aprono automaticamente e su come vengono regolate le altre protezioni, in modo più evidente in fail2ban.
fail2ban
fail2ban monitora i tentativi di autenticazione e bandisce gli indirizzi che continuano a fallire. È attivo per impostazione predefinita e la pagina lo descrive come: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
Lascialo attivo. È la protezione singola più economica della pagina, non costa nulla in termini di prestazioni e trasforma un costante rumore di fondo di tentativi di indovinare la password in nulla. Su uno stack WordPress o WooCommerce protegge anche il modulo di accesso, che è dove la maggior parte degli attacchi contro WordPress in realtà arriva.
ModSecurity, il firewall per applicazioni web
ModSecurity ispeziona le richieste HTTP rispetto all'OWASP Core Rule Set e contrassegna quelle che sembrano attacchi. Su un server KapsuleHost inizia in modalità di sola rilevazione: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
La sola rilevazione è il punto di partenza corretto. Il Core Rule Set è esauriente e su un'applicazione reale alcune richieste legittime corrisponderanno a una regola. Eseguilo in sola rilevazione per un po', leggi i log, scopri quali regole il tuo traffico attiva e solo allora passa al blocco all'interno del server.
L'attivazione del blocco senza prima regolare può rompere il tuo sito. I moduli con testo formattato, i caricamenti di file e i client API con payload insoliti sono le solite vittime. Controlla i tuoi log prima di cambiare.
Applicazione automatica delle patch del sistema operativo
Gli aggiornamenti di sicurezza vengono applicati automaticamente. La sezione spiega la rete di sicurezza: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."
Due impostazioni si trovano sotto l'interruttore:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). Gli aggiornamenti del kernel hanno effetto solo dopo un riavvio. Se lo disattivi, le patch del kernel vengono installate ma non sono attive fino a quando non riavvii tu stesso.
- Quiet window (UTC), un'ora di inizio e fine. I riavvii avvengono solo al suo interno. Impostalo alle ore più tranquille per il tuo pubblico e ricorda che il campo è in UTC, non nell'ora locale.
Lascia l'applicazione automatica delle patch attiva. La stragrande maggioranza dei server compromessi esegue software con una patch pubblicata settimane prima. Uno snapshot pre-patch con rollback automatico significa che l'obiezione solita, che un aggiornamento potrebbe rompere qualcosa, è già gestita.
Cronologia delle patch e esecuzione di una patch ora
La sezione Patch history elenca ogni esecuzione con uno stato di RUNNING, SUCCESS, ROLLED_BACK, FAILED o SKIPPED, il numero di pacchetti aggiornati, se il server ha effettuato il riavvio e l'ora di inizio.
Per applicare la patch immediatamente anziché aspettare la pianificazione, fai clic su Run patch now. La conferma legge: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
Una voce ROLLED_BACK significa che la rete di sicurezza ha fatto il suo lavoro: il server non è tornato pulito dopo un riavvio, quindi lo snapshot pre-patch è stato ripristinato. Vedi Cloud Server Snapshots per come funzionano questi snapshot.
Una baseline sensata
Per la maggior parte dei server, questa è l'intera configurazione di sicurezza:
| Impostazione | Consigliato |
|---|---|
| Firewall | Attivo, regole predefinite, più solo le porte di cui ha bisogno la tua app |
| fail2ban | Attivo |
| ModSecurity | Attivo, sola rilevazione finché non hai letto i log |
| Applicazione automatica delle patch del sistema operativo | Attiva, con riavvii consentiti in una finestra tranquilla |
| Autenticazione SSH | Chiavi, non password |
L'ultima riga non è su questa pagina ma conta più del resto messo insieme. Vedi Connecting to Your Cloud Server With SSH.
Risoluzione dei problemi
"Could not load management config." Il pannello non ha potuto leggere le impostazioni per questo server. Ricarica e verifica che il server esista e sia provisioning.
"Port must be 1-65535." Il campo della porta accetta un numero intero in quell'intervallo. Gli intervalli e i nomi dei servizi non sono accettati qui.
La mia regola è stata salvata ma nulla è cambiato. Cerca il banner "Live apply unavailable". Se è visualizzato, la modifica è archiviata ma non ancora inviata al server.
Riesco a raggiungere il mio servizio da una rete ma non da un'altra. Di solito è il tuo firewall in uscita, non quello del server. Esegui il test da una connessione diversa prima di modificare le regole qui.
Un'esecuzione di patch mostra FAILED. Leggi il messaggio di errore sulla riga. Un disco pieno è la causa più comune. Libera dello spazio e fai clic su Run patch now.
Il traffico legittimo ha iniziato a essere bloccato. Se hai cambiato ModSecurity in modalità di blocco, ripristinalo alla sola rilevazione, leggi i log e identifica la regola prima di riprovare.
Se una regola firewall si rifiuta di applicare o sei bloccato da un servizio che hai consentito, invia un'email a support@kapsulehost.com con il nome del server, la porta e cosa ti aspetti di potervi raggiungere.