A WordPress telepítése lehet olyan biztonságos vagy nem biztonságos, amennyire csak szeretné. Ismerje meg, melyik öt dolog a legfontosabb a biztonság szempontjából.
A WordPress biztonságával kapcsolatos aggodalmak és panaszok nem újdonságok.
Ha CMS-re van szüksége, és olyan szolgáltatóhoz fordul, aki nem ismeri a WordPress-t, akkor a biztonság az első számú probléma, amelyről hallani fog. Ez azt jelenti, hogy mindenkinek el kell hagynia a WordPress-t, és statikus webhelygenerátorra vagy fej nélküli CMS-re kell váltania?
Nem, mert mint minden igazságnak az életben, ennek is sok oldala van.
Tartalomjegyzék
A WordPress nagyon nem biztonságos?
Vessünk egy pillantást néhány hatalmas webhelyre, amelyek a WordPressre épültek:
- TechCrunch
- A New Yorker
- BBC Amerika
- Bloomberg
- MTV Híradó
- PlayStation blog
Tehát mi készteti ezeket a vállalatokat – az abszurdan mély zsebekkel és az elképesztő munkaerővel –, hogy ne váltsanak le a WordPressről? Ha úgy gondolja, hogy a válasz az örökölt kód, gondolja át újra: ezeknél a neveknél az adatbiztonság és a nyilvános imázs végtelenül fontosabb, mint egy egyszerű migráció, amely (becslésem szerint) kevesebb, mint 200 000 dollárba kerül.
A mérnökeik biztosan tudják, mit csinálnak, és nem látnak alapvető, megoldhatatlan biztonsági problémákat a WordPress-szel?
Még nekem is van szerencsém kezelni egy olyan WordPress-telepítést, amely havonta 3,5-4 millió látogatót lát. A biztonsági rések teljes száma az elmúlt nyolc évben? Nulla!
Így . . . biztonságos a WordPress?
Elnézést, ha trollkodásnak tűnik, de itt van a válaszom:
Azért mondom, mert mint minden igazság az életben, ez is bonyolult. Ahhoz, hogy jogos választ kaphassunk, először is meg kell értenünk, hogy a WordPress (vagy bármilyen előre felépített CMS) nem olyan, mint egy szekrény, amelyet végleg felragasztunk valahova, és készen vagyunk vele.
Ez egy összetett szoftver, sok függőséggel:
- PHP, amely nyelvvel készült
- Nyilvánosan látható gép, amelyen a telepítés található
- A látogatók kezelésére használt webszerver (Apache, Nginx stb.)
- A használt adatbázis (MySQL/MariaDB)
- Témák (PHP, CS és JS fájlok kötegei)
- Beépülő modulok (PHP, CS és JS fájlok kötegei)
- És még sok más, attól függően, hogy a telepítés mennyit kíván elérni
Más szavakkal, a biztonsági rést ezen varratok bármelyikén WordPress-sértésnek nevezzük.
Ha a kiszolgáló root jelszava admin123 volt, és feltörték, ez a WordPress biztonsági hibája?
Ha a PHP-verzió biztonsági rést tartalmazott, vagy ha a megvásárolt és telepített új bővítmény kirívó biztonsági rést tartalmazott; stb. Összefoglalva: Egy alrendszer meghibásodik, és ez egy WordPress biztonsági hiba.
Mellesleg, kérjük, ne hagyja, hogy ez azt a benyomást keltse, hogy a PHP, a MySQL és az Apache nem biztonságos. Minden szoftvernek vannak sebezhetőségei, amelyek száma a nyílt forráskód esetében megdöbbentő (mert mindenki számára elérhető és elemezhető).
Mondta valaki, hogy „biztonságos”? 😛
Amit ebből a gyakorlatból tanulunk:
Önmagában semmi sem biztonságos vagy bizonytalan. A különböző felhasznált alkatrészek alkotják a láncszemeket, a lánc természetesen olyan erős, mint a leggyengébb közülük. A történelem során a WordPress „nem biztonságos” címkéje a régi PHP-verziók, a megosztott tárhely és a nem megbízható forrásokból származó bővítmények/témák hozzáadása volt.
Ugyanakkor néhány meglehetősen gyakori hiányosság sebezhetővé teszi a WordPress telepítését azok számára, akik tudják, hogyan kell kihasználni őket, és elszántak. És ez a bejegyzés erről szól. Tehát minden további nélkül (és körkörös érvek nélkül) kezdjük.
A legjobb WordPress kiskapuk, amelyeket a hackerek kihasználhatnak
A WordPress táblázat előtagja
A híres 5 perces telepítés a legjobb dolog, ami a WordPress-szel történhet, de mint minden telepítő varázsló, ez is lustává tesz minket, és alapértelmezésben hagyja a dolgokat.
Ez azt jelenti, hogy a WordPress-táblázatok alapértelmezett előtagja a wp_, ami olyan táblázatneveket eredményez, amelyeket bárki kitalálhat:
- wp-felhasználók
- wp-opciók
- wp-posztok
Most vegyük fontolóra az SQL Injection néven ismert támadást, ahol a rosszindulatú adatbázis-lekérdezéseket ügyesen illesztik be, és futtassák a WordPress-en belül (kérjük, vegye figyelembe – ez semmiképpen sem kizárólagos WordPress/PHP-támadás).
Bár a WordPress beépített mechanizmusokkal rendelkezik az ilyen típusú támadások kezelésére, senki sem tudja garantálni, hogy ez nem fog megtörténni.
Tehát ha valamilyen módon a támadónak sikerül egy lekérdezést futtatnia, például DROP TABLE wp_users; DROP TABLE wp_posts;, az összes fiókja, profilja és bejegyzése egy pillanat alatt törlődik, és nincs esély a helyreállításra (hacsak nincs biztonsági mentési séma, de még akkor is adatvesztésre kerülhet az utolsó biztonsági mentés óta ).
Az előtag egyszerű megváltoztatása a telepítés során nagy dolog (ami nem igényel erőfeszítést).
Valami véletlenszerű, például sdg21g34_ ajánlott, mert értelmetlen és nehéz kitalálni (minél hosszabb az előtag, annál jobb). A legjobb az egészben az, hogy ennek az előtagnak nem kell emlékezetesnek lennie; az előtagot a WordPress el fogja menteni, és soha többé nem kell aggódnia miatta (mint ahogy az alapértelmezett wp_ előtag miatt sem!).
Az alapértelmezett bejelentkezési URL
Honnan tudod, hogy egy webhely WordPress-en fut? Az egyik árulkodó jel az, hogy a WordPress bejelentkezési oldala jelenik meg, amikor hozzáadja a „/wp-login.php” címet a webhely címéhez.
Példaként vegyük a webhelyemet (http://ankushthakur.com). WordPress-en van? Nos, folytassa és adja hozzá a bejelentkezési részt. Ha túl lustának érzi magát, a következő történik:
¯_(ツ)_/¯
WordPress, ugye?
Ha már ennyit tudni, a támadó ujjongva dörzsölheti a kezét, és elkezdhet csúnya trükköket alkalmazni a Bag-O’-Doomból ábécé sorrendben. Szegény én!
A megoldás az, hogy megváltoztatja az alapértelmezett bejelentkezési URL-t, és csak azoknak adják meg, akikben megbízhatók.
Például ez a webhely is WordPress-en van, de ha felkeresi a http://etoppc.com.com/wp-login.php oldalt, csak mély csalódást fog kapni. A bejelentkezési URL rejtett, és csak az adminisztrátorok ismerik?
A bejelentkezési URL módosítása sem rakétatudomány. Fogd csak ezt csatlakoztat.
Gratulálunk, most újabb frusztráló biztonsági réteget adott hozzá a brutális támadásokkal szemben.
A PHP és a webszerver verziója
Már megbeszéltük, hogy minden valaha írt (és készülő) szoftver tele van kihasználásra váró hibákkal.
Ugyanez vonatkozik a PHP-re is.
Még ha a PHP legújabb verzióját használja is, nem lehet biztos benne, hogy milyen biztonsági rések léteznek, és egyik napról a másikra felfedezhetik azokat. A megoldás az, hogy elrejti a webszerver által küldött fejlécet (soha nem hallott fejlécekről? olvassa el ez!), amikor egy böngésző csatlakozik hozzá: x-powered-by.
Így néz ki, ha megnézi kedvenc böngészője fejlesztői eszközeit:
Amint itt láthatjuk, a webhely azt mondja, hogy Apache 2.4-en fut, és a PHP 5.4.16-os verzióját használja.
Ez már rengeteg információ, amelyet ok nélkül továbbítunk, és segít a támadónak leszűkíteni az eszközök kiválasztását.
Ezeket (és hasonló) fejléceket el kell rejteni.
Szerencsére gyorsan meg lehet csinálni; sajnos kifinomult technikai tudásra van szükség, mert bele kell merülnie a rendszer zsigerébe, és fontos fájlokkal kell vacakolnia. Ezért azt tanácsolom, hogy kérje meg webhelytárhely-szolgáltatóját, hogy tegye ezt meg Ön helyett; ha nem látják, hogy egy tanácsadó meg tudja-e csinálni, bár ez nagymértékben az Ön webhelyén múlik, hogy a beállításuk rendelkezik-e ilyen lehetőségekkel vagy sem.
Ha ez nem működik, ideje tárhelyszolgáltatót váltani, vagy VPS-re váltani, és tanácsadót felvenni biztonsági és adminisztrációs problémák miatt.
Megéri? Ezt csak te döntheted el. 🙂
Ó, és ha kíváncsi a biztonsági fejlécekre, itt a megoldás!
Bejelentkezési kísérletek száma
A hacker kézikönyvének egyik legrégebbi trükkje az ún Szótártámadás.
Az ötlet az, hogy nevetségesen sok (lehetőleg milliónyi) kombinációt próbálj ki egy jelszóhoz, hacsak egyik sem sikerül. Mivel a számítógépek villámgyorsan végzik tevékenységüket, egy ilyen ostoba terv ésszerű, és ésszerű időn belül eredményeket hozhat.
Az egyik gyakori (és rendkívül hatékony) védekezés az volt, hogy késleltetést adnak hozzá a hiba megjelenítése előtt. Ez arra készteti a címzettet, hogy várjon, ami azt jelenti, hogy ha egy hacker által használt szkriptről van szó, túl sokáig tart a befejezés. Ez az oka annak, hogy számítógépe vagy kedvenc alkalmazása kissé ugrál, majd azt mondja: „Hoppá, rossz jelszó!”.
Mindenesetre a lényeg az, hogy korlátozza a bejelentkezési kísérletek számát a WordPress webhelyére.
A megadott számú próbálkozáson túl (mondjuk öten) a fióknak zárolva kell lennie, és csak a fióktulajdonos e-mail-címén keresztül lehet helyreállítani.
Szerencsére ennek elkészítése egy kis tortúra, ha találsz egy szépet csatlakoztat.
HTTP vs. HTTPS
Az SSL-tanúsítvány, amely miatt a szállítója zaklatja Önt, fontosabb, mint gondolná.
Ez nem pusztán egy hírnév eszköz, amely egy zöld lakat ikont jelenít meg a böngészőben, amelyen a „Biztonságos” felirat áll; Inkább egy SSL-tanúsítvány telepítése és az összes URL „https” protokollon való működésre kényszerítése önmagában elegendő ahhoz, hogy webhelye nyitott könyvből rejtélyes görgetéssé váljon.
Ha nem érti, hogyan történik ez, kérjük, olvassa el az úgynevezett a ember a középső támadásban.
A számítógépről a szerverre áramló forgalom lehallgatásának egy másik módja a csomagszippelés, amely az adatgyűjtés passzív formája, és még csak nem is kell a közepébe helyezkednie.
Azokon a webhelyeken, amelyek egyszerű „HTTP-n” futnak, a hálózati forgalmat elfogó személy jelszavai és hitelkártyaszámai egyértelmű, egyszerű szövegként jelennek meg.
Forrás: comparitech.com
Ijedős? Nagyon!
Ha azonban telepít egy SSL-tanúsítványt, és az összes URL-t „https”-re konvertálják, ezek az érzékeny információk halandzsaként jelennek meg, amelyet csak a szerver tud visszafejteni. Más szóval, ne izzad el azt a néhány dollárt évente. 🙂
Következtetés
Vajon ennek az öt dolognak az irányítása alatt biztonságossá válik a webhelye?
Nem, egyáltalán nem. Amint azt számtalan biztonsági cikk mondja, soha nem lehet 100%-os biztonságban, de ésszerű erőfeszítéssel ezeknek a problémáknak a nagy része kiküszöbölhető. Fontolja meg a SUCURI felhő WAF használatát webhelyei holisztikus védelme érdekében.