Sikkerheten til din WordPress-installasjon er i stor grad opp til deg. La oss utforske de fem viktigste faktorene for å sikre din nettside.
Bekymringer rundt sikkerheten til WordPress er ikke noe nytt fenomen.
Dersom du vurderer et CMS, og snakker med en leverandør som ikke spesialiserer seg på WordPress, vil sikkerhet garantert være det første som tas opp. Bør dette få alle til å forlate WordPress til fordel for statiske nettsider eller et headless CMS?
Nei, som med de fleste komplekse spørsmål, finnes det flere perspektiver.
Er WordPress virkelig så usikkert?
La oss se på noen av de mange kjente nettstedene som er bygget med WordPress:
- TechCrunch
- The New Yorker
- BBC America
- Bloomberg
- MTV News
- PlayStation Blog
Hvorfor fortsetter disse selskapene, med sine betydelige ressurser, å bruke WordPress? Det er ikke på grunn av gammel kode. For disse aktørene er databeskyttelse og omdømme viktigere enn en enkel migrasjon som ville koste mindre enn 2 millioner kroner, vil jeg tro.
Deres ingeniører har god oversikt over situasjonen og ser ingen grunnleggende, uløselige sikkerhetsproblemer i WordPress.
Jeg har selv administrert WordPress-installasjoner med 3,5-4 millioner besøkende per måned. Antall sikkerhetsbrudd de siste åtte årene? Null!
Så… er WordPress sikkert?
Jeg beklager om dette virker som en vits, men her er mitt svar:
Som med mange komplekse saker er det ikke enkelt. For å finne et godt svar, må vi forstå at WordPress (eller et hvilket som helst ferdig CMS) ikke er en fast installasjon som settes opp en gang og glemmes.
Det er en kompleks programvare med mange avhengigheter:
- PHP, programmeringsspråket det er bygget med
- En offentlig tilgjengelig server som installasjonen ligger på
- Webserveren som håndterer besøk (Apache, Nginx, etc.)
- Databasen som brukes (MySQL/MariaDB)
- Temaer (pakker med PHP-, CS- og JS-filer)
- Plugins (pakker med PHP-, CS- og JS-filer)
- Og mange flere elementer, avhengig av installasjonens funksjoner
Med andre ord vil et sikkerhetsbrudd på et av disse punktene bli ansett som et WordPress-brudd.
Dersom serverens rotpassord var «admin123» og ble kompromittert, er det en WordPress-sikkerhetsfeil?
Eller om PHP-versjonen hadde en sikkerhetssårbarhet, eller pluginen du installerte inneholdt en kritisk feil? For å oppsummere: Et undersystem svikter, og det blir stemplet som en WordPress-sikkerhetsfeil.
La det være sagt at PHP, MySQL og Apache ikke er usikre i seg selv. All programvare har sårbarheter, særlig programvare med åpen kildekode, siden den er tilgjengelig for alle å studere.
Sa noen «sikkert»? 😛
Dette viser oss at:
Ingenting er i seg selv sikkert eller usikkert. Det er samspillet mellom de ulike komponentene som avgjør sikkerheten. En kjede er ikke sterkere enn det svakeste leddet. Tidligere var WordPress sitt «usikre» rykte en kombinasjon av utdaterte PHP-versjoner, delt hosting og bruk av plugins/temaer fra upålitelige kilder.
Vanlige feil gjør WordPress-installasjonen sårbar for de som vet hvordan de skal utnytte dem. Dette innlegget skal handle om de typiske sikkerhetshullene. La oss begynne, uten flere unødvendige digresjoner.
De viktigste sikkerhetshullene i WordPress som hackere kan utnytte
WordPress tabellprefiks
Den berømte 5-minutters installasjonen er genialt, men som alle installasjonsveivisere, gjør den oss litt late og lar standardinnstillingene være som de er.
Dette betyr at standardprefikset for WordPress-tabellene dine er «wp_», noe som gir tabellnavn som er enkle å gjette:
- wp_users
- wp_options
- wp_posts
Tenk deg et angrep kalt SQL Injection, der ondsinnede databaseforespørsler blir lurt inn for å kjøre i WordPress (dette er ikke et angrep unikt for WordPress/PHP).
Selv om WordPress har innebygde sikkerhetstiltak mot slike angrep, kan ingen garantere at det aldri vil skje.
Dersom angriperen klarer å kjøre en forespørsel som «DROP TABLE wp_users; DROP TABLE wp_posts;», vil alle kontoene, profilene og innleggene dine bli slettet uten mulighet for gjenoppretting (med mindre du har en sikkerhetskopieringsrutine, og selv da vil du miste data siden forrige sikkerhetskopi).
Bare det å endre prefikset under installasjonen er et viktig tiltak (som ikke krever noe ekstra arbeid).
Et tilfeldig prefiks som «sdg21g34_» er å anbefale fordi det er vanskelig å gjette. Jo lengre prefikset er, desto bedre. Det beste er at du ikke trenger å huske prefikset; WordPress lagrer det, og du trenger ikke å tenke på det igjen (akkurat som du ikke tenker på standard «wp_»-prefikset!).
Standard innloggingsadresse
Hvordan kan man vite om en nettside bruker WordPress? Ett av tegnene er at du ser WordPress sin innloggingsside når du legger til «/wp-login.php» i nettsidens adresse.
Ta for eksempel nettsiden min (http://ankushthakur.com). Bruker den WordPress? Bare legg til innloggingsdelen. Om du ikke gidder, så er svaret dette:
¯\_(ツ)_/¯
Det er WordPress, ikke sant?
Med denne kunnskapen kan en angriper glede seg og begynne å bruke ufine metoder for å bryte seg inn. Det er ikke bra!
Løsningen er å endre standard innloggingsadresse og bare dele den med de som er klarert.
Denne nettsiden bruker også WordPress, men hvis du besøker http://tipsbilk.net.com/wp-login.php, vil du ikke finne noe. Innloggingsadressen er skjult og kun kjent for administratorene.
Endring av innloggingsadresse er ikke vanskelig. Bare bruk denne pluginen.
Gratulerer, du har akkurat lagt til et ekstra lag med sikkerhet mot bruteforce-angrep.
PHP- og webserverversjon
Vi har allerede nevnt at all programvare inneholder feil som venter på å bli utnyttet.
Det samme gjelder PHP.
Selv om du bruker den nyeste versjonen av PHP, kan du ikke være sikker på at det ikke finnes sårbarheter som kan bli oppdaget over natten. Løsningen er å skjule en bestemt overskrift som webserveren sender ut (aldri hørt om overskrifter? les denne!) når en nettleser kobler seg til: x-powered-by.
Slik ser det ut når du sjekker utviklerverktøyene i nettleseren din:
Som du ser, forteller nettstedet oss at det kjører på Apache 2.4 og bruker PHP versjon 5.4.16.
Vi gir unødvendig informasjon og hjelper angriperen med å begrense valgmulighetene sine.
Disse (og lignende) overskriftene bør skjules.
Heldigvis kan dette gjøres raskt. Dessverre kreves det teknisk innsikt, da du må endre viktige systemfiler. Mitt råd er å spørre din hostingleverandør om å gjøre dette for deg. Hvis de ikke kan, se om en konsulent kan hjelpe. Om det er mulig, avhenger av webhotellets oppsett.
Dersom det ikke er mulig, kan det være på tide å bytte leverandør, eller flytte til en VPS og ansette en konsulent for sikkerhet og administrasjon.
Er det verdt det? Det er opp til deg. 🙂
Og for deg som er interessert i sikkerhetsoverskrifter, her er løsningen!
Antall innloggingsforsøk
Et gammelt triks i hackerens verktøykasse er det som kalles et ordbokangrep.
Tanken er å prøve mange kombinasjoner (om mulig millioner) av passord inntil en treffer. Siden datamaskiner er raske, kan dette gi resultater i løpet av kort tid.
Et vanlig (og effektivt) forsvar er å legge inn en forsinkelse før feilmeldingen vises. Dette tvinger mottakeren til å vente, som forhindrer at et skript kjørt av en hacker skal lykkes. Det er derfor datamaskinen eller appen din venter litt før den sier «Beklager, feil passord!».
Poenget er at du bør begrense antall innloggingsforsøk på WordPress-siden din.
Etter et visst antall forsøk (f.eks. fem), skal kontoen låses og kun kunne gjenopprettes via e-post.
Dette kan lett fikses med en god plugin.
HTTP vs. HTTPS
SSL-sertifikatet som leverandøren din maser om, er viktigere enn du tror.
Det er ikke bare et verktøy for å vise en grønn hengelås i nettleseren som sier «Sikker». Det å installere et SSL-sertifikat og tvinge alle adresser til å bruke «https» er nok til å gjøre nettstedet ditt til en kryptert rull.
Om du ikke vet hvorfor, les om mann-i-midten-angrep.
En annen måte å avskjære trafikken fra datamaskinen til serveren er pakkefanging, som er en passiv form for datainnsamling og ikke krever at man plasserer seg midt i kommunikasjonen.
For nettsider som kjører over vanlig «HTTP», vil en som avlytter trafikken kunne se passord og kredittkortnumre i klartekst.
Kilde: comparitech.com
Skremmende, ikke sant?
Men når du installerer et SSL-sertifikat og tvinger alle adresser til «https», blir den sensitive informasjonen kryptert og kan kun dekrypteres av serveren. Med andre ord, ikke spar på de få kronene i året. 🙂
Konklusjon
Vil disse fem tiltakene gjøre nettstedet ditt helt sikkert?
Nei, langt ifra. Som de fleste sikkerhetsartikler sier, er du aldri 100 % sikker, men det er mulig å eliminere mange problemer med enkle tiltak. Du kan også vurdere å bruke SUCURI cloud WAF for å beskytte nettstedet ditt helhetlig.