Server cloud
Gestione della sicurezza e del firewall per Cloud Server
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
Cloud Server Firewall and Security Management
Ogni server KapsuleHost viene fornito con un firewall gestito che nega il traffico in ingresso per impostazione predefinita, oltre a protezione contro gli attacchi brute-force, un web application firewall e patch di sicurezza automatiche, il tutto controllato da una sola pagina in KPanel.
Le impostazioni predefinite sono scelte in modo che un server completamente nuovo sia sicuro prima di apportare qualsiasi modifica. Quello che aggiungi oltre alle impostazioni predefinite sono di solito solo le porte di cui ha bisogno la tua applicazione. Questa guida esamina l'intera pagina di Server management, perché il firewall è una sezione di essa e le altre sezioni sono ciò che impedisce di avere 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, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."
Se un banner recita "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", il pannello non riesce a 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 policy del firewall predefinita
La sezione Firewall (UFW) indica la policy in una riga: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
In pratica questo significa:
- Niente può raggiungere il tuo server da internet se una regola non lo consente.
- La porta 22 è sempre aperta, quindi una modifica del firewall non potrà mai bloccarti dall'accesso alla macchina.
- Le porte di cui ha bisogno il tuo app stack, 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 policy predefinita non copre: un'applicazione Node sulla 3000, un database che devi raggiungere direttamente sulla 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 sono 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 di nuovo immediatamente quella porta.
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 invece. Se deve veramente essere raggiungibile dall'esterno, assicurati che il servizio stesso richieda autenticazione forte e crittografia.
Aggiungi la regola per primo, quindi avvia il servizio. Un servizio che viene avviato dietro una porta chiusa sembra rotto esattamente allo stesso modo di un servizio che non è riuscito ad avviarsi, e puoi perdere molto tempo a eseguire il debug del livello sbagliato.
App Stacks
La sezione App stack indica alla piattaforma che tipo di applicazione esegue questo server, in modo che il preset di hardening possa essere regolato ad esso. L'installazione di un'applicazione tramite il pannello imposta questo automaticamente.
Gli stack riconosciuti sono WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web e No app stack. La sezione si spiega da sola: "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, più visibilmente in fail2ban.
fail2ban
fail2ban monitora i tentativi di autenticazione e blocca 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 singolarmente più economica della pagina, non ha alcun costo in termini di prestazioni e trasforma il rumore di fondo costante dei tentativi di indovinare la password in nulla. Su uno stack WordPress o WooCommerce protegge anche il modulo di accesso, che è il luogo in cui la maggior parte degli attacchi contro WordPress effettivamente ha luogo.
ModSecurity, il Web Application Firewall
ModSecurity ispeziona le richieste HTTP rispetto all'OWASP Core Rule Set e contrassegna quelle che sembrano attacchi. Su un server KapsuleHost inizia in modalità detection-only: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
La modalità detection-only è il punto di partenza corretto. L'OWASP Core Rule Set è completo, e su un'applicazione reale alcune richieste legittime corrisponderanno a una regola. Eseguilo in detection-only 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 regolazione preliminare può rompere il tuo sito. Gli invii di moduli con testo ricco, i caricamenti di file e i client API con payload insoliti sono le solite vittime. Controlla i tuoi log prima di passare.
OS Auto-Patching
Gli aggiornamenti di sicurezza vengono applicati per te. 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 lasci questa opzione disattivata, le patch del kernel vengono installate ma non attive fino a quando non riavvii tu stesso.
- Quiet window (UTC), un'ora di inizio e di fine. I riavvii avvengono solo al suo interno. Impostalo sulle ore più tranquille per il tuo pubblico e ricorda che il campo è in UTC, non nell'ora locale.
Lascia l'auto-patching attivo. 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 patch ed 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 riavviato e l'ora di inizio.
Per applicare la patch immediatamente invece di aspettare la pianificazione, fai clic su Run patch now. La conferma recita: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
Un'voce ROLLED_BACK significa che la rete di sicurezza ha fatto il suo lavoro: il server non è tornato in modo pulito dopo un riavvio, quindi lo snapshot pre-patch è stato ripristinato. Vedi Cloud Server Snapshots per come funzionano questi snapshot.
Una baseline ragionevole
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, detection-only finché non hai letto i log |
| OS auto-patching | Attivo, con riavvii consentiti in una finestra tranquilla |
| SSH authentication | Chiavi, non password |
L'ultima riga non è su questa pagina ma è più importante 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 controlla che il server esista e sia stato sottoposto a provisioning.
"Port must be 1-65535." Il campo porta accetta un numero intero in quell'intervallo. Gli intervalli e i nomi di servizio non sono accettati qui.
La mia regola è stata salvata ma non è cambiato nulla. Cerca il banner "Live apply unavailable". Se è visualizzato, la modifica è archiviata ma non ancora inviata al server.
Posso raggiungere il mio servizio da una rete ma non da un'altra. Di solito è il tuo firewall in uscita, non quello del server. Testa 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à blocco, riportalo a detection-only, leggi i log e identifica la regola prima di riprovare.
Se una regola del firewall rifiuta di applicarsi o sei bloccato da un servizio che hai consentito, invia un'email a support@kapsulehost.com con il nome del server, la porta e ciò che ti aspetti di raggiungere.