Gábor írt egy remek cikket tegnap a Bejelentkezésről, ami sokak számára lehetett gondolatindító, de számomra mindenképpen az volt. És mivel már egyszer – khm, majdnem 8 éve – írtam a biztonság témájáról, ezért úgy gondoltam, hogy ez méltó folytatása és kiegészítése is lesz.

A jelszavakról általában

Az egyik legfontosabb dologról, a jó felhasználónév választásról már volt szó Gábor cikkében, de az erős jelszó választásról nem. Eltérő nézetek vannak erről, de ha telepítettél WordPress-t az elmúlt 3 évben akkor találkozhattál a jelszó erősség kijelzéssel, amelyet én személyesen már-már túl paranoidnak tartok. De Automatticos körökben különösen népszerű az a nézet, hogy az a jelszó, amit meg tudsz jegyezni az nem elég erős.
Viszont, egy 32 karakter hosszú krikszkrakszokkal telerakott jelszót senki nem fog tudni fejben tartani, erre jó megoldás egy jelszó kezelő alkalmazás, nálunk az irodában a LastPass volt az egyik legnépszerűbb. Erre találták ki, biztonságosabb a böngészőben tárolt jelszavaknál, minden népszerű eszközre elérhető, egyéni felhasználásra ingyenes, de az évi $12 sem tűnik soknak a prémium verzióért.

Az alapokról még egy kicsit

Hajlamosak vagyunk néha azt hinni, hogy azok a megoldások, amiket használunk azok mind biztonságosak, ezért nem vagyunk elég óvatosak. Vagy azt gondoljuk, hogy mi oldalunk pici és nem lehet robotok célpontja.

Nincs olyan oldal, amit nem érné meg egy bot hálózatnak megpróbálni feltörni, így a méret nem számít, vakon próbálkoznak legtöbbször. Vagyis, te oldalad is bármikor célpont lehet. Kérdés nem az, hogy fognak-e próbálkozni, hanem a legjobb esetben is csak az, hogy mikor.

Többféle megoldást is fontolóra kell venni, amikor további védelmi szinteket szeretnénk a rendszerbe építeni.

Limiter

Az egyik legegyszerűbb, és egyben legkevésbé kifinomult megoldás az, ha a tárhely szolgáltatód van annyira körültekintő, jó fej és hozzáértő, hogy a wp-login.php -ra irányuló kéréseket limitálja és egy adott megtekintési szám után lassítja.

Például 5 próbálkozás után a bejelentkező oldal hiba kódot (HTTP 403) fog adni a következő 3-5 percben. Ez arra elég, hogy a brute force támadásokat kellően lelassítsa. így egy idő után nem fognak tovább próbálkozni, mert a brute forcenak akkor lehet eredménye, ha minél gyorsabban, minél több kombinációt ki tudnak próbálni, ahogy elkezd a próbálkozások közötti válaszidő növekedni úgy válik beláthatatlanná a jelszó feltöréséhez szükséges idő.

Reverz proxy

A következő említésre méltó megoldás az hogy egy megbízható reverz proxy szolgáltatást teszünk az oldalunk elé, a két legnépszerűbb a CloudFlare és Incapsula.

A két szolgáltatás hasonló, de vannak különbségeik, de mindkettőben közös az, hogy nyilvántartanak ilyen bothálózatokat és automatikusan megfogják a kártékony próbálkozási kísérleteket akár már az előtt, hogy elérné az oldalad.

Mindkét szolgáltató rendelkezik ingyenes csomaggal, amivel már elérhetőek az előnyök, az ingyenes csomag a CloudFlarenél ingyenes SSL-t is biztosít a teljes domain név számára, míg az Incapsula ezt csak a fizetős csomagjában nyújtja, cserébe jelentősen szélesebb az elérhető biztonsági megoldások palettája.

Jól viselkedj!

Létezik egy népszerű és ingyenes megoldás, amely a látogatók viselkedését figyeli az oldalunkon, és ha az IP-cím szerepel valamely nyilvános adatbázisban, akkor nemes egyszerűséggel nem engedi az oldalunkhoz hozzáférni a látogatót, igaz ez a bejelentkező felülettől kezdve a hozzászólásokon át a tartalom megtekintéséig. (Ez utóbbit nem lehet hatékonyan megakadályozni, ha statikus oldal cachet alkalmazunk.)

Ezt a megoldást Bad Behaviornek hívják, és több jó nevű oldal is alkalmazza a megoldásukat, a bővítményük ingyenesen letölthető, és a bekapcsoláson kívül semmi különösebb varázslatot nem igényel.

Bízzuk a WordPress.com felhőre!

Egy éve megvan a lehetősége minden Jetpack bővítményt használónak arra, hogy különböző biztonsági funkciókkal tömje tele az oldalát. Az egyik ilyen a Jetpack Protect, ami a fent említett brute force típusú támadásokkal szemben nyújt hatékony segítséget. Ezenkívül lehetséges saját IP-címet, vagy hosztnevet whitelistre tenni, így azt is eltudjuk kerülni, hogy kizárjuk magunkat az oldalunkról.

Egy másik biztonsági lépcső a Single Sign On lehetőség, ezt egy picit trükkösebb bekapcsolni, de erről Jeremy beszélt a legutóbbi Meetupon. A lényeg annyi, hogy a saját oldalunk a bejelentkezéshez át fog irányítani a WordPress.com-ra, és az ottani felhasználói fiókunkkal tudjuk elérni a blogunkat.

Az újonnan regisztráló felhasználók is ide lesznek átirányítva, és megkapják ugyanazokat a jogokat, mintha közvetlenül az oldalunkon regisztráltak volna. (Amennyiben le van tiltva a regisztráció az oldalunkra, akkor természetesen nem fognak tudni regisztrálni.)

A módszer előnye, hogy a támadások így a WordPress.com végeláthatatlan mennyiségű szerverparkjára fognak ömleni, és nem a mi kis oldalunkra, megbízható saját forrásokból vannak kártékony bothálózatokról információik (Akismet, BruteProtect) így ezeket a támadásokat hatékonyan eltudják hárítani. Mi pedig akkor is SSL-en keresztül tudunk belépni az admin felületünkre, ha az oldalunkon nincs SSL támogatás.

Végszóként még annyit szeretnék, hogy bármennyire jó védelmet is valósítottunk meg az oldalunkon, ha a szerver környezet vagy más egyéb hozzáférésünk (pl. FTP) nem biztonságos, akkor az egész semmit nem ért.