Din WordPress-installation kan være så sikker eller usikker, som du ønsker. Lær hvilke fem ting der er de vigtigste, når det kommer til sikkerhed.
Bekymringer og klager over WordPress-sikkerhed er ikke noget nyt.
Hvis du har brug for et CMS og tilfældigvis konsulterer en tjenesteudbyder, der ikke er til WordPress, er sikkerhed nummer ét, du vil høre om. Betyder det, at alle skal droppe WordPress og skifte til statiske webstedsgeneratorer eller et hovedløst CMS?
Nej, for ligesom enhver sandhed i livet har denne også mange sider.
Indholdsfortegnelse
Er WordPress meget usikkert?
Lad os tage et kig på nogle enorme websteder, der blev bygget på WordPress:
- TechCrunch
- New Yorkeren
- BBC America
- Bloomberg
- MTV News
- PlayStation-blog
Så hvad får disse virksomheder – med absurd dybe lommer og en forbløffende arbejdsstyrke – til ikke at skifte fra WordPress? Hvis du tror, at svaret er gammel kode, så tænk om igen: For disse navne er datasikkerhed og offentligt image uendeligt meget vigtigere end en simpel migrering, der vil koste (jeg estimerer) mindre end $200.000.
Deres ingeniører ved sikkert, hvad de laver, og ser ingen grundlæggende, uløselige sikkerhedsproblemer med WordPress?
Selv har jeg heldet med at styre en WordPress-installation, der ser 3,5-4 millioner besøgende om måneden. Det samlede antal sikkerhedsbrud i de sidste otte år? Nul!
Så . . . er WordPress sikkert?
Jeg beklager, hvis det virker som trolling, men her er mit svar:
Jeg siger det, fordi det, som enhver sandhed i livet, er kompliceret. For at nå frem til et legitimt svar, skal vi først forstå, at WordPress (eller et hvilket som helst forudbygget CMS, for den sags skyld) ikke er som et skab, du holder fast et sted permanent og er færdig med det.
Det er et komplekst stykke software med mange afhængigheder:
- PHP, som er det sprog, det er bygget med
- En offentligt synlig maskine, der er vært for installationen
- Webserveren, der bruges til at håndtere besøgende (Apache, Nginx osv.)
- Den anvendte database (MySQL/MariaDB)
- Temaer (bundter af PHP-, CS- og JS-filer)
- Plugins (bundter af PHP-, CS- og JS-filer)
- Og mange flere, afhængigt af hvor meget din installation sigter mod at opnå
Med andre ord vil et sikkerhedsbrud i nogen af disse sømme blive betegnet som et WordPress-brud.
Hvis serverens root-adgangskode var admin123, og den blev kompromitteret, er det så WordPress sikkerhedsfejl?
Hvis PHP-versionen havde en sikkerhedssårbarhed, eller hvis det nye plugin, du købte og installerede, indeholdt et grelt sikkerhedshul; og så videre. For at opsummere: Et undersystem fejler, og det er en WordPress-sikkerhedsfejl.
Som en sidebemærkning, lad venligst heller ikke dette give dig det indtryk, at PHP, MySQL og Apache ikke er sikre. Hvert stykke software har sårbarheder, hvoraf antallet er svimlende i tilfælde af open source (fordi det er tilgængeligt for alle at se og analysere).
Var der nogen, der sagde “sikker”? 😛
Det vi lærer af al denne øvelse er dette:
Intet er sikkert eller usikkert i sig selv. Det er de forskellige anvendte komponenter, der danner leddene i kæden, kæden er selvfølgelig lige så stærk som den svageste af dem. Historisk set var WordPress-etiketten “ikke sikker” en kombination af gamle PHP-versioner, delt hosting og tilføjelse af plugins/temaer fra upålidelige kilder.
Samtidig gør nogle ret almindelige forglemmelser din WordPress-installation sårbar over for dem, der ved, hvordan man udnytter dem og er beslutsomme. Og det er det, dette indlæg handler om. Så uden videre (og cirkulære argumenter), lad os komme i gang.
Top WordPress-smuthuller, som hackere kan udnytte
WordPress-tabelpræfikset
Den berømte 5-minutters installation er det bedste, der kan ske for WordPress, men som alle installationsguider gør det os dovne og lader tingene stå som standard.
Dette betyder, at standardpræfikset for dine WordPress-tabeller er wp_, hvilket resulterer i tabelnavne, som alle kan gætte:
- wp-brugere
- wp-indstillinger
- wp-indlæg
Overvej nu et angreb kendt som SQL Injection, hvor ondsindede databaseforespørgsler er smart indsat og lavet til at køre i WordPress (bemærk venligst – dette er på ingen måde et WordPress/PHP-eksklusivt angreb).
Mens WordPress har indbyggede mekanismer til at håndtere disse typer angreb, kan ingen garantere, at det ikke vil ske.
Så hvis angriberen på en eller anden måde formår at køre en forespørgsel som DROP TABLE wp_users; DROP TABLE wp_posts;, vil alle dine konti, profiler og indlæg blive slettet på et øjeblik uden chance for gendannelse (medmindre du har en backup-ordning på plads, men selv da er du bundet til at miste data siden sidste sikkerhedskopiering ).
Blot at ændre præfikset under installationen er en stor sag (hvilket kræver ingen indsats).
Noget tilfældigt som sdg21g34_ anbefales, fordi det er noget pjat og svært at gætte (jo længere præfiks, jo bedre). Det bedste er, at dette præfiks ikke behøver at være mindeværdigt; præfikset er noget, WordPress vil gemme, og du behøver aldrig at bekymre dig om det igen (ligesom du ikke bekymrer dig om standardpræfikset wp_!).
Standard login-URL
Hvordan ved du, at en hjemmeside kører på WordPress? Et af de afslørende tegn er, at du ser WordPress login-siden, når du tilføjer “/wp-login.php” til hjemmesidens adresse.
Som et eksempel, lad os tage min hjemmeside (http://ankushthakur.com). Er det på WordPress? Nå, gå videre og tilføj login-delen. Hvis du føler dig for doven, sker der følgende:
¯_(ツ)_/¯
WordPress, ikke?
Når så meget er kendt, kan angriberen gnide deres hænder i glæde og begynde at anvende grimme tricks fra deres Bag-O’-Doom på alfabetisk basis. Stakkels mig!
Løsningen er at ændre standard login-URL og kun give den til de personer, der er tillid til.
For eksempel er denne hjemmeside også på WordPress, men hvis du besøger http://toadmin.dk.com/wp-login.php, vil du kun få en dyb skuffelse. Login-URL’en er skjult og er kun kendt af administratorerne?
Ændring af login-URL er heller ikke raketvidenskab. Bare tag fat i dette plugin.
Tillykke, du har lige tilføjet endnu et lag af frustrerende sikkerhed mod brute force-angreb.
PHP- og webserverversionen
Vi har allerede diskuteret, at hvert stykke software, der nogensinde er skrevet (og bliver skrevet), er fuld af fejl, der venter på at blive udnyttet.
Det samme gælder for PHP.
Selvom du bruger den nyeste version af PHP, kan du ikke være sikker på, hvilke sårbarheder der findes og måske bliver opdaget fra den ene dag til den anden. Løsningen er at skjule en bestemt header sendt af din webserver (aldrig hørt om headers? læs dette!) når en browser opretter forbindelse til den: x-powered-by.
Sådan ser det ud, hvis du tjekker udviklerværktøjerne i din yndlingsbrowser:
Som vi kan se her, fortæller hjemmesiden os, at den kører på Apache 2.4 og bruger PHP version 5.4.16.
Nu er det allerede et væld af informationer, vi sender videre uden grund, og hjælper angriberen med at indsnævre deres valg af værktøjer.
Disse (og lignende) overskrifter skal skjules.
Heldigvis kan det gøres hurtigt; Desværre er der brug for sofistikeret teknisk viden, da du bliver nødt til at dykke ned i systemets indvolde og rode med vigtige filer. Derfor er mit råd at bede din hjemmeside-hostingudbyder om at gøre dette for dig; hvis de ikke kan se, om en konsulent kan få det gjort, selvom det i høj grad afhænger af din hjemmesidevært, om deres opsætning har sådanne muligheder eller ej.
Hvis det ikke virker, kan det være på tide at skifte hostingudbyder eller flytte til en VPS og hyre en konsulent til sikkerheds- og administrationsspørgsmål.
Er det det værd? Det kan kun du bestemme. 🙂
Åh, og hvis du vil nørde ud på sikkerhedsheadere, er her din løsning!
Antal loginforsøg
Et af de ældste tricks i hackerens håndbog er den såkaldte Ordbogsangreb.
Ideen er, at du prøver et latterligt stort antal (om muligt millioner) kombinationer for en adgangskode, medmindre en af dem lykkes. Da computere er lynhurtige til det, de gør, er sådan en tåbelig ordning fornuftig og kan give resultater inden for rimelig tid.
Et almindeligt (og ekstremt effektivt) forsvar har været at tilføje en forsinkelse, før fejlen vises. Dette får modtageren til at vente, hvilket betyder, at hvis det er et script ansat af en hacker, vil det tage for lang tid at afslutte. Det er grunden til, at din computer eller yndlingsapp hopper lidt og så siger: “Ups, den forkerte adgangskode!”.
Pointen er i hvert fald, at du bør begrænse antallet af loginforsøg til dit WordPress-websted.
Ud over et bestemt antal forsøg (f.eks. fem), bør kontoen blive låst og bør kun kunne gendannes via kontoindehaverens e-mail.
Heldigvis er det en cakewalk at få dette gjort, hvis du støder på en dejlig plugin.
HTTP vs. HTTPS
SSL-certifikatet, som din leverandør har plaget dig om, er vigtigere, end du måske tror.
Det er ikke kun et omdømmeværktøj at vise et grønt låseikon i browseren, der siger “Sikker”; snarere, at få et SSL-certifikat installeret og tvinge alle URL’er til at arbejde på “https” er alene nok til at tage dit websted fra at være en åben bog til en kryptisk rulle.
Hvis du ikke forstår, hvordan dette sker, så læs venligst om noget kendt som en mand-i-midten angreb.
En anden måde at opsnappe trafikken, der strømmer fra din computer til serveren, er packet sniffing, som er en passiv form for dataindsamling og ikke engang behøver at gøre sig umage for at placere sig i midten.
For websteder, der kører over almindelig “HTTP”, vises den person, der opsnapper netværkstrafikken, dine adgangskoder og kreditkortnumre klar, almindelig tekst.
Kilde: comparitech.com
Skræmmende? Meget!
Men når du først har installeret et SSL-certifikat, og alle URL’er bliver konverteret til “https”, vises disse følsomme oplysninger som vrøvl, som kun serveren kan dekryptere. Med andre ord, lad være med at svede de få dollars om året. 🙂
Konklusion
Vil få disse fem ting under kontrol sikre din hjemmeside pænt?
Nej slet ikke. Som utallige sikkerhedsartikler siger, er du aldrig 100 % sikker, men det er muligt at eliminere en stor klasse af disse problemer med en rimelig indsats. Du kan overveje at bruge SUCURI cloud WAF til at beskytte dine websteder holistisk.