A múlt hét a WordPress biztonsága körül zajlott, ezért most szeretnék néhány biztonsági tippet, trükköt, és az ezeket segítő bővítményeket ismertetni veletek.
Úgy tűnik ebből egy cikk sorozat lesz, bár nem így indult. De most nem szeretnék egyszerre sok információt átadni.
Először egy-két biztonsági alap dolgot fogok firtatni. Majd a wp-admin könyvtár biztonságát érintő bővítményeket, és tippeket.
A cikk következő részében a content, azon bellül is a bővítmény és sablonok könyvtárak védelmét nézzük át. A harmadik rész pedig a 2.6 újdonságait mutatja majd be a biztonságra nézve, valamint az SSL támogatást és a biztonságos Cookie kezelés mikéntjét.
Általános dolgok
Frissítés
Nem győzzük hangsúlyozni a frissítések fontosságát. A WordPress fejlesztői nem a saját szórakoztatásukra adnak ki újabb és újabb verziókat. Vagyis annak érdekében is, de főleg hibajavító verziók érzkeznek újabban, annak érdekében, hogy kritikus réseket befoltozzanak.
Biztonsági mentés
Ennek a szerepéről is sokat beszélünk, de kevésbé alkalmazzuk, legalábbis ez a tapasztalatom. Te mikor csináltál utoljára teljes adatbázis mentést a blogodon található bejegyzésekből? És ezt utoljára mikor mentetted át külső adathordozóra, külső gépre?
Tudjátok nem is volt olyan régen az, amikor az egyik nagy szolgáltató szerver termében a szerverek nagyrésze a tápig vízben állt… Vajh, ha a te blogod egy olyan szerveren lett volna, mikor állhatott volna újra üzembe?
Adatbázis mentéshez használahatod a WordPress Database Backup névre hallgató bővítményt.
Nálam rendszeres, napi adatbázis mentés fut, de tanácsos időnként, mondjuk egy WordPress kompatibilis XML-be is akár kimenteni az adataidat, és ilyenkor könnyen importálható marad. Én néha be szoktam importálni a teljes blogom egy-egy WordPress MU alapú blog szolgátatóhoz, mint például a PirateBay blog szolgáltatása a BayWords.com.
Biztonságos kapcsolat
Amikor csak lehetőségünk van rá, a blogunkra SFTP-n vagy SCP-n keresztül töltsünk fel háttéranyagot, bővítményeket, új sablonokat. Mivel a sima FTP protokollon keresztül küldött adatok titkosítatlanul folynak. Oké, nem te vagy a NASA, hogy arra legyen kiváncsi bárki is, hogy milyen adatot töltesz fel. De mivan, ha mégis?
Egyébként tudtad, hogy a blogod admin felülete a 2.6-os verzió óta képes HTTPS alapon is működni? Erről bővebben majd a harmadik részben, fogok írni.
Fájl jogosultságok
Először is tanuljuk meg, mit jelentenek a unix rendszerek fájl jogosultsági maszkjai, utánna pedig nézzük meg, hogy a blogunk lényges fájljai milyen jogosultságokkal rendelkeznek.
Ha nem dedikált szerverünk, vagy dedikált VPS-ünk van, akkor ez különösen fontos. Természetesen egy szolgáltatónak minden tőle telhetőt meg kell tennie, az ügyfelek adatainak eszakálása érdekében, de mi is tegyük meg a magunkét, és állítsuk be megfelelően a fájlok és könyvtárak jogosultságát.
Admin könyvtár védelme
Az első és kézenfekvő megoldás, a .htaccess alkalmazása IP címre, tartományra szűkítéssre, amennyiben ez megoldható. Nyilván nem járható út, ha az internet szolgáltatód mindig más IP tartományból oszt neked IP-címet.
(Két évvel ezelőtti tapasztalataim alapján a T-onlány képes volt egymás után kiosztani olyan IP-címet, amiben nem volt közös tag. Azaz minden tartomány különbözött, ilyenkor ez a megoldás nem alkalmazható.)
A htaccess fájlok használatának a lehetőségét a szolgálattód tudja engedélyezni, erre nem létezik „meghekkeljük phpből” jellegű megoldás.
Az IP címre szűkítés egyébként ideális lehet, egy fix irodai IP-címmel rendelkező szerkesztőségnek bejegyzéseket írni a céges blogra. Ennek a mikéntje annyiban merül ki, hogy a wp-admin könyvtár gyökerében létrehozunk egy .htaccess fájlt, hasonló tartalommal:
Order deny,allow Deny from all allow from xx.xx.xx.xx
Nyilván a xx.xx.xx.xx cseréljük a pontos IP-címünkre.
Használhatóak még a következő formák is:
– 10.1.0.0/16
– 10.1
– nitro.glicer.in
– nsa.gov
– .gov
AskApache
Az admin hozzáférés korlátozására nyilván vannak még más módja is. Talán az egyik legismertebb, az AskApache bővítmény, amit arra szokás használni, hogy egy plusz biztonsági szintet emeljen a login oldal elé, vagyis, már a login oldalra bejutáshoz is egy standard HTTP authentikáción kell átmennünk.
De ennél jóval többet tud az AskApache, tartalmaz nyilvános proxyk elleni védelmet, különböző spam filter modulokat (referer ellenőrzés, trackback spam szűrés, UserAgent ellenőrzés, Content-Length vizsgálat, Content-Type vizsgálat…), exploit elleni védelmek (directory traversal, illegális karakter formázások, nem standard HTTP parancsok…), valamint tárolja a jelszó fájlok korábbi állapotait. Ugye milyen kis aranyos? 🙂
WP Security Scan
Az All-in-One SEO Pack jelenlegi karbantartójának egy régebbi bővítménye, ami átvizsgálja a fájl és könyvtár jogosultságokat, a jelszavakat, és az adatbázist gyenge pontok után kutatva. Valamit segít elrejteni a szoftver verzióját, és eltávolítja a Generator META tagot az oldal fejlécéből.
Login LockDown
Arra szokás használni, hogy megakadályozza az esetleges brute force jellegű támadásokat a login oldal ellen. Az alap beállításban 5 percen bellül 3 sikertelen bejelentkezési kísérlet után 1 óra bünti jön, és csak utánna próbálkozhatunk újra belépni, miután felkeltünk a sarokból a kukoricán térdelésből.
A sikertelen bejelentkezési kísérleteket ezen kívül még naplózza is.
Nos, ma eddig jutottunk, hamarosan (valószínűleg a jövőhéten) folytatás következik.
Ez igen! Ezt a pezsgést! 🙂 😉
Örülök egy ilyen kis (nekem)kínai nyelvezetnek tűnő szösszenetnek, mert megmutatja, hogy milyen kis porszem vagyok e való Wilágban. 🙂
A WordPress Database Backup, a megadott linken található bejegyzés szerint 2.3-ig végzi a munkát. Azután mi lesz a helyzet?
„Version 2.1.3 automatically includes the tables used in WordPress 2.3. In addition, now you can select all of the non-WordPress core tables in one click.”
Ez egy bugfix.. ettől még megy a plugin…
A WordPress Database Backup használatát kiváltja a phpAdmin-nal végzett mentés is, ugye? Csak az talán kicsit több lépéses?
elvileg kiváltja. gyakorlatilag a tárhelyedtől függ, nekem van olyan elyen wp-m, ahol a dp-backuppal készített mentés hiányos, nem szed ki mindent az adatbázisból, így phpmyadminnal mentek. azonban az esetek többségében megfelelő