Módszerek a WordPress biztonságossá tételére, és hogy miért nem érnek ezek lófaszt se.

A mostani betörés során kénytelen voltam utánaolvasni, hogy milyen lehetőségek vannak a WordPress biztonságossá tételére. Számos oldal foglalkozik ezzel a kérdéssel, ám sajnos azt kellett tapasztalnom, hogy csak a mítoszokat terjesztik. Ezekbe a mítoszokba vetett hit pedig nem vezet máshoz, mint hamis biztonságérzethez. Nézzük sorba, hogy mit is lehet tenni.

A WordPress naprakészen tartása

Ez egy amúgy igen fontos dolog. Mondhatni ez az alap, ami nélkül teljesen értelmetlen WordPress oldalt üzemeltetni. Védelmet ugyan nem ad, hiszen csak akkor van bármi haszna, ha a meglévő hiba kihasználása előtt frissítjük a rendszerünket. Tény viszont, hogy a crackereknek sokkal több idejük van, és általában hamarabb találják meg a hibákat mint a fejlesztők.

A pluginek naprakészen tartása

Ugyanaz mint a WordPress naprakészen tartása. Sajnos amíg a WordPress-t sokan fejlesztik és még többen használják, így a hibák hamar kiderülhetnek és hamar javítják is őket, addig a plugineket nem ritkán egy ember fejleszti. Vagy rosszabb esetben fejlesztette valamikor, de már beleunt és egy betűt se ír hozzá. Épp ezért nagyon-nagyon fontos, hogy tényleg csak a szükséges pluginek legyenek telepítve, és lehetőleg olyanok, amiket egyrészt folyamatosan frissítenek, másrészt lehetőség szerint ne egy ember munkája legyen.

Biztonságos jelszavak használata

Ezt amúgy előszeretettel fordítják erős jelszavaknak, de erős a tevehúgy szaga. A jelszó vagy biztonságos, vagy nem jelszó. Egyetlen jó dolog van, hogy a próbálgatásos jelszótörést viszonylag könnyen észre lehet venni. Természetesen az, hogy észrevesszük, és rendkívül ügyesen tiltjuk a próbálkozót, épp annyit ér, mintha pogány átkokat mormolnánk. Vagy még annyit se. Tehát rendkívül bölcs dolog kerülni az olyan jelszavakat, hogy “admin” meg “123”. Meg azokat is, amik egyeznek a felhasználói névvel. De ez már egy másik, hosszú téma.

Az “admin” felhasználó törlése

A Security through obscurityW egyik esete. A Wikipédia elég szemérmesen fogalmaz, gyakorlatilag annyit ér, mint döglött nyúlnak a rigófütty. A lényege az, hogy csinálunk egy új WordPress accountot, mondjuk Béla néven, és a Béla adminisztrátor lesz, majd Bélaként bejelentkezve töröljük az admin felhasználót. Hogy miért? Mert a gonosz emberek tudják – sejtik -, hogy admin felhasználó tuti van a rendszerünkben. Viszont ha ezt a körtáncot ellejtjük, akkor csak a rendkívül ostoba vagy kezdő gonoszokat lehet megtorpanásra bírni, az enyhén haladó szintűek csak vállat vonnak.

Ártani viszont nem árt, de kár túl nagy hasznot tulajdonítani neki.

A felhasználói név elrejtése a postoknál

A Security through obscurityW másik esete. Lásd döglött nyúl vs. rigófütty.

A wp_ táblaprefix megváltoztatása

Nyúl.

A WordPress verzió elrejtése

Az lenne a lényege, hogy úgyse jönnek rá, hogy melyik verziójú WordPress van feltelepítve. Hát persze.

A jogosultságok megszigorítása

Na, ez egy olyan dolog, aminek értelme is lehet. A WordPress egyik nagy előnye, hogy kápráztatóan egyszerű frissíteni, vagy új plugineket feltelepíteni. Ennek sajnos az az ára, hogy a webszervernek tudnia kell írni magukat a WordPress fájlokat, így ha valaki a Webszervert vagy  a WordPress-t, vagy egy plugnit meg tud patkolni, akkor kb. bármire képes lehet.

Persze ha a fájlok nem írhatók, akkor máris sokkal-sokkal nehezebb dolga van annak, aki ártani akar. Ugyanakkor a kényelem van lendületből tökön bökve, ami egyenes úton vezet oda, hogy késnek, elmaradoznak a frissítések. Ez viszont újfent egy könnyelmű dolog.

FTP helyett SFTP

Az első gond, hogy a legtöbb ember a fenti mondatból csak a helyett szót ismeri. A második, hogy amíg naponta fordulnak elő betörések elmentett (S)FTP jelszavak miatt, addig inkább azt lehetne mondani, hogy egyáltalán ne használjon senki se ilyesmit. Akkor viszont marad a WordPress saját frissítése, ami viszont alapból egyenértékű az öngyilkossággal1. A harmadik gond, hogy elenyésző esélyét látom annak, hogy valakinek a jelszavát így ellopják. Ártani semmiképp se árt, de túl sok javulást nem hoz.

SSL használata (HTTPS)

Kb. ugyanaz igaz rá mint a FTP-SFTP esetén: ártani semmiképp se árt, de túl sok javulást nem hoz. Kivéve ha az oldalt sokan írják pl. netcaféból vagy hasonló, nem megbízható hálózatból. Akkor viszont alapvető követelmény, de önmagában még semmitől se véd.

Az adatbázisok szétválasztása

Csak akkor van jelentősége, ha a gépen nem egy, hanem több WordPress oldal van, amiket egyetlen WordPress telepítés szolgál ki. Annyi az előnye, hogy a többi WordPress adatbázis letörléséhez több idő kell.

A wp-admin, wp-includes, wp-config.php védelme

Ezek azok, amiket alapból nem szabad írnia (sőt, olvasnia se) senkinek, ezért megmondjuk a webszervernek, hogy ezekhez senkit se engedjen oda. Ez is nagyon mókás dolog, ártani valószínűleg nem árt, de a haszna elkeserítően csekély.

A login.php védelme

Brute-force törések ellen (se) véd, ha a login.php-t extra jelszóval védjük. Más ellen nem, így aztán olyan döbbenetesen nagy védelmet nem ad. Igaz ártani se árt, kivéve ha elfelejtjük a jelszót. Másik lehetséges védelem, hogy csak bizonyos IP tartományokból engedjük elérni. Ez hamar a kényelem rovására mehet ám sok esetben megmentheti a blogot. Sok esetben pedig annyit se számít mint tengerben a fingás

A fájlmódosítás kikapcsolása

Meg lehet mondani a WordPress-nek, hogy ne is gondoljon arra, hogy egyes fájlokat (pl. témák vagy pluginek) módosítani lehessen. Ugyanis van egy beépített szerkesztgető valami, de rendkívül kevesen használják, a maradék 99.999% kikapcsolhatja. Persze ha már odáig jutott valaki, hogy fájlokat módosíthatna, akkor már van pár módszere arra, hogy gonosz legyen. Tehát ez se ér sokkal többet mint esernyő az atomvillanás ellen.

Tűzfal pluginek

Őszintén szólva fogalmam sincs. Talán van hasznuk, de hogy melyiknek és mennyi, azt ki kellene próbálni.

Na és akkor mi legyen?

Számos dolgot lehet tenni tehát azért, hogy egy-egy WordPress telepítés biztonságosabb legyen. Ám nagyon-nagyon fontos azt észben tartani, hogy a legtöbbjük semmiféle problémát nem old meg, csupán elrejti a hibát, ezáltal hamis biztonságérzetet ad. Persze nem egy esetben megakadályozhat betöréseket; az én esetemben most a define('DISALLOW_FILE_EDIT', TRUE); hasznos lett volna, de attól még épp úgy átírták volna a jelszavamat. Ha a jelszavamat átírták, akkor már nem nagy puki törölni pl. az összes postot az adatbázisból, és azt visszaállítani esetleg nagyobb munka, még ha van mentés akkor is.2

Jogos a kérdés, hogy akkor mi legyen? Semmi értelme védekezni? Hát majdnem. Először is, pár alapvető dolgot be kell tartani. Kb. annyit, hogy normális jelszót kell használni, és naprakészen kell tartani a cuccot. Sajnos az újratelepítéskor derült ki, hogy pár plugin, amit amúgy használnék, egyszerűen megszűnt létezni, azaz már egyáltalán nem fejlesztik tovább, sőt, már fel se tudom telepíteni a régi verziót se. Illetve az indiai tehénpásztor fejlesztők még mindig nem válaszoltak az általam felvetett problémára, ami végül is az egész kalamajkát okozta, de szerencsére a hup.hu közössége hamar adott megoldást.

Komolyabb – értsd céges – környezetben viszont biztosra kéne menni. Lehetséges megoldás pl. a cloudflare és társai használata, azaz olyan oldalaké, amelyek figyelik a gépre irányuló forgalmat, és gyanú esetén közbeavatkoznak. Én ezt jobbnak tartom mint a tűzfal pluginek telepítését, ám biztos vagyok benne, hogy egy szint felett ezek is fizetősek. Sajnos olyan megoldás nincs, amit az ember egyszer feltelepít, és utána minden remek lesz, örökké.

Láb, jegyzet
1. Jó, ez nyilván így nem igaz, de az alapvető probléma attól még megmarad
2. Igen, csináltam már olyat, hogy a mysql logból eltekertem egy adott időpillanatig, hogy az az után következő törléseket már kihagyjam. Nem lehetetlen, de ha nem muszáj, akkor nem csinálom.

You may also like...