Din WordPress-installasjon kan være så sikker eller usikker du vil. Lær hvilke fem ting som er de viktigste når det kommer til sikkerhet.
Bekymringer og klager om WordPress-sikkerhet er ikke noe nytt.
Hvis du trenger et CMS og tilfeldigvis konsulterer en tjenesteleverandør som ikke er i WordPress, er sikkerhet nummer én du vil høre om. Betyr det at alle bør droppe WordPress og bytte til statiske nettstedsgeneratorer eller et hodeløst CMS?
Nei, for akkurat som enhver sannhet i livet, har også denne mange sider.
Innholdsfortegnelse
Er WordPress svært usikkert?
La oss ta en titt på noen enorme nettsteder som ble bygget på WordPress:
- TechCrunch
- New Yorkeren
- BBC America
- Bloomberg
- MTV Nyheter
- PlayStation-bloggen
Så, hva gjør at disse selskapene – med absurd dype lommer og en overveldende arbeidsstyrke – ikke bytter fra WordPress? Hvis du tror svaret er eldre kode, tenk om igjen: for disse navnene er datasikkerhet og offentlig image uendelig mye viktigere enn en enkel migrering som vil koste (anslår jeg) mindre enn $200 000.
Ingeniørene deres vet sikkert hva de gjør og ser ingen grunnleggende, uløselige sikkerhetsproblemer med WordPress?
Selv har jeg til gode å administrere en WordPress-installasjon som ser 3,5-4 millioner besøkende i måneden. Totalt antall sikkerhetsbrudd de siste åtte årene? Null!
Så . . . er WordPress sikkert?
Jeg beklager hvis det virker som trolling, men her er svaret mitt:
Jeg sier det fordi, som enhver sannhet i livet, er det komplisert. For å komme frem til et legitimt svar, må vi først forstå at WordPress (eller et hvilket som helst forhåndsbygd CMS, for den saks skyld) ikke er som et skap du stikker et sted permanent og blir ferdig med det.
Det er et komplekst stykke programvare med mange avhengigheter:
- PHP, som er språket det er bygget med
- En offentlig synlig maskin som er vert for installasjonen
- Nettserveren som brukes til å håndtere besøkende (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, avhengig av hvor mye installasjonen din har som mål å oppnå
Med andre ord, et sikkerhetsbrudd på noen av disse sømmene vil bli betegnet som et WordPress-brudd.
Hvis serverens root-passord var admin123 og det ble kompromittert, er det WordPress-sikkerhetsfeil?
Hvis PHP-versjonen hadde en sikkerhetssårbarhet, eller hvis den nye plugin-en du kjøpte og installerte inneholdt et skarpt sikkerhetshull; og så videre. For å oppsummere: Et undersystem svikter, og det er en WordPress-sikkerhetsfeil.
Som en side, vennligst ikke la dette gi deg inntrykk av at PHP, MySQL og Apache ikke er sikre. Hvert stykke programvare har sårbarheter, hvor antallet er svimlende når det gjelder åpen kildekode (fordi den er tilgjengelig for alle å se og analysere).
Sa noen «sikker»? 😛
Det vi lærer av all denne øvelsen er dette:
Ingenting er sikkert eller usikkert i seg selv. Det er de forskjellige komponentene som brukes som danner leddene i kjeden, kjeden er selvfølgelig like sterk som den svakeste av dem. Historisk sett var «ikke sikker»-etiketten til WordPress en kombinasjon av gamle PHP-versjoner, delt hosting og å legge til plugins/temaer fra ikke-klarerte kilder.
Samtidig gjør noen ganske vanlige forglemmelser WordPress-installasjonen din sårbar for de som vet hvordan de skal utnytte dem og er bestemt. Og det er det dette innlegget handler om. Så uten videre (og sirkulære argumenter), la oss komme i gang.
Topp WordPress smutthull som hackere kan utnytte
WordPress-tabellprefikset
Den berømte 5-minutters installasjonen er det beste som kan skje med WordPress, men som alle installasjonsveivisere gjør det oss late og lar ting stå som standard.
Dette betyr at standardprefikset for WordPress-tabellene dine er wp_, noe som resulterer i tabellnavn som alle kan gjette:
- wp-brukere
- wp-alternativer
- wp-innlegg
Vurder nå et angrep kjent som SQL Injection, der ondsinnede databasespørringer er smart satt inn og laget for å kjøre i WordPress (vær oppmerksom på at dette på ingen måte er et WordPress/PHP-eksklusivt angrep).
Mens WordPress har innebygde mekanismer for å håndtere denne typen angrep, kan ingen garantere at det ikke vil skje.
Så hvis angriperen på en eller annen måte klarer å kjøre en spørring som DROP TABLE wp_users; DROP TABLE wp_posts;, alle dine kontoer, profiler og innlegg vil bli slettet på et øyeblikk uten sjanse for gjenoppretting (med mindre du har et sikkerhetskopieringsskjema på plass, men selv da er du nødt til å miste data siden siste sikkerhetskopiering ).
Bare å endre prefikset under installasjonen er en stor sak (som krever null innsats).
Noe tilfeldig som sdg21g34_ anbefales fordi det er tull og vanskelig å gjette (jo lengre prefikset, jo bedre). Det beste er at dette prefikset ikke trenger å være minneverdig; prefikset er noe WordPress vil lagre, og du trenger aldri å bekymre deg for det igjen (akkurat som du ikke bekymrer deg for standard wp_-prefikset!).
Standard påloggings-URL
Hvordan vet du at en nettside kjører på WordPress? Et av tegnene er at du ser WordPress-påloggingssiden når du legger til «/wp-login.php» til nettstedsadressen.
Som et eksempel, la oss ta nettstedet mitt (http://ankushthakur.com). Er det på WordPress? Vel, fortsett og legg til påloggingsdelen. Hvis du føler deg for lat, skjer dette:
¯_(ツ)_/¯
WordPress, ikke sant?
Når så mye er kjent, kan angriperen gni hendene i glede og begynne å bruke ekle triks fra Bag-O»-Doom på alfabetisk basis. Stakkars meg!
Løsningen er å endre standard påloggings-URL og gi den bare til de personene som er klarert.
For eksempel er denne nettsiden også på WordPress, men hvis du besøker http://tipsbilk.net.com/wp-login.php, får du bare en dyp skuffelse. Påloggings-URLen er skjult og er kun kjent for administratorene?
Å endre påloggingsadressen er heller ikke rakettvitenskap. Bare ta tak i dette plugg inn.
Gratulerer, du har nettopp lagt til et nytt lag med frustrerende sikkerhet mot brute force-angrep.
PHP- og webserverversjonen
Vi har allerede diskutert at hvert stykke programvare som noen gang er skrevet (og blir skrevet) er full av feil som venter på å bli utnyttet.
Det samme gjelder for PHP.
Selv om du bruker den nyeste versjonen av PHP, kan du ikke være sikker på hvilke sårbarheter som finnes og kan bli oppdaget over natten. Løsningen er å skjule en bestemt overskrift sendt av webserveren din (aldri hørt om overskrifter? les dette!) når en nettleser kobler til den: x-powered-by.
Slik ser det ut hvis du sjekker utviklerverktøyene til favorittnettleseren din:
Som vi kan se her, forteller nettstedet oss at det kjører på Apache 2.4 og bruker PHP versjon 5.4.16.
Nå er det allerede massevis av informasjon vi sender videre uten grunn, og hjelper angriperen med å begrense valget av verktøy.
Disse (og lignende) overskrifter må skjules.
Heldigvis kan det gjøres raskt; Dessverre er det nødvendig med sofistikert teknisk kunnskap, siden du må dykke ned i systemets tarm og rote med viktige filer. Derfor er mitt råd å spørre vertsleverandøren for nettstedet ditt om å gjøre dette for deg; hvis de ikke ser om en konsulent kan få det gjort, selv om dette i stor grad vil avhenge av webverten din om oppsettet deres har slike muligheter eller ikke.
Hvis det ikke fungerer, kan det være på tide å bytte hostingleverandør eller flytte til en VPS og ansette en konsulent for sikkerhet og administrasjon.
Er det verdt det? Bare du kan bestemme det. 🙂
Åh, og hvis du vil nerde på sikkerhetsoverskrifter, her er løsningen din!
Antall påloggingsforsøk
Et av de eldste triksene i hackerens håndbok er den såkalte Ordbokangrep.
Tanken er at du prøver et latterlig stort antall (om mulig millioner) kombinasjoner for et passord med mindre en av dem lykkes. Siden datamaskiner er lynraske i det de gjør, er et så tåpelig opplegg fornuftig og kan gi resultater innen rimelig tid.
Et vanlig (og ekstremt effektivt) forsvar har vært å legge til en forsinkelse før feilen vises. Dette får mottakeren til å vente, noe som betyr at hvis det er et skript ansatt av en hacker, vil det ta for lang tid å fullføre. Det er grunnen til at datamaskinen eller favorittappen din spretter litt og så sier «Beklager, feil passord!».
Uansett, poenget er at du bør begrense antall påloggingsforsøk for WordPress-siden din.
Utover et angitt antall forsøk (f.eks. fem), skal kontoen låses og bare kunne gjenopprettes via kontoinnehaverens e-post.
Heldigvis er det en cakewalk å få dette gjort hvis du kommer over en fin plugg inn.
HTTP vs. HTTPS
SSL-sertifikatet leverandøren din har plaget deg om er viktigere enn du kanskje tror.
Det er ikke bare et omdømmeverktøy å vise et grønt låsikon i nettleseren som sier «Sikker»; snarere, å få installert et SSL-sertifikat og tvinge alle nettadresser til å fungere på «https» er alene nok til å ta nettstedet ditt fra å være en åpen bok til en kryptisk rulle.
Hvis du ikke forstår hvordan dette skjer, vennligst les om noe kjent som en mann-i-midten angrep.
En annen måte å avskjære trafikken som strømmer fra datamaskinen til serveren er pakkesniffing, som er en passiv form for datainnsamling og ikke engang trenger å anstrenge seg for å plassere seg i midten.
For nettsteder som kjører over vanlig «HTTP», vises personen som avskjærer nettverkstrafikken, passordene og kredittkortnumrene klar, ren tekst.
Kilde: comparitech.com
Skummelt? Veldig!
Men når du først har installert et SSL-sertifikat og alle nettadresser blir konvertert til «https», vises denne sensitive informasjonen som vrøvl som bare serveren kan dekryptere. Med andre ord, ikke svett de få dollarene i året. 🙂
Konklusjon
Vil få disse fem tingene under kontroll sikre nettstedet ditt pent?
Nei ikke i det hele tatt. Som utallige sikkerhetsartikler sier, er du aldri 100 % sikker, men det er mulig å eliminere en stor klasse av disse problemene med rimelig innsats. Du kan vurdere å bruke SUCURI cloud WAF for å beskytte nettstedene dine helhetlig.