Ditt stöd är viktigt! Med din hjälp finns Macpro kvar även i framtiden. Läs mer här
!

2015-07-13
Nyhet

Skydda din WordPress-sajt mot intrång

Om du kör WordPress som publiceringsplattform så är det inte bara att installera WordPress och tro att den automagiska uppdateringen av plattformen löser allt. Långt därifrån – hur starka lösenord du valt spelar en viss roll, hur säkra eventuella plugins är spelar en annan minst lika stor roll.

Jag hjälper ett antal vänner med att drifta sina webbsajter som alla kör på WordPress. Man kan tycka att jag skulle övertyga/tvinga dem att köra Jekyll istället men men även om Jekyll har sina stora fördelar så är Jekyll knappast höjden av användarvänligt för gemene man eller kvinna.

Problemet med WordPress är, utöver återkommande säkerhets- och prestandaproblem att det också ställer krav på den som driver det åt sina kunder/vänner/användare eftersom man inte alltid kan anta att de ska hålla koll på detta själva. Fråga vilket webbhotell som helst hur många samtal de får till sin kundtjänst dagligen om att deras webbsajt blivit hackad så kommer du snart inse att detta är ett väldigt stort problem.

En god vän som arbetar som säkerhetsexpert och som själv ägnat sig åt att hacka webbsajter i yngre år ställde frågan rakt ut: hur kan WordPress tillåtas få köras på någon webbsajt?

Den frågan skulle jag också ha ställt mig då jag såg bilden högst upp i artikeln på en av de sajter jag driftar åt några vänner. Det visade sig sedan att det fanns ytterligare två WordPress-sajter i samma kluster som drabbats av samma sak.

Det kan ju tyckas pinsamt att blogga om sina upplevelser men jag hoppas kunna hjälpa andra att inte drabbas på samma sätt. Mina egna sajter förblev orörda, mycket beroende på att de inte har någon väg in och inte körs med kod skriven i PHP utan består istället helt och hållet av statiska filer. Det är bökigt, men det fungerar.

Intrånget på min server berodde i första hand på klent valda lösenord i ett par av de vänners WordPress-sajter jag kör hos mig men också på grund av det faktum att jag körde en gammal version av PHP på mina webbnoder och att jag inte läst på om säkerhet i WordPress.

Det har jag gjort nu och här är några tips på hur du ska slippa lägga en solig Lördag på att städa upp, installera om och läsa på om saker man egentligen inte skulle behöva bry sig om om världen var en perfekt plats.

Om / när du blir hackad

Det första du ska göra om, eller när, du blir hackad är att ta ner webbsajten omedelbart. Har du kontroll över servern, stoppa webbserverprogramvaran omedelbart och stäng av alla andra accessvägar som exempelvis FTP eller SSH tills du har en aning om hur attacken gått till. Har du inte kontroll över själva webbserverns programvara, flytta bort katalogen med sajten från mappen som webbservern delar ut till omvärlden.

Det finns två stora anledningar till detta – dels att attacken kanske fortfarande pågår, och dels att du inte vill att den hackade sidan ska fastna i Googles index. Hamnar din sajt i Googles index är det en signal om att din server är öppen för attacker och därmed kommer den nästan garanterat dra till sig andra som försöker hacka dig igen.

Nästa steg är att ta reda på vad som faktiskt hänt. Finns webbserverns loggar kvar är det bara att sätta sig och leta efter något som ser underligt ut. Återkommande anrop från samma IP-adress efter filer som inte finns på din server (eller borde finnas där) är en bra ledtråd. Leta också exempelvis efter rader som innehåller ordet “POST” då det innebär att någon försökt skriva något till din sajt. I fallet WordPress är det oftast en php-fil som laddats upp till /wp-content/uploads-mappen men det kan lika gärna vara en annan fil förtäckt som en bild, textfil eller liknande.

Om din WordPress-sajt är hackad är det högst sannolikt att förövaren inte bara kommit åt ditt lösenord till sajten utan också ditt databaslösenord och alla andra inställningar som rör WordPress. Om du har en backup som är tagen innan attacken kan du först spara undan din hackade sajt till din lokala dator och sedan ladda upp backupfilen. Starta dock inte webbservern ännu utan det finns ett antal modifieringar du först måste göra i WordPress innan du kan starta sajten igen. Din databas kommer sannolikt vara antingen förstörd eller ändrad på ett sådant sätt så du bör radera den befintliga databasen och återställa en backup. Om du inte har en backup har du härmed lärt dig den hårda vägen att du bör ha en.

Om du har backuper på hela din sajt en eller flera dagar bakåt i tiden är det en god ide att jämföra dessa med din nuvarande, hackade, sajt. Försök hitta vilka filer som har förändrats (oftast index.php i root-katalogen på WordPress) men det kan också finnas filer i /wp-content/uploads-katalogen.

I mitt fall byggde hacket på en enorm php-fil vid namn p0c.php. Jag kunde se exakt var filen hade skrivits på mina servrar men när jag började leta fanns inte filen där. Detta beror på att många av dessa exploit-filer är självförstörande och raderar sig själva från hårddisken. Detta kan man tycka är en rak motsägelse – att smyga sig in, spara all information som scriptet kan komma över om din WordPress-sajt och din server i övrigt (om möjligt), förstöra din WordPress-sajt och slutligen radera sig själv från hårddisken.

Vad förövaren inte hade räknat med är att jag tar snapshots på min storage med stor regelbundenhet varför jag kunde gå in i mina snapshots och hitta filen i fråga och se exakt vad den gjorde, och det jag såg gjorde mig ganska kallsvettig men det gav mig också väldigt goda ledtrådar till att det inte fanns någon skadlig kod installerad på min server. Istället hade scriptet inhämtat tonvis med information och sedan raderat sig självt, men mer om det senare.

Installera om din webbserver

Om din sajt blivit hackad så kanske det var bara för att förstöra den, men vågar du chansa? I mitt fall installerade jag om alla mina webbservrar och andra servrar som har något med driften att göra. Alla lösenord byttes, IP-adresser byttes på servrarna och en rad andra ändringar för att helt förändra den bild som kunnat uthämtas av det skadliga scriptet.

I mitt fall körde jag CentOS med alla uppdateringar installerade. Men det räckte inte då CentOS är minst sagt konservativa med att lägga in fräscha versioner av exempelvis PHP.

Således fick jag använda mig av ett externt repository för att få in de senaste versionerna av PHP, ett mycket flexibelt och fint programmeringsspråk på många sätt men också ett som, på grund av sin populäritet, är extra utsatt för olika attacker. Som komplement till det installerade jag Suhosin och la in ett antal extra funktioner i php.ini för att härda PHP ännu mer.

En god regel är också att se till att din webbserver inte har paket och applikationer installerade som faktiskt inte behövs för att den ska kunna vara just en webbserver. I fallet WordPress är det en god ide att säkra din WordPress-sajt med ett SSL-certifikat så du inte skickar din inloggningsinformation i klartext varje gång du loggar in på din blogg.

Härda WordPress

Det finns gott om plugins för WordPress som säger sig skydda din sajt. Den jag använder på alla sajter jag har hand om heter Wordfence. Den är dock bara ett bra skydd om den är korrekt inställd och om du dessutom har valt ett starkt lösenord för ditt/dina konton på sajten. Jag återkommer till det lite senare i texten.

Wordfence har en funktion som är viktigt, och underligt nog är den avaktiverad som standard: Disable Code Execution for Uploads directory. Slå på den, så kommer Wordfence att placera en regel i en .htaccess-fil som din webbserver läser och sedan lyder. Denna regel gör det helt enkelt omöjligt att exekverera kod som laddats upp till /wp-content/uploads-katalogen.

Nästa steg är att se till att alla kataloger och filer har korrekta rättigheter. Det finns ett enkelt sätt att göra detta. Lägg in följande rader i wp-config.php:


define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

Nästa steg är att stoppa så det inte går att redigera några filer som har med ditt tema på din WordPress-sajt att göra genom WordPress egna gränssnitt för ändamålet. Lägg in följande i wp-config.php


define('DISALLOW_FILE_EDIT',true);

Steget där efter är att slå av så din WordPress-sajt inte kan göra externa anrop till externa URL:er. Detta kan givetvis hindra funktionen i en eller flera plugins som förlitar sig på detta så denna regel kan du slå på och sedan lägga till sajter som du tillåter externa anrop för till specifika adresser.

Lägg till denna i wp-config.php:

define('WP_HTTP_BLOCK_EXTERNAL', true);

Lägg till detta i din .htaccess-fil i roten för WordPress:

<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>
<IfModule mod_alias.c>
RedirectMatch 403 /xmlrpc.php
</IfModule>

På så sätt skyddar du åtkomst till wp-config.php-filen och du blockerar också försök till att attackera och hacka din WordPress-sajt via xmlrpc.php, en funktion som används för att publicera blogginlägg via tredjepartsapplikationer.

I tidigare versioner av WordPress var RPC inte aktiverat som standard men från och med version 3.5 är det just det och i den senaste versionen när detta skrivs, version 4.2.2, finns det inget sätt att slå av funktionen om man antingen inte installerar en plugin för ändamålet eller lägger in de tre nedre raderna enligt ovan.

I filen wp-config.php noterar du säkert att det finns följande text:

define(‘AUTH_KEY’, ‘put your unique phrase here’);
define(‘SECURE_AUTH_KEY’, ‘put your unique phrase here’);
define(‘LOGGED_IN_KEY’, ‘put your unique phrase here’);
define(‘NONCE_KEY’, ‘put your unique phrase here’);
define(‘AUTH_SALT’, ‘put your unique phrase here’);
define(‘SECURE_AUTH_SALT’, ‘put your unique phrase here’);
define(‘LOGGED_IN_SALT’, ‘put your unique phrase here’);
define(‘NONCE_SALT’, ‘put your unique phrase here’);

Vad betyder då detta? I praktiken kan du kryptera all information som WordPress skriver i cookies med denna metod och det bidrar också till att göra det svårare att försöka attackera din sajt med ett script som testar sig igenom olika lösenord – något du också kan försvåra genom att använda Wordfence och låta den pluginen blockera återkommande felaktiga lösenord efter ett visst antal besök.

När det gäller just lösenord och inloggningsnamn är det för övrigt en väldigt oerhört god ide att inte använda admin som inloggningsnamn – sätt något annat och sätt sedan ett lösenord som är åtminstone 16 tecken långt och inte läsbart eller ens memorerbart. Använd Keychain i OS X eller något program som exempelvis 1Password eller pwSafe för att spara det.

När det gäller alla de nycklar som ska in i wp-config.php har WordPress själva en automatisk generering av dessa här. Radera raderna ur din wp-config.php och lägg in de som du får på den sidan och spara sedan wp-config.php.

Summering

Vad kostar det då mig att dra ner brallorna på detta sätt och visa för omvärlden att servrar jag driver blev hackade? Ingenting egentligen – det är ingen skam i att erkänna att man gjort fel, men det är en betydligt större i skam i att inte lära sig av sina misstag och kanske en värre att inte hjälpa andra som kan råka illa ut.

Det finns ingen genväg till en säker webbsajt, oavsett vilken plattform den drivs på och oavsett vilket operativsystem du kör i botten, så oavsett om du använder Linux, FreeBSD eller OS X på din webbserver kräver det att du gör din hemläxa själv. Kör du en gammal version av PHP eller kod skriven i PHP (för att ta två exempel) som har någon form av säkerhetsproblem är det enda sättet att vara etthundra procent säker att stänga av webbservern helt och hållet.

Kör du din WordPress-sajt på ett webbhotell, se till att de ligger i framkant när det gäller att stödja nya versioner av exempelvis PHP (som exempelvis FS Data) och se själv till att du inte avaktiverat den automatiska uppdateringen av WordPress som numera är inbyggd.

Se till att ta backup på din sajt minst en gång per dag (inklusive dess databas) , och om du installerar en massa tillägg i form av plugins, se till att de är säkra och schyssta (det räcker inte med att en bunt personer har röstat på att pluginen fungerar ordentligt, använd Google och sök efter säkerhetsproblem med den plugin du överväger) och se till att du raderar alla plugins från din WordPress-installation som du inte använder (att avaktivera dem räcker inte).

Lycka till!


Macpro är annonsfri för att göra din läsupplevelse bättre.
Läs mer här om hur du hjälper Macpro förbli annonsfri

© 2004 - 2017 Joacim Melin