Härda webbplatsen: behörigheter, headers och säkerhetstillägg

Modul 7: Säkerhet · Lästid: 10 minuter

Lärandemål: Efter den här lektionen kan du härda en WordPress-webbplats med behörigheter, inställningar och säkerhetsheaders, och värdera säkerhetstillägg på rätt sätt.

Nyckelbegrepp: härdning (hardening), filbehörigheter (644, 755), DISALLOW_FILE_EDIT, ingen PHP i uploads, mapplistning, dölja version, X-Powered-By, säkerhetsheaders, säkerhetskopior och .git i webbmappen, WAF på servern, WAF i ett tillägg, malwareskanner

Vad härdning är

Härdning innebär att du ställer in webbplatsen så att ett fel eller en säkerhetslucka kan göra mindre skada. Det ersätter inte uppdateringar och starka lösenord (lektion 7.2 och 7.3), men det gör konsekvenserna mindre. Tänk på ett hus: uppdateringar är låsen, härdning handlar om att se till att en inbrottstjuv som ändå tar sig in inte kommer åt kassaskåpet.

Filbehörigheter

Varje fil och varje mapp på servern har behörigheter: vem som får läsa, skriva och köra. De skrivs som tre siffror, för ägaren, gruppen och resten av världen. Riktlinjen från WordPress dokumentation:

Vilket värde som fungerar för wp-config.php beror på hur ditt webbhotell kör PHP: hos de flesta delade webbhotell körs PHP som din egen användare, och då räcker 600. Prova och kontrollera att webbplatsen fortfarande fungerar.

Aldrig 777. Det betyder att alla på servern får skriva. En guide som säger "sätt mappen till 777 om uppladdningen inte fungerar" löser problemet på fel sätt. Hos ett bra webbhotell behövs det heller aldrig.

Inställningar i wp-config.php

Några rader som gör stor skillnad (ovanför "det räcker, nu kan du sluta redigera"):

// Ingen filredigering från administrationen (Utseende > Temaredigerare och Tillägg > Tilläggsredigerare).
define( 'DISALLOW_FILE_EDIT', true );

// Felmeddelanden ska aldrig visas för besökare (lektion 5.4).
define( 'WP_DEBUG', false );

Med DISALLOW_FILE_EDIT försvinner editorn som du annars kan använda i administrationen för att ändra PHP-filer i teman och tillägg. En inkräktare som tar över ett administratörskonto kan då inte med två klick lägga in skadlig kod i ditt tema. Du kan fortfarande installera tillägg; vill du förbjuda även det (till exempel på en webbplats du förvaltar åt en kund), finns DISALLOW_FILE_MODS, men då slutar även uppdateringar via administrationen att fungera.

Ingen PHP i uploads, ingen mapplistning

I wp-content/uploads hör bilder och dokument hemma, aldrig PHP-filer. Inkräktare som via en säkerhetslucka kan ladda upp en fil försöker just placera en PHP-fil där och sedan anropa den. Blockera det med en .htaccess i mappen uploads (för LiteSpeed och Apache):

<Files *.php>
Require all denied
</Files>

Stäng också av visning av mapplistor. Utan index.php eller index.html i en mapp visar vissa webbservrar en lista över alla filer ("Index of /wp-content/uploads/2026/11"). Det är ett skyltfönster för den som letar efter säkerhetskopior eller känsliga dokument. I .htaccess för din webbmapp:

Options -Indexes

Många webbhotell har redan stängt av det här som standard. Uppgiften i den här lektionen kontrollerar det.

Inga rester i webbmappen

Allt i webbmappen går att hämta via webben, förutom det som servern kör som PHP eller blockerar. Farligt är:

• kopior av wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ från en textredigerare): de innehåller ditt databaslösenord och skickas som ren text (lektion 1.3);
• säkerhetskopior som backup.zip, site.tar.gz eller database.sql i webbmappen;
• en .git-mapp från en utvecklare, som gör att någon kan ladda ner hela din kod (och ibland lösenord);
• debug.log i wp-content (lektion 5.4);
• gamla installations- eller testfiler som info.php med phpinfo().

Spara säkerhetskopior utanför webbmappen eller utanför servern, och städa bort rester.

Dölja version: liten vinst

WordPress lägger som standard in detta i HTML:en:

<meta name="generator" content="WordPress 7.1.4" />

och samma sak i RSS-flödet. Även PHP avslöjar sig ibland i en header: X-Powered-By: PHP/8.3.14. Att dölja det är rimligt, men förvänta dig inte för mycket: angriparnas program testar en säkerhetslucka oavsett vilken version du visar, och versioner kan ofta också avläsas via ?ver= efter skript. Att dölja är städning, inte säkerhet. En webbplats som döljer sin version men inte uppdateras är precis lika sårbar.

Så här gör du, i ett eget litet tillägg eller i functions.php i ditt barntema:

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

Och PHP-headern med expose_php = Off i PHP-inställningarna hos ditt webbhotell (i DirectAdmin under Select PHP version, Options), eller med Header unset X-Powered-By i .htaccess.

Säkerhetsheaders

Med några headers talar du om för webbläsaren hur den ska hantera din webbplats. De viktigaste:

I .htaccess (för LiteSpeed och 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>

Testa sedan att allt fungerar: inbäddat innehåll, betalknappar, en chattwidget. Externa verktyg som securityheaders.com och internet.nl visar vad din webbplats skickar.

Säkerhetstillägg, ärligt bedömda

Det finns många säkerhetstillägg (till exempel Wordfence, Solid Security, All-In-One Security, Sucuri). De kombinerar ofta: en brandvägg, en malwareskanner, inloggningsskydd, tvåfaktorsautentisering, meddelanden och en härdningslista. Användbart, men med begränsningar:

• En brandvägg i ett tillägg (WAF) startar först när PHP körs. En skadlig förfrågan måste först passera webbservern och PHP innan tillägget ser den. En säkerhetslucka i en PHP-fil som anropas direkt, eller en attack som belastar PHP kraftigt, stoppar den inte alltid. En brandvägg på servern (till exempel ModSecurity, Imunify360 eller en brandvägg från ditt webbhotell) sitter tidigare i kedjan och stoppar mer, utan att ditt tillägg behöver göra beräkningsarbetet. Fråga ditt webbhotell vad som körs på servern.
• En skanner hittar i efterhand. En malwareskanner talar om för dig att något är fel. Det är värdefullt, men det förhindrar ingenting. Och en skanner på samma server som en hackad webbplats kan också själv ha manipulerats av inkräktaren.
• De ersätter inte uppdateringar. Ett tillägg med en känd säkerhetslucka förblir sårbart, även med ett säkerhetstillägg bredvid. Vissa säkerhetstjänster erbjuder "virtuella patchar" som stoppar kända attacker tills du har uppdaterat; praktiskt som en tillfällig lösning, inte som ersättning.
• De är själva ett tillägg. Mer kod, mer att uppdatera, ibland en säkerhetslucka i sig själva. Och två säkerhetstillägg samtidigt krockar ofta.
• De kostar prestanda, särskilt skanners som körs på din egen server.

Ett rimligt val: titta först på vad ditt webbhotell redan gör (brandvägg, malwareskanning, blockering av inloggningsförsök). Komplettera det som saknas, oftast tvåfaktorsautentisering och begränsning av inloggningsförsök. Ett omfattande säkerhetstillägg är mest användbart hos webbhotell som själva gör lite.

Sammanfattning

• Härdning begränsar skadan av ett fel eller en säkerhetslucka; det ersätter inte uppdateringar och lösenord.
• Mappar 755, filer 644, wp-config.php strängare; aldrig 777.
• Aktivera DISALLOW_FILE_EDIT, blockera PHP i uploads, stäng av mapplistningar och städa bort säkerhetskopior, .git och debug.log från webbmappen.
• Att dölja versionen är städning, inte säkerhet; säkerhetsheaders hjälper webbläsaren att skydda dina besökare.
• En brandvägg på servern stoppar mer än ett tillägg; säkerhetstillägg är ett komplement, inte en ersättning.

Quiz

Uppgift

Uppgift A7.4: Vad visar din webbplats för alla? Fyll i adressen till din webbplats. Programmet läser startsidan och RSS-flödet (/feed/) och kontrollerar: finns det ingen WordPress-version i generator-taggen i HTML:en och flödet, visar headern X-Powered-By ingen PHP-version, och skickar din webbplats X-Content-Type-Options: nosniff, ett skydd mot frames (X-Frame-Options eller frame-ancestors) och en Referrer-Policy? HSTS (lektion 3.1) och Permissions-Policy får saknas (orange).

Uppgift A7.4b: Inga rester i webbmappen. Bevisa att det är din egen webbplats (TXT-post eller fil med koden från uppgiften). Programmet hämtar sedan en kort fast lista: mappen /wp-content/uploads/ (ingen mapplistning), /.git/HEAD, /wp-content/debug.log och några vanliga namn på kopior av wp-config.php. Godkänt är om ingen av dem returnerar innehåll (404 eller 403). Programmet testar inget annat och ändrar inget.

Läs mer

De här artiklarna beskriver stegen i WebOkés paneler; i andra paneler fungerar det på liknande sätt.

• DirectAdmin-guide 11.5: Behörigheter för filer och mappar (chmod)
• DirectAdmin-guide 11.4: Visa och redigera dolda filer som .htaccess
• DirectAdmin-guide 15.10: Brandvägg för webbapplikationer
• DirectAdmin-guide 15.11: Imunify360: skanna din webbplats efter skadlig kod
• Blockera filer via .htaccess, till exempel plugin-googlemap2-proxy.php
• PHP-säkerhet
• Härda WordPress (developer.wordpress.org, Engelska): https://developer.wordpress.org/advanced-administration/security/hardening/
• Säkerhetsheaders (MDN, Engelska): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security