Herde nettstedet: rettigheter, headere og sikkerhetsutvidelser

Modul 7: Sikkerhet · Lesetid: 10 minutter

Læringsmål: Etter denne leksjonen kan du herde et WordPress-nettsted med rettigheter, innstillinger og sikkerhetsheadere, og vurdere sikkerhetsutvidelser på deres faktiske verdi.

Nøkkelbegreper: herding (hardening), filrettigheter (644, 755), DISALLOW_FILE_EDIT, ingen PHP i uploads, mappeliste, skjule versjon, X-Powered-By, sikkerhetsheadere, sikkerhetskopifiler og .git i webmappen, WAF på serveren, WAF i en utvidelse, skadevarescanner

Hva herding er

Herding betyr: å stille inn nettstedet slik at en feil eller et sikkerhetshull gjør mindre skade. Det erstatter ikke oppdateringer og sterke passord (leksjon 7.2 og 7.3), men gjør konsekvensene mindre. Tenk på et hus: oppdateringer er låsene, herding er å sørge for at en innbruddstyv som likevel kommer inn, ikke kommer til safen.

Filrettigheter

Hver fil og mappe på serveren har rettigheter: hvem som får lese, skrive og kjøre. De skrives som tre siffer, for eieren, gruppen og resten av verden. Retningslinjen fra WordPress-dokumentasjonen:

Hvilken verdi som fungerer for wp-config.php, avhenger av hvordan webhotellet ditt kjører PHP: hos de fleste delte webhotell kjører PHP som din egen bruker, og da er 600 nok. Prøv det og se om nettstedet fortsatt fungerer.

Aldri 777. Det betyr: alle på serveren får skrive. En veiledning som sier «sett mappen til 777 hvis opplastingen ikke fungerer», løser problemet på feil måte. Hos et godt webhotell er det heller aldri nødvendig.

Innstillinger i wp-config.php

Noen linjer som utgjør stor forskjell (over «stopp redigering»):

// Ingen filredigering fra administrasjonen (Utseende > Temaredigering og Utvidelser > Utvidelsesredigering).
define( 'DISALLOW_FILE_EDIT', true );

// Feilmeldinger skal aldri vises på skjermen til besøkende (leksjon 5.4).
define( 'WP_DEBUG', false );

Med DISALLOW_FILE_EDIT forsvinner redigeringsverktøyet du ellers kunne brukt i administrasjonen til å endre PHP-filer i temaer og utvidelser. En innbruddstyv som overtar en administratorkonto, kan da ikke legge ondsinnet kode i temaet ditt med to klikk. Du kan fortsatt installere utvidelser; vil du forby også det (for eksempel på et nettsted du administrerer for en kunde), finnes DISALLOW_FILE_MODS, men da slutter også oppdateringer via administrasjonen å fungere.

Ingen PHP i uploads, ingen mappeliste

I wp-content/uploads hører bilder og dokumenter hjemme, aldri PHP-filer. Innbruddstyver som får lastet opp en fil gjennom et sikkerhetshull, prøver nettopp å legge inn en PHP-fil og så hente den. Blokker dette med en .htaccess i uploads-mappen (for LiteSpeed og Apache):

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

Skru også av visning av mappeinnhold. Uten index.php eller index.html i en mappe viser noen webservere en liste over alle filene («Index of /wp-content/uploads/2026/11»). Det er et utstillingsvindu for alle som leter etter sikkerhetskopier eller sensitive dokumenter. I .htaccess-filen i webmappen din:

Options -Indexes

Mange webhotell har dette allerede skrudd av som standard. Oppgaven i denne leksjonen kontrollerer det.

Ingen rester i webmappen

Alt i webmappen kan hentes via nettet, bortsett fra det serveren kjører som PHP eller blokkerer. Farlige eksempler er:

• kopier av wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ fra en tekstredigerer): disse inneholder databasepassordet ditt og sendes ut som ren tekst (leksjon 1.3);
• sikkerhetskopier som backup.zip, site.tar.gz eller database.sql i webmappen;
• en .git-mappe fra en utvikler, som gjør at noen kan laste ned hele koden din (og noen ganger passord);
• debug.log i wp-content (leksjon 5.4);
• gamle installasjons- eller testfiler som info.php med phpinfo().

Oppbevar sikkerhetskopier utenfor webmappen eller utenfor serveren, og rydd opp rester.

Skjule versjon: liten gevinst

WordPress legger som standard dette i HTML-koden:

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

og det samme i RSS-feeden. Også PHP melder seg noen ganger i en header: X-Powered-By: PHP/8.3.14. Å skjule dette er fornuftig, men forvent ikke for mye av det: programmene til innbruddstyver prøver et sikkerhetshull uansett, uavhengig av versjonen du viser, og versjoner kan ofte også leses ut av ?ver= bak skript. Å skjule er opprydding, ikke sikkerhet. Et nettsted som skjuler versjonen sin men ikke oppdaterer, er like sårbart.

Slik gjør du det, i en egen liten utvidelse eller i functions.php til undertemaet ditt (child theme):

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

Og PHP-headeren med expose_php = Off i PHP-innstillingene hos webhotellet ditt (i DirectAdmin under Select PHP version, Options), eller med Header unset X-Powered-By i .htaccess.

Sikkerhetsheadere

Med noen få headere forteller du nettleseren hvordan den skal forholde seg til nettstedet ditt. De viktigste:

I .htaccess (for 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 etterpå om alt fungerer: innebygd innhold, betalingsknapper, en chat-widget. Eksterne verktøy som securityheaders.com og internet.nl viser hva nettstedet ditt sender.

Sikkerhetsutvidelser, ærlig vurdert

Det finnes mange sikkerhetsutvidelser (for eksempel Wordfence, Solid Security, All-In-One Security, Sucuri). De pakker ofte sammen: en brannmur, en skadevarescanner, innloggingsbeskyttelse, tofaktorautentisering, varsler og en herdeliste. Nyttig, men med begrensninger:

• En brannmur i en utvidelse (WAF) starter først når PHP kjører. En ondsinnet forespørsel må først gjennom webserveren og PHP før utvidelsen ser den. Et sikkerhetshull i en PHP-fil som kalles direkte, eller et angrep som belaster PHP tungt i seg selv, stopper den ikke alltid. En brannmur på serveren (for eksempel ModSecurity, Imunify360 eller en brannmur fra webhotellet ditt) sitter tidligere i kjeden og stopper mer, uten at din egen pakke gjør regnearbeidet. Spør webhotellet ditt hva som kjører på serveren.
• En scanner finner i etterkant. En skadevarescanner forteller deg at noe er galt. Det er verdifullt, men det forhindrer ingenting. Og en scanner på samme server som et hacket nettsted kan selv ha blitt endret av innbruddstyven.
• De erstatter ikke oppdateringer. En utvidelse med et kjent sikkerhetshull forblir sårbar, selv med en sikkerhetsutvidelse ved siden av. Noen sikkerhetstjenester tilbyr «virtuelle patcher» som stopper kjente angrep til du har oppdatert; nyttig som overgang, ikke som erstatning.
• De er selv en utvidelse. Mer kode, mer å oppdatere, noen ganger selv et sikkerhetshull. Og to sikkerhetsutvidelser samtidig kolliderer ofte.
• De koster regnekraft, spesielt scannere som kjører på din egen server.

Et fornuftig valg: se først hva webhotellet ditt allerede gjør (brannmur, skadevarescanning, blokkering av innloggingsforsøk). Fyll på det som mangler, som oftest tofaktorautentisering og begrensning av innloggingsforsøk. En omfattende sikkerhetsutvidelse er mest nyttig ved webhotell som selv gjør lite.

Oppsummering

• Herding begrenser skaden av en feil eller et sikkerhetshull; det erstatter ikke oppdateringer og passord.
• Mapper 755, filer 644, wp-config.php strengere; aldri 777.
• Skru på DISALLOW_FILE_EDIT, blokker PHP i uploads, skru av mappelister og rydd bort sikkerhetskopier, .git og debug.log fra webmappen.
• Å skjule versjonen er opprydding, ikke sikkerhet; sikkerhetsheadere hjelper nettleseren med å beskytte de besøkende dine.
• En brannmur på serveren stopper mer enn en utvidelse; sikkerhetsutvidelser er et supplement, ikke en erstatning.

Quiz

Oppgave

Oppgave A7.4: Hva viser nettstedet ditt til alle? Fyll inn adressen til nettstedet ditt. Programmet leser forsiden og RSS-feeden (/feed/) og kontrollerer: at det ikke står noen WordPress-versjon i generator-taggen i HTML-koden og feeden, at headeren X-Powered-By ikke viser noen PHP-versjon, og at nettstedet ditt sender X-Content-Type-Options: nosniff, en beskyttelse mot rammer (X-Frame-Options eller frame-ancestors) og en Referrer-Policy? HSTS (leksjon 3.1) og Permissions-Policy kan mangle (oransje).

Oppgave A7.4b: Ingen rester i webmappen. Bevis at det er ditt eget nettsted (TXT-record eller fil med koden fra oppgaven). Programmet ber deretter om en kort, fast liste: mappen /wp-content/uploads/ (ingen mappeliste), /.git/HEAD, /wp-content/debug.log og noen vanlige navn på kopier av wp-config.php. Godt er om ingen av dem gir tilbake innhold (404 eller 403). Programmet prøver ikke noe annet og endrer ingenting.

Les mer

Disse artiklene beskriver trinnene i kontrollpanelene til WebOké; i andre kontrollpaneler fungerer de på lignende måte.

• DirectAdmin-veiledning 11.5: Rettigheter for filer og mapper (chmod)
• DirectAdmin-veiledning 11.4: Vise og redigere skjulte filer som .htaccess
• DirectAdmin-veiledning 15.10: Web Application Firewall
• DirectAdmin-veiledning 15.11: Imunify360: skann nettstedet ditt for skadevare
• Blokker filer via .htaccess, for eksempel plugin-googlemap2-proxy.php
• PHP-sikkerhet
• Herding av WordPress (developer.wordpress.org, engelsk): https://developer.wordpress.org/advanced-administration/security/hardening/
• Sikkerhetsheadere (MDN, engelsk): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security