Modul 7 · 7.4
At hærde webstedet: rettigheder, headers og sikkerhedsplugins
Modul 7: Sikkerhed · Læsetid: 10 minutter
Læringsmål: Efter denne lektion kan du hærde et WordPress-websted med rettigheder, indstillinger og sikkerhedsheaders, og vurdere sikkerhedsplugins på deres reelle værdi.
Nøglebegreber: hærdning (hardening), filrettigheder (644, 755), DISALLOW_FILE_EDIT, ingen PHP i uploads, mappeliste, skjul version, X-Powered-By, sikkerhedsheaders, backupfiler og .git i webmappen, WAF på serveren, WAF i en plugin, malwarescanner
Hvad hærdning er
Hærdning betyder: at indstille webstedet sådan, at en fejl eller et hul kan gøre mindre skade. Det erstatter ikke opdateringer og stærke adgangskoder (lektion 7.2 og 7.3), men gør konsekvenserne mindre. Tænk på et hus: opdateringer er lågene, hærdning handler om at sikre, at en indbrudstyv, der alligevel er kommet ind, ikke kan nå pengeskabet.
Filrettigheder
Hver fil og hver mappe på serveren har rettigheder: hvem må læse, skrive og udføre. De skrives som tre tal, for ejeren, gruppen og resten af verden. Retningslinjen fra WordPress' dokumentation:
| Hvad | Rettigheder | Betydning |
|---|---|---|
| Mapper | 755 | Ejer må alt, andre må læse og åbne |
| Filer | 644 | Ejer må læse og skrive, andre kun læse |
| wp-config.php | strengere, for eksempel 600 eller 640 | Kun ejeren (og eventuelt webservergruppen) må læse |
Hvilken værdi der virker for wp-config.php, afhænger af, hvordan din hoster kører PHP: ved de fleste delte hostingløsninger kører PHP som din egen bruger, og så er 600 nok. Prøv det, og se om webstedet stadig virker.
Aldrig 777. Det betyder: alle på serveren må skrive. En vejledning, der siger "sæt mappen til 777, hvis upload ikke virker", løser problemet forkert. Ved god hosting er det heller aldrig nødvendigt.
Indstillinger i wp-config.php
Et par linjer, der gør en stor forskel (over "stop redigering"):
// Ingen filredigering fra kontrolpanelet (Udseende > Temaeditor og Plugins > Plugineditor).
define( 'DISALLOW_FILE_EDIT', true );
// Fejlmeddelelser må aldrig vises til besøgende (lektion 5.4).
define( 'WP_DEBUG', false );Med DISALLOW_FILE_EDIT forsvinder editoren, hvormed du kan ændre PHP-filer i temaer og plugins fra kontrolpanelet. En indbrudstyv, der overtager en administratorkonto, kan så ikke med to klik lægge skadelig kode ind i dit tema. Du kan stadig installere plugins; vil du også forbyde det (for eksempel på et websted, du administrerer for en kunde), findes DISALLOW_FILE_MODS, men så virker opdateringer via kontrolpanelet heller ikke længere.
Ingen PHP i uploads, ingen mappeliste
I wp-content/uploads hører billeder og dokumenter til, aldrig PHP-filer. Indbrudstyve, der via et hul kan uploade en fil, forsøger netop at placere en PHP-fil der og hente den. Bloker det med en .htaccess i mappen uploads (ved LiteSpeed og Apache):
<Files *.php>
Require all denied
</Files>Slå også visning af mapper fra. Uden index.php eller index.html i en mappe viser nogle webservere en liste over alle filer ("Index of /wp-content/uploads/2026/11"). Det er en udstillingsvindue for dem, der søger efter backups eller følsomme dokumenter. I .htaccess-filen for din webmappe:
Options -IndexesMange hostere har dette allerede slået fra som standard. Opgaven i denne lektion kontrollerer det.
Ingen rester i webmappen
Alt i webmappen kan hentes via nettet, bortset fra det, serveren kører som PHP eller blokerer. Farlige er:
- kopier af wp-config.php (
wp-config.php.bak,wp-config.old,wp-config.php~fra en teksteditor): de indeholder din databaseadgangskode og sendes som tekst (lektion 1.3); - backups som
backup.zip,site.tar.gzellerdatabase.sqli webmappen; - en
.git-mappe fra en udvikler, hvormed nogen kan downloade hele din kode (og nogle gange adgangskoder); - debug.log i wp-content (lektion 5.4);
- gamle installations- eller testfiler som
info.phpmedphpinfo().
Opbevar backups uden for webmappen eller uden for serveren, og ryd rester op.
Skjule version: lille gevinst
WordPress sætter som standard dette i HTML'en:
<meta name="generator" content="WordPress 7.1.4" />og det samme i RSS-feedet. PHP melder sig også nogle gange i en header: X-Powered-By: PHP/8.3.14. At skjule det er fornuftigt, men forvent ikke for meget af det: indbrudstyves programmer prøver bare et hul, uanset hvilken version du viser, og versioner kan ofte også udledes fra ?ver= bag scripts. At skjule er oprydning, ikke sikkerhed. Et websted, der skjuler sin version, men ikke opdaterer, er lige så sårbart.
Sådan gør du det, i en lille selvstændig plugin eller i functions.php for dit undertema (child theme):
remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );Og PHP-headeren med expose_php = Off i PHP-indstillingerne hos din hoster (i DirectAdmin under Select PHP version, Options), eller med Header unset X-Powered-By i .htaccess.
Sikkerhedsheaders
Med et par headere fortæller du browseren, hvordan den skal håndtere dit websted. De vigtigste:
| Header | Hvad den gør |
|---|---|
Strict-Transport-Security | Kun via https (lektion 3.1) |
X-Content-Type-Options: nosniff | Browseren gætter ikke på, hvilken type fil noget er; forhindrer, at et uploadet "billede" bliver kørt som script |
X-Frame-Options: SAMEORIGIN eller Content-Security-Policy: frame-ancestors 'self' | Andre websteder må ikke vise dit websted i en frame; forhindrer clickjacking (en usynlig knap fra dit websted under et andet) |
Referrer-Policy: strict-origin-when-cross-origin | Ved et klik til et andet websted følger kun dit domænenavn med, ikke hele adressen |
Permissions-Policy | Slår browserfunktioner fra, som dit websted ikke bruger (kamera, mikrofon, placering) |
Content-Security-Policy | Bestemmer præcis, hvilke kilder scripts og stilarter må komme fra. Kraftfuld, men svær at få rigtigt til med WordPress og plugins; begynd med tilstanden Report-Only |
I .htaccess (ved LiteSpeed og Apache):
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>Test derefter, om alt virker: indlejret indhold, betalingsknapper, en chatwidget. Eksterne værktøjer som securityheaders.com og internet.nl viser, hvad dit websted sender.
Sikkerhedsplugins, ærligt vurderet
Der findes mange sikkerhedsplugins (for eksempel Wordfence, Solid Security, All-In-One Security, Sucuri). De samler ofte: en firewall, en malwarescanner, loginbeskyttelse, totrinsbekræftelse, notifikationer og en hærdningsliste. Nyttigt, men med begrænsninger:
- En firewall i en plugin (WAF) starter først, når PHP kører. En skadelig forespørgsel skal først igennem webserveren og PHP, før pluginnet ser den. Et hul i en PHP-fil, der kaldes direkte, eller et angreb, der belaster PHP selv tungt, stopper den ikke altid. En firewall på serveren (for eksempel ModSecurity, Imunify360 eller en firewall fra din hoster) sidder tidligere i kæden og stopper mere, uden at din pakke skal gøre regnearbejdet. Spørg din hoster, hvad der kører på serveren.
- En scanner finder det bagefter. En malwarescanner fortæller dig, at noget er galt. Det er værdifuldt, men det forhindrer ikke noget. Og en scanner på samme server som et hacket websted kan selv også være blevet ændret af indbrudstyven.
- De erstatter ikke opdateringer. En plugin med et kendt hul forbliver sårbar, selv med et sikkerhedsplugin ved siden af. Nogle sikkerhedstjenester tilbyder "virtuelle patches", der stopper kendte angreb, indtil du har opdateret; nyttigt som overgangsløsning, ikke som erstatning.
- De er selv en plugin. Mere kode, mere at opdatere, nogle gange selv et hul. Og to sikkerhedsplugins samtidig kolliderer ofte.
- De koster regnekraft, især scannere, der kører på din egen server.
Et fornuftigt valg: se først, hvad din hoster allerede gør (firewall, malwareskanning, blokering af loginforsøg). Udfyld det, der mangler, oftest totrinsbekræftelse og begrænsning af loginforsøg. Et omfattende sikkerhedsplugin er især nyttigt ved hosting, der selv gør lidt.
Opsummering
- Hærdning begrænser skaden af en fejl eller et hul; det erstatter ikke opdateringer og adgangskoder.
- Mapper 755, filer 644, wp-config.php strengere; aldrig 777.
- Slå DISALLOW_FILE_EDIT til, bloker PHP i uploads, slå mappelister fra, og ryd backups, .git og debug.log ud af webmappen.
- At skjule version er oprydning, ikke sikkerhed; sikkerhedsheaders hjælper browseren med at beskytte dine besøgende.
- En firewall på serveren stopper mere end en plugin; sikkerhedsplugins er et supplement, ikke en erstatning.
Quiz
Opgave
Opgave A7.4: Hvad viser dit websted til alle? Indtast adressen på dit websted. Programmet læser forsiden og RSS-feedet (/feed/) og kontrollerer: er der ingen WordPress-version i generator-tagget i HTML'en og feedet, viser headeren X-Powered-By ingen PHP-version, og sender dit websted X-Content-Type-Options: nosniff, en beskyttelse mod frames (X-Frame-Options eller frame-ancestors) og en Referrer-Policy? HSTS (lektion 3.1) og Permissions-Policy må mangle (orange).
Opgave A7.4b: Ingen rester i webmappen. Bevis, at det er dit eget websted (TXT-record eller fil med opgavens kode). Programmet henter derefter en kort fast liste: mappen /wp-content/uploads/ (ingen mappeliste), /.git/HEAD, /wp-content/debug.log og et par almindelige navne på kopier af wp-config.php. Det er godt, hvis ingen af dem returnerer indhold (404 eller 403). Programmet prøver intet andet og ændrer intet.
Læs mere
Disse artikler beskriver trinnene i panelerne hos WebOké; i andre paneler virker det tilsvarende.
- DirectAdmin vejledning 11.5: Rettigheder til filer og mapper (chmod)
- DirectAdmin vejledning 11.4: Sådan viser og redigerer du skjulte filer som .htaccess
- DirectAdmin vejledning 15.10: Webapplikationsfirewall (WAF)
- DirectAdmin vejledning 15.11: Imunify360: scan din hjemmeside for malware
- Bloker filer via .htaccess, for eksempel plugin-googlemap2-proxy.php
- PHP-sikkerhed
- Hærdning af WordPress (developer.wordpress.org, engelsk): https://developer.wordpress.org/advanced-administration/security/hardening/
- Sikkerhedsheaders (MDN, engelsk): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security
