Cloudservers
Cloud Server Firewall en Beveiligingsbeheer
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 en beveiligingsbeheer
Elke KapsuleHost server wordt geleverd met een beheerde firewall die inkomend verkeer standaard weigert, plus beveiliging tegen brute-force-aanvallen, een Web Application Firewall en automatische beveiligingspatches, allemaal beheerd vanuit één pagina in KPanel.
De standaardwaarden zijn zo gekozen dat een gloednieuwe server veilig is voordat u iets hebt aangeraakt. Wat u erbovenop toevoegt, zijn meestal alleen de poorten die uw eigen applicatie nodig heeft. Deze handleiding behandelt de hele Server management pagina, omdat de firewall één sectie ervan is en de andere secties zijn wat u ervan weerhoudt de firewall überhaupt nodig te hebben.
De beheerpagina openen
- Meld u aan bij KPanel.
- Klik op Cloud Servers in de linker zijbalk en klik op uw server.
- Klik op Management in de actieknoppen boven aan de pagina.
Het directe adres is /cloud-servers/<server-id>/management. De pagina beschrijft zichzelf als "Firewall, OS patches, fail2ban, en ModSecurity. Wijzigingen worden via SSH binnen enkele seconden toegepast."
Als een banner aangeeft "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", kan het paneel de server op dit moment niet bereiken. Uw instellingen worden nog steeds opgeslagen, ze worden alleen niet direct toegepast. Controleer of de server draait en bereikbaar is.
Het standaard firewallbeleid
De sectie Firewall (UFW) stelt het beleid in één regel uit: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
In de praktijk betekent dit:
- Niets kan uw server vanaf internet bereiken tenzij een regel dit toestaat.
- Poort 22 is altijd open, dus een firewall-wijziging kan u nooit uit de machine sluiten.
- De poorten die uw app-stack nodig heeft, zoals 80 en 443 voor een webapplicatie, worden voor u geopend.
- Uitgaand verkeer van de server wordt niet beperkt.
Zonder aangepaste regels toont de sectie "No custom rules. Defaults: SSH + app-stack ports." Dit is een gezonde toestand, geen ontbrekende configuratie.
Een aangepaste regel toevoegen
Voeg een regel toe wanneer u iets uitvoert op een poort die het standaardbeleid niet dekt: een Node-applicatie op 3000, een database die u direct op 5432 moet bereiken, een game- of mediaserver op een UDP-poort.
- Open de sectie Firewall (UFW).
- Voer het Port-nummer in het eerste veld in. Geldige waarden zijn 1 tot 65535.
- Kies TCP of UDP.
- Kies Allow of Deny.
- Klik op Add.
De regel verschijnt in de lijst met een ALLOW- of DENY-badge en de poort en het protocol, bijvoorbeeld 3000/tcp. Deze wordt via de beheerverbinding binnen enkele seconden naar de server gepusht.
U verwijdert een regel door op de X aan het einde van de rij te klikken. Het verwijderen van een Allow-regel sluit die poort onmiddellijk weer.
Het blootstellen van een databasepoort aan het hele internet is een van de meest voorkomende manieren waarop een server wordt aangetast. Voordat u 3306, 5432, 6379 of 27017 toestaat, vraag jezelf af of hetgeen verbinding maakt de database via de loopback-interface van de server zelf of via een particulier netwerk zou kunnen bereiken. Als het echt van buiten bereikbaar moet zijn, zorg er dan voor dat de service zelf sterke authenticatie en versleuteling vereist.
Voeg de regel eerst toe en start de service vervolgens. Een service die achter een gesloten poort wordt opgestart, ziet er precies hetzelfde uit als een service die niet is gestart, en u kunt veel tijd verspillen met het debuggen van de verkeerde laag.
App Stacks
De sectie App stack vertelt het platform welk type applicatie deze server uitvoert, zodat de hardening-voorinstelling erop kan worden afgestemd. Het installeren van een applicatie via het paneel stelt dit voor u in.
De herkende stacks zijn WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web, en No app stack. De sectie beschrijft zichzelf als: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
De stack beïnvloedt welke poorten automatisch openen en hoe de andere beveiligingen worden afgestemd, het meest zichtbaar in fail2ban.
fail2ban
fail2ban controleert verificatiepogingen en blokkeert adressen die steeds mislukken. Het is standaard ingeschakeld en de pagina beschrijft het als: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
Laat het ingeschakeld. Het is de enige goedkoopste beveiliging op de pagina, het kost niets in prestaties, en het verandert een constant achtergrondgeluid van wachtwoordgokpogingen in helemaal niets. Op een WordPress- of WooCommerce-stack beschermt het ook het inlogformulier, wat is waar de meeste aanvallen op WordPress eigenlijk terechtkomen.
ModSecurity, de Web Application Firewall
ModSecurity inspecteert HTTP-aanvragen tegen de OWASP Core Rule Set en markeert de aanvragen die op aanvallen lijken. Op een KapsuleHost server begint het in detection-only modus: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
Detection-only is het juiste startpunt. De Core Rule Set is grondig, en op een echte applicatie zullen sommige legitieme aanvragen een regel aanpassen. Voer het een tijd in detection-only uit, lees de logboeken, bepaal welke regels uw eigen verkeer activeert, en schakel pas daarna over op blokkering in de server.
Het inschakelen van blokkering zonder eerst af te stemmen kan uw site beschadigen. Formulierverzendingen met rich text, bestandsuploads en API-clients met ongebruikelijke payloads zijn meestal de slachtoffers. Controleer uw logboeken voordat u overschakelt.
Automatische OS-patching
Beveiligingsupdates worden voor u toegepast. De sectie legt de vangnet uit: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."
Twee instellingen bevinden zich onder de schakelaar:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). Kernel-updates worden alleen van kracht na een herstart. Als u dit uitschakelt, worden kernelpatches geïnstalleerd maar niet actief totdat u zelf opnieuw opstart.
- Quiet window (UTC), een start- en einduur. Herstarten gebeuren alleen erin. Stel deze in op de rustigste uren voor uw publiek, en onthoud dat het veld in UTC is, niet uw lokale tijd.
Laat auto-patching ingeschakeld. De overgrote meerderheid van de aangetaste servers voert software uit met een patch die weken eerder is gepubliceerd. Een pre-patch snapshot met automatische rollback betekent dat het gebruikelijke bezwaar, dat een update iets kan breken, al wordt afgehandeld.
Patchgeschiedenis en nu een patch uitvoeren
De sectie Patch history bevat elke uitvoering met een status van RUNNING, SUCCESS, ROLLED_BACK, FAILED of SKIPPED, het aantal bijgewerkte pakketten, of de server opnieuw is opgestart, en het moment waarop deze is gestart.
Klik op Run patch now om onmiddellijk een patch uit te voeren in plaats van op het schema te wachten. De bevestiging luidt: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
Een ROLLED_BACK-invoer betekent dat het vangnet zijn werk deed: de server is na een herstart niet schoon terugkomen, dus de pre-patch snapshot is hersteld. Zie Cloud Server Snapshots voor hoe die snapshots werken.
Een verstandige basislijn
Voor de meeste servers is dit de hele beveiligingsconfiguratie:
| Instelling | Aanbevolen |
|---|---|
| Firewall | Aan, standaardregels, plus alleen de poorten die uw app nodig heeft |
| fail2ban | Aan |
| ModSecurity | Aan, detection-only totdat u de logboeken hebt gelezen |
| Automatische OS-patching | Aan, met herstarten toegestaan in een rustig venster |
| SSH-authenticatie | Sleutels, geen wachtwoorden |
De laatste rij staat niet op deze pagina maar is belangrijker dan al het andere bij elkaar. Zie Connecting to Your Cloud Server With SSH.
Probleemoplossing
"Could not load management config." Het paneel kon de instellingen voor deze server niet lezen. Laad opnieuw en controleer of de server bestaat en ingericht is.
"Port must be 1-65535." Het poortveld accepteert een geheel getal in dat bereik. Bereiken en servicenamen worden hier niet geaccepteerd.
Mijn regel is opgeslagen maar er is niets veranderd. Zoek naar de banner "Live apply unavailable". Als dit wordt weergegeven, wordt de wijziging opgeslagen maar nog niet naar de server gepusht.
Ik kan mijn service van het ene netwerk bereiken maar niet van het andere. Dat is meestal uw eigen uitgaande firewall, niet die van de server. Test vanuit een ander apparaat voordat u hier regels wijzigt.
Een patchuitvoering toont FAILED. Lees het foutbericht op de rij. Een volledige schijf is de meest voorkomende oorzaak. Maak ruimte vrij en klik op Run patch now.
Het verkeer van legitieme gebruikers werd geblokkeerd. Als u ModSecurity naar blokkeringsmodus hebt geschakeld, zet het terug op detection-only, lees de logboeken en identificeer de regel voordat u het opnieuw probeert.
Als een firewallregel niet wil worden toegepast, of u bent uitgesloten van een service die u hebt toegestaan, stuurt u een e-mail naar support@kapsulehost.com met de servernaam, de poort en wat u ervan verwacht te bereiken.