Het eerste uur: een kleiner aanvalsoppervlak.

Verifieer en behoud toegang

Bevestig de serveridentiteit via een vertrouwd kanaal en voeg uw SSH publieke sleutel toe. Maak een benoemde beheerdersgebruiker aan. Houd de oorspronkelijke sessie open terwijl u de nieuwe test en leg de herstelmethode vast voordat u de authenticatie wijzigt.

Patch en beperk blootstelling

Installeer ondersteunde beveiligingsupdates en herstart indien nodig. Controleer luisterende services en sta alleen de noodzakelijke poorten toe in de firewall, inclusief IPv6. Verwijder ongebruikte daemons en open een database niet publiekelijk alleen om de installatie eenvoudiger te maken.

Gescheiden gebruikers en geheimen

Voer applicaties uit onder hun eigen accounts. Plaats privéconfiguratie buiten de openbare webmap en sluit deze uit van versiebeheer. Gebruik beperkte databaserechten en afzonderlijke inloggegevens voor productie en experimenten.

Laat een werkend herstelpad achter

Stel logrotatie, schijfalarmen en een aparte back-up in. Herstart één keer om te verifiëren dat de applicatie correct start. Leg vast wat is gewijzigd, zodat de configuratie op een schone image kan worden herbouwd.

Controleer voordat u de sessie sluit

Open een tweede verbinding met het nieuwe account, verifieer administratieve verhoging en test de firewall vanaf een andere client. Bevestig dat de service terugkeert na een herstart. Documenteer de herstelroute van de provider, zodat een foutieve netwerkregel geen geïmproviseerd herstel vereist.

Een verificatielijst voor de eerste dag

Controleer open sockets, recente authenticatiegebeurtenissen, updatestatus, back-upleeftijd en schijfgebruik. Controleer dat privéconfiguratie en versiebeheer-metadata niet via HTTP kunnen worden opgehaald. Gebruik de kleinste set geïnstalleerde tools die de werkelijke workload ondersteunt.

ss -lntup
df -h
free -h
systemctl --failed

Voer toegangswijzigingen uit in een omkeerbare volgorde

Bevestig eerst de console- of reddingsroute en verifieer de SSH host-sleutel via een vertrouwd providerkanaal. Installeer de openbare sleutel voor een benoemde beheerder, open vervolgens een tweede verbinding en test de rechtenverhoging. Valideer de syntaxis van de SSH configuratie voordat u de dienst herlaadt. Pas firewallwijzigingen pas toe nadat de beoogde SSH route is toegestaan. Schakel een oude authenticatiemethode pas uit nadat de vervanging werkt vanuit een nieuwe sessie, inclusief de vereiste tweefactorstroom.

• Controleer de effectieve configuratie en de inbegrepen snippets; een instelling in één bestand is mogelijk niet het uiteindelijke beleid.
• Controleer zowel wachtwoordauthenticatie als het keyboard-interactive-beleid bij het beoordelen van een op sleutels gebaseerd loginontwerp.
• Een niet-standaard SSH-poort kan achtergrondruis verminderen, maar vervangt geen geverifieerde sleutels, toegangsbeperkingen of updates.
• Gebruik de servicenaam en herlaadprocedure voor uw distributie. Houd de oorspronkelijke sessie open totdat het nieuwe beleid is bewezen.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Officiële documentatie: OpenSSH: handleiding voor serverconfiguratie

Bewijs de firewall van buitenaf

Beoordeel de providernetwerkfirewall en de gastfirewall als afzonderlijke maatregelen. Test de beoogde service via IPv4 en IPv6 vanaf een andere geautoriseerde machine. Een lokale verbinding bewijst alleen dat een proces luistert. Blokkeer niet blindelings elk ICMP-pakket: normaal netwerkverkeer heeft ook passend controleverkeer nodig. Controleer de door containers gepubliceerde poorten tegen de werkelijke regels, want de blootstelling van de applicatie komt mogelijk niet overeen met het beleid waarvan je dacht dat een firewallfront-end het had toegepast.

• Als SSH mislukt, controleer dan bronadresbeperkingen, de luisterende interface en de providerfirewall voordat je herhaaldelijk sleutels wijzigt.
• Als HTTPS mislukt, controleer dan DNS, de proceslistener en de lokale/proxy-firewall in die volgorde.
• Controleer vóór de eerste productiedataset de updatestatus, een schone herstart, schijfalarmen en een onafhankelijk herstelbare back-up.
• Stel een gedocumenteerde tijdzone in en verifieer de tijdsynchronisatie. Voeg geen willekeurige swap- of loginstellingen toe zonder de geheugen- en bewaarbehoeften van de workload te controleren.

Officiële documentatie: Ubuntu Server: firewallbeheer