Security Pilot

Security Pilot er et komplet WordPress-sikkerhedsplugin, der hærder dit site mod almindelige angreb og sårbarheder. Det sætter branchestandardiserede HTTP-sikkerhedsheaders, beskytter login-siden mod brute-force-angreb, blokerer ondsindede requests med en indbygget firewall, begrænser følsomme REST API-endpoints og leverer en audit med ét klik, der giver installationen en karakter fra A til F.

I modsætning til opblæste sikkerhedssuiter er Security Pilot let og modulært: aktiver kun de beskyttelser, du har brug for. Hvert modul kan slås til og fra hver for sig, og alle indstillinger styres fra topmenuen Security Pilot i WordPress’ admin-sidebar.

Højdepunkter

• HTTP-sikkerhedsheaders — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection samt fjernelse af X-Powered-By-headeren.
• Login-beskyttelse — justerbar rate-limit, midlertidige lockouts og permanente bans af gengangere, med valgfri mail-alerts.
• Request-firewall — mønsterbaseret detektion af SQL-injection, cross-site scripting (XSS), path traversal, remote file inclusion (RFI) og command injection.
• REST API-beskyttelse — bloker uautoriseret adgang til følsomme endpoint-grupper som /wp/v2/users, WooCommerce, Jetpack, wp-site-health, Divi Builder og Elementor.
• WordPress-hærdning — slå filredigereren og XML-RPC fra, dæmp pingbacks og trackbacks, skjul WordPress-versionen, fjern RSD-linket og Windows Live Writer-manifestet.
• Rate limiter — throttling pr. IP for 404-storme og andre høj-frekvente request-mønstre, med justerbar max-block-tæller og rullende tidsvindue.
• Formularbeskyttelse — rate-limit på indsendelser fra frontend, blokering af engangsmail-domæner og bot-fælder via skjulte honeypot-felter og et justerbart tid-til-udfyldning-tjek.
• Security Check — audit med ét klik, der giver installationen en karakter fra A til F og rapporterer status pr. check (PASS / WARNING / FAIL) på hærdning, REST API-eksponering, forældede plugins/themes, debug-indstillinger, filredigerer og meget mere.
• Adgangsregler og angrebslog — administrer Blokerede IP’er, Whitelistede IP’er og Whitelistede URL’er fra en skærm med tre faner, og dyk ned i hver blokeret request i angrebsloggen.

Krav

Security Pilot er designet til moderne, selv-hostede WordPress-sites.

• En fungerende WordPress-installation med administratoradgang.
• En PHP-version, der understøttes af din nuværende WordPress-udgivelse.
• HTTPS anbefales kraftigt. HSTS-headeren bør kun slås til, når sitet kan nås over TLS på hver URL, inklusive de subdomæner, du ønsker dækket.
• Tilstrækkelige rettigheder til at ændre HTTP-responseheaders. På de fleste managed hosts virker det ud af boksen; foran nogle reverse proxies eller CDN’er kan headerne kræve at blive sluppet igennem ved kanten.

Der er ingen eksterne tjenester at konfigurere, og ingen API-nøgler er nødvendige. Indstillinger, logs og blokeringslister gemmes i din egen WordPress-database.

Installation

1. Hent Security Pilot-pluginets ZIP.
2. Åbn i WordPress Plugins → Tilføj nyt → Upload plugin.
3. Vælg ZIP-filen, og vælg Installer nu.
4. Klik på Aktiver plugin, når uploaden er færdig.
5. Åbn Security Pilot → Indstillinger for at gennemgå modulerne. De fire undermenupunkter er, i den rækkefølge de optræder, Security Check, Adgangsregler, Angrebslog og Indstillinger.

Efter aktivering tvinges ingen beskyttelse på — hvert modul starter i en kendt tilstand og kan slås til en ad gangen. Det gør det sikkert at installere pluginet på et produktionssite og indføre hærdning i små, omvendelige skridt.

Konfiguration

Al konfiguration sker fra Security Pilot → Indstillinger. Siden grupperer indstillingerne i moduler — hvert modul er et sammenklappeligt kort med sin egen til/fra-kontakt og et lille antal valg.

Et Licens-kort øverst tager imod en PILOT-XXXX-XXXX-XXXX-XXXX-nøgle (fra din ordrebekræftelse) og aktiverer automatiske plugin-opdateringer fra GitHub-release-feedet, når nøglen er verificeret. Pluginet virker fuldt uden en nøgle; kun den automatiske opdateringskanal er låst.

HTTP-sikkerhedsheaders

Headers-modulet tilføjer standardbaserede HTTP-responseheaders til hver request, der serveres gennem WordPress. Slå enkelte headers til eller fra efter sitets behov.

Et par bemærkninger til konfigurationen af headers:

• HSTS er permanent i browseren, så snart den er modtaget. Bekræft, at HTTPS virker overalt — inklusive www og enhver subdomæne, du vil have med — før du slår den til.
• Content-Security-Policy er den mest kraftfulde og den mest påtrængende header. Start med de report-venlige defaults, og stram derefter policyen op, efter at du har tjekket browser-konsollen for blokerede ressourcer på dine rigtige sider.
• Hvis dit site sidder bag et CDN eller en reverse proxy, der omskriver headers, så sørg for, at de edges sender de værdier, Security Pilot tilføjer, uændrede igennem.

Login-beskyttelse

Login-beskyttelsen tæller fejlede godkendelsesforsøg pr. IP-adresse og udløser en lockout, når en tærskel rammes. Efter et konfigurerbart antal lockouts kan IP’en bannes permanent.

Tilgængelige indstillinger:

• Maks. fejlede forsøg — antal fejlede logins fra en IP, før en lockout udløses. Tager værdier fra 1 til 20. Standard 5 er et fornuftigt udgangspunkt.
• Forsøgsvindue — det rullende tidsvindue, i minutter, der bruges til at tælle fejl. Tager værdier fra 1 til 120.
• Lockout-varighed — hvor længe en låst IP holdes blokeret, i minutter. Tager værdier fra 1 til 1440 (24 timer).
• Tærskel for permanent ban — antal separate lockouts, en IP kan akkumulere, før den bannes permanent. Tager værdier fra 1 til 20.
• Mail-alerts — når slået til, modtager site-administratoren en mail, hver gang et angreb opdages, og hver gang en IP føjes til blokeringslisten.
• Skjul detaljerede fejlmeddelelser — generiske fejlmeddelelser (“ugyldige credentials”) erstatter WordPress’ standardmeddelelser og forhindrer angribere i at finde ud af, om et brugernavn eksisterer.

Beskyttelsen gælder både wp-login.php og det standard XML-RPC-godkendelses-endpoint, så længe XML-RPC stadig er slået til.

Request-firewall

Request-firewallen inspicerer indgående requests for ondsindede mønstre og returnerer et 403 Forbidden-svar, når et mønster genkendes. Detektionsmønstrene er indbyggede og dækker:

• SQL-injection — almindelige payloads mod query-parametre, POST-bodies og cookies.
• Cross-site scripting (XSS) — signaturer for reflekterede og lagrede angreb.
• Path traversal — ../-stil-forsøg på at undslippe document root.
• Remote file inclusion (RFI) — referencer til eksterne URL’er i kontekster, hvor lokale stier forventes.
• Command injection — shell-metategn i parametre, der sandsynligt rammer system-lignende funktioner.

Firewallen har ingen konfiguration pr. regel. Den er enten slået til eller fra. Blokerede requests registreres i angrebsloggen beskrevet nedenfor, inklusive den fornærmende parameter og den regel, der udløste blokeringen.

Rate Limiter (404-flod-beskyttelse)

Sites under brute-force-probing brænder hundredvis af 404-svar af pr. IP pr. minut på jagt efter skjulte plugin-assets eller wp-config-backups. Rate limiteren lægger loft over den trafik pr. kilde-IP ved at spore 404-hits i et rullende vindue:

Blokeringen håndhæves af samme mekanisme som Login-beskyttelsen, så den dukker op på fanen Adgangsregler → Blokerede IP’er med årsagen 404_flood.

REST API-beskyttelse

WordPress eksponerer et stort REST API som standard, herunder endpoints, der er nyttige for site-builders, men ofte unødvendige på et produktionssite. Security Pilot kan blokere uautentificeret adgang til hele endpoint-grupper og lade resten af API’en være i fred.

Beskyttede grupper:

• /wp/v2/users — bruger-enumeration via kernens users-endpoint.
• WooCommerce — butiks-, ordre- og kundeendpoints udstillet af WooCommerce, når det er installeret.
• Jetpack — Jetpacks eget REST-namespace.
• wp-site-health — health-check-endpoints, der kan lække information om miljøet.
• Divi Builder — Divis REST-endpoints.
• Elementor — Elementors REST-endpoints.

Slå kun beskyttelse til for de grupper, du ikke har brug for. For eksempel kan et site uden WooCommerce trygt låse for WooCommerce-endpointene. Pluginet kontrollerer autentificering på hvert request og returnerer en autorisationsfejl for uautentificerede kald til en beskyttet gruppe.

Formularbeskyttelse

Beskytter kontakt-/kommentar-/login-formularer på hele sitet mod spam, engangsmail-tilmeldinger og bot-indsendelser i højt tempo:

Honeypot-fælder (skjulte felter, kun bots udfylder) og et minimum tid-til-udfyldning-tjek kører sammen med rate-portene. Blokerede forsøg logges i angrebsloggen.

WordPress-hærdning

Hærdningsmodulet slår WordPress-funktioner fra, som ofte misbruges eller røber information, angribere kan bruge til at planlægge et exploit. Hvert valg er uafhængigt.

• Slå filredigereren fra — slukker for den indbyggede theme- og plugin-filredigerer (DISALLOW_FILE_EDIT). En angriber, der skaffer sig admin-credentials, kan ikke længere ændre kode direkte fra WordPress’ brugerflade.
• Slå XML-RPC fra — blokerer xmlrpc.php-endpointet, der er et hyppigt mål for brute-force- og amplification-angreb. Slå kun XML-RPC fra, hvis ingen integration på sitet er afhængig af det.
• Slå pingbacks og trackbacks fra — lukker en gammel amplification-vektor, der er blevet brugt i DDoS-kampagner.
• Skjul WordPress-version — fjerner generator-meta-tagget og versions-query-parametre fra enqueuede assets, så den installerede WordPress-version ikke avertereres i sidens kilde.
• Fjern RSD-link — dropper Really Simple Discovery-linket, som eksterne publiceringsklienter bruger.
• Fjern WLW-manifest — fjerner Windows Live Writer-manifestets link, der sjældent er nyttigt i dag.

På de fleste produktionssites er det trygt at slå alle hærdningsvalg til. At slå filredigereren og XML-RPC fra er især en grundlæggende anbefaling fra WordPress-sikkerhedsmiljøet.

Security Check

Security Check-siden — Security Pilot → Security Check — kører en audit med ét klik og giver en bogstavkarakter fra A (“fremragende, din sikkerhed er stærk”) ned til F, sammen med KPI-tællere for samlet bestået, fejlet, advarsel og checks i alt.

Checket dækker hver kategori, pluginet kan verificere indefra WordPress, herunder (men ikke begrænset til):

• HTTPS konfigureret for sitets URL.
• Filredigerer slået fra (DISALLOW_FILE_EDIT).
• XML-RPC slået fra.
• Debug-logning og debug-display slået fra i produktion.
• Adgang til wp-config.php blokeret på webserverniveau.
• WordPress-kerne, plugins og themes opdaterede.
• Inaktive plugins stadig installeret (angrebsflade).
• Standard-brugernavnet admin ikke i brug.
• REST API-beskyttelse slået til.
• HTTP-sikkerhedsheaders, login-beskyttelse og request-firewall aktive.
• Stærk DB-prefix, PHP-eksponering, server-signatur.

Hver række viser en kort titel, en linje med beskrivelse og et status-badge (PASS, WARNING, FAIL, INFO). Modulet Indstillinger → Security Check byder på tre opt-in-kontakter, der tilføjer dybere checks (forældede plugins, forældede themes, opslag i en offentlig sårbarheds-feed for plugins) — de kører, når rapporten genereres, og sløver den med få sekunder, så de er slået fra som standard. Fra selve rapporten ligger fixene typisk et klik væk i WordPress-administrationen (opdater plugin, slet inaktivt plugin, vip en hærdningskontakt).

Brug

Et praktisk første gennemløb af pluginet ser sådan ud.

1. Installer og aktiver Security Pilot.
2. Åbn Security Pilot → Indstillinger.
3. Slå HTTP-sikkerhedsheaders til med de anbefalede defaults. Besøg et par sider på sitet, og tjek browser-konsollen for uventede Content-Security-Policy-overtrædelser.
4. Slå login-beskyttelse til. Lad Maks. fejlede forsøg stå på 5, vælg et 15-minutters forsøgsvindue og en 60-minutters lockout til et typisk site. Slå mail-alerts til, så du opdager det, når sitet angribes.
5. Slå request-firewallen til. Ingen yderligere konfiguration er nødvendig.
6. Slå rate limiteren til for at fange 404-storme (standard 25 hits på 60 sekunder → IP på blokeringslisten).
7. Slå REST API-beskyttelse til for de endpoint-grupper, sitet ikke bruger offentligt. /wp/v2/users-gruppen er næsten altid sikker at låse.
8. Slå formularbeskyttelse til på sites med kontakt-/kommentar- formularer — vælg en fornuftig cooldown pr. IP og en TLD-blokliste.
9. Slå WordPress-hærdningsvalgene til. Som minimum: slå filredigereren og XML-RPC fra på produktionssites.
10. Kør et Security Check og handl på hver WARNING- og FAIL-række (opdater eller slet de nævnte plugins og themes, vip de markerede hærdningskontakter).

Efter dette første gennemløb: vend periodisk tilbage til Security Pilot → Security Check for at holde karakteren over C, og til Angrebslog + Adgangsregler for at gennemgå, hvad der blev fanget.

Gennemgå adgangsregler

Skærmen Adgangsregler (Security Pilot → Adgangsregler) er en central styring med tre faner for IP- og URL-baserede blokerings- og whitelistlister:

• Blokerede IP’er — hver adresse, der i øjeblikket blokeres af Login-beskyttelsen, rate limiteren eller firewallen. Hver række viser IP’en, blokeringsårsagen (f.eks. firewall:path_traversal, 404_flood, firewall:sqli), tidspunktet, den blev tilføjet, og en Lås op-knap. En enkel formular øverst lader dig manuelt blokere en vilkårlig IP med en valgfri årsag, og et søgefelt filtrerer på IP eller årsag.
• Whitelistede IP’er — adresser, der er fritaget fra hvert tjek (kontor, monitoreringstjeneste, staging-server, din egen hjemme-IP).
• Whitelistede URL’er — stier fritaget fra 404-rate-limiteren (nyttigt, når et legitimt endpoint legitimt returnerer 404 i bølger).

Brug skærmen til at:

• Låse op for en adresse, som en legitim bruger ramte ved at taste forkert.
• Whiteliste en kendt-god IP (dit kontor, monitoreringstjeneste, staging-server), så den ikke kan låses ude ved et uheld.
• Whiteliste en URL, der ramme 404-rate-grænsen ved design (f.eks. en probe-sti, der forbruges af ekstern monitorering).

Gennemgå angrebsloggen

Angrebsloggen (Security Pilot → Angrebslog) registrerer hver blokeret request, herunder brute-force-lockouts, firewall-hits, rate-limiter-udløsninger, formular-spam-afvisninger og REST API-afvisninger. Hver række bærer tidsstemplet, kilde-IP’en, Angrebstype (f.eks. RESTRICTION, REQUEST_URI, PATH_TRAVERSAL, COMMAND_INJECTION, POST_X), den Rule listener, der udstedte blokeringen, og Request URI, der udløste det. En bulk-handling Ryd log rydder siden, og værktøjslinjen byder på fritekstsøgning samt filtre pr. IP og pr. listener.

Loggen er nyttig både til efterbehandling efter en hændelse og til finjustering af firewallen: hvis et legitimt request til dit site optræder i loggen, kan du identificere den ansvarlige regel og beslutte, om du vil whiteliste requestet, IP’en eller præcisere reglen.

WordPress-dashboard-widget

Security Pilot tilføjer en widget til standard-Dashboard-skærmen (den side, WordPress åbner ved login), så hovedtallene er synlige fra det øjeblik, du logger ind.

Widgetten viser:

• Den seneste Security Check-karakter (A–F) og numeriske score (f.eks. A 95/100), tegnet som en farvet ring.
• En live-tæller for Blokerede IP’er, hentet fra Adgangsregler-tabellen.
• En løbende Angreb-tæller fra angrebsloggen.
• Listen Seneste angreb — de fem nyeste rækker i angrebsloggen med type-badge, kilde-IP og tidsstempel.
• Footer-genveje til Angrebslog og Komplet sikkerhedsrapport.

FAQ

Erstatter Security Pilot andre sikkerhedsplugins?

For de fleste sites: ja. Security Pilot dækker HTTP-headers, login-beskyttelse, request-filtrering, REST API-begrænsninger, hærdning og audit. Det er bevidst let frem for en “schweizerkniv”-suite. At køre det sammen med en anden firewall eller et andet login-beskyttelsesplugin er teknisk muligt, men sjældent nyttigt og kan få overlappende regler til at fyre to gange.

Vil headerne ødelægge mit site?

Standardværdierne er konservative. De to headers, der oftest kræver opmærksomhed, er HSTS og Content-Security-Policy.

• Slå kun HSTS til, når sitet er fuldt tilgængeligt over HTTPS, inklusive de subdomæner, du vil have med. Headeren caches af browsere og kan ikke nemt trækkes tilbage.
• Finjuster Content-Security-Policy, efter at du har holdt øje med browser-konsollen for blokerede ressourcer på rigtige sider. Custom scripts, fonte og analytics skal ofte tilføjes policyen.

Vil request-firewallen blokere legitim trafik?

Detektionsmønstrene retter sig mod kendte angrebssignaturer og plejer at være præcise. Hvis et legitimt request bliver blokeret, optræder det i angrebsloggen med den regel, der udløste blokeringen. Så kan du låse op for IP’en og — hvis mønsteret reelt er uundgåeligt — dokumentere undtagelsen for dit team.

Virker pluginet bag et CDN eller en reverse proxy?

Ja. Pluginet læser den oprindelige IP-adresse fra standard-request-headers og kan korrekt identificere besøgende bag et CDN, forudsat at dit hostingmiljø videresender den korrekte X-Forwarded-For eller tilsvarende header. Sørg for, at et eventuelt edge-lag foran WordPress ikke fjerner de response-headers, Security Pilot tilføjer.

Kan jeg eksportere angrebslogs eller blokerede IP-lister?

Angrebsloggen og tabellen over blokerede IP’er ligger i din WordPress-database og kan gennemgås direkte fra admin-grænsefladen. Til langtidsarkivering eller off-site-analyse tager du en database-backup, som du ville for ethvert andet WordPress-data.

Ødelægger det noget at slå XML-RPC fra?

XML-RPC bruges af den gamle Windows Live Writer-klient, af WordPress-mobilapps i visse konfigurationer og af et lille antal tredjeparts-integrationer. Hvis du ikke bruger nogen af dem, er at slå XML-RPC fra et af de mest effektive enkelt-klik-skridt, du kan tage til hærdning.

Bevares indstillingerne, når pluginet deaktiveres?

Ja. At deaktivere Security Pilot bevarer din konfiguration, angrebsloggen og blokeringslisten i databasen, så aktivering igen genopretter den tidligere tilstand.

Fejlfinding

En legitim bruger låses ude

Åbn Blokerede IP’er, find posten for den berørte adresse, og fjern blokeringen. Hvis den samme bruger låses ude igen og igen, så overvej:

• At øge Maks. fejlede forsøg for glemsomme brugere.
• At føje brugerens IP (eller kontor-NAT-IP’en) til whitelisten.
• At bede brugeren om at nulstille adgangskoden i stedet for at gætte.

Browseren blokerer ressourcer efter at have slået CSP til

Content-Security-Policy er bevidst streng som standard. Åbn browserens udviklingsværktøjer og se Console-fanen — browseren rapporterer hver blokeret ressource sammen med det direktiv, der afviste den. Justér CSP’en til at inkludere de betroede origins (CDN, analytics-udbyder, font-host), dit site er afhængig af.

Sider bliver ved med at indlæse over HTTP efter HSTS

HSTS overholdes først, når browseren har set headeren mindst én gang over HTTPS. Besøg sitet direkte over https:// for at fylde cachen. Hvis sitet endnu ikke kan nås over HTTPS for hver URL, du annoncerer, så slå HSTS fra, indtil migreringen er færdig.

REST API-integrationer holder op med at virke

Hvis en integration, der lænder på en beskyttet endpoint-gruppe, holder op med at virke, så slå beskyttelsen midlertidigt fra for den gruppe under REST API-beskyttelse og bekræft, at integrationen autentificerer korrekt. Mange integrationer forventer at blive kaldt som en autentificeret WordPress-bruger; autentificerede requests blokeres ikke af modulet.

Headers er ikke til stede i svaret

Visse hosts eller reverse proxies fjerner eller overstyrer response-headers, PHP tilføjer. Bekræft headerne med et værktøj som curl -I https://example.com/ eller browserens network-inspektor. Hvis en header mangler, så slå op i hostingens dokumentation, hvordan man slipper custom headers igennem, eller tilføj headeren ved kanten, hvis hosten kræver det.

Mail-alerts kommer ikke frem

Mail-alerts bruger WordPress’ wp_mail(). Kommer ingen mail frem, ligger fejlen næsten altid i sitets mailopsætning og ikke i Security Pilot. Installer et transaktionsmail-plugin (for eksempel et plugin, der sender WordPress-mail gennem SMTP), og test igen ved at udløse en lockout fra en test-browser.