Ismét egy csokor kérdés és válasz, folytatván a múlt héten megkezdett sort. Lassan de biztosan haladunk a teljesen általános kérdések irányába (hogy védjem meg az oldalamat), és ezekre egyre nehezebb válaszolni a konkrét oldal ismerete nélkül.
A közeljövőben ismét várható WP biztonsági est, ott is lehet majd kérdezni! Most pedig lássuk az e heti kérdéseket!
Miklós kérdései:
WordPress-t használok, és az admin felhasználót megszüntettem, mást használok helyette, de a cikkeknél admin-ként jelenik meg. Létrehoztam agy másikat is, kisebb jogkörrel, viszont látom, hogy mivel létező felhasználó, próbálják is felnyomni. Vajon melyik károsabb, ha a más nevű admint használom vagy ha létező szerkesztő felhasználóval írok?
Alapvetően ha kiderül hogy milyen felhasználóneveid vannak a rendszerben, akkor teljesen mindegy, hogy admin vagy kispista a felhasználónév. Amit tettél, a jogkör szűkítése jó ötlet volt. Így ha meg is fejtik a felhasználóhoz tartozó jelszót, jó esetben túl nagy kárt nem tudnak okozni az oldalon. Azért mondom hogy jó esetben, mert számos példát láttunk olyan hibára, amikor egyszerű feliratkozói jogkörből lehetett admin jogosultságokat szerezni. Ha bármilyen módon kinyerhető a rendszerből, hogy milyen felhasználóneveid vannak, akkor a támadások üzemszerűvé válnak. Ha letiltod a felhasználónevek listázását / megjelenítését, akkor is még hónapokig látható, hogy próbálkoznak a támadók.
A másik kérdésem pedig az, hogy ahogy a videódból már tiszta, hogy azonnal frissíteni kell a WP-t, de kérdés, hogy tesztelik-e a HU verziót és hogy ha esetleg eltöri a frissítés a rendszert, akkor backupból vissza (úgy olvastam, hogy régen előfordult ilyen)?
Az elmúlt másfél évben nem találkoztam ilyen jellegű problémával. Frissítési gond két ügyfelemnél volt: az egyiknél a tárhelyszolgáltató még 5.3-as PHP verziót használt. Ez a verzió két és fél éve(!!!) nem támogatott, így a bővítmények készítői sem nagyon foglalkoznak azzal, hogy ilyen régi rendszerrel kompatibilisek legyenek. Az egyik bővítmény nem volt kompatibilis ezzel a régi verzióval, így az oldal beborult. Végül a tárhelyszolgáltató bekapcsolt egy frissebb PHP-t.
A másik esetben 3 féle Divi sablon volt feltéve, és a frissítés során ezek valahogy „összevesztek”. A felesleges, régi Divi-k törlése megoldotta a problémát.
Összegezve: alapvetően a frissítés nem okozott problémát az elmúlt másfél évben. Ettől függetlenül ajánlott mentés készítése (adatbázisról is!) a frissítés előtt, hogy ha bármi beüt, legyen egy B terv. Azonban a mentésből ilyenkor sem ész nélkül állítanék vissza mindent, hanem elkezdeném egyesével visszarakni a bővítményeket, és megnézni, hogy melyik okozza a galibát.
István kérdése:
Szia! Ha valaki csak portfólió oldalként használja a wp-t (gmail címet ad meg levelezésre, nem blogol, inkább FB-n fogad bármiféle hozzászólást,véleményt, 3 havonta cseréli a jelszót,frissít amikor épp tud( 🙂 )igazából arra használja,hogy lássák a fotóit,munkáit,akkor mi lehet az a legsérülékenyebb „rész”,amit támadhat valaki( mondjuk csak azért,hogy ne jelenjen meg tartalom az oldalon)?
Nagyon szuper kérdés, sokaktól hallom, hogy „áááá, nekem csak egy egyszerű névjegy oldalam van, ki akarná ezt feltörni?”.
Bizonyos szempontból ezek a legnagyszerűbb célpontok. A támadónak az az érdeke, hogy minél hosszabb ideig észrevétlen maradjon, és ez által hosszabb ideig használhassa a Te erőforrásaidat spam küldésre, vagy más rendszerek támadására. Mivel ritkán nézel rá az oldalra, jó eséllyel később fogod észrevenni ha valami gond van.
A frissítéseket akkor teszed fel, amikor éppen tudod. Egyrészt jó, hogy frissítesz, másrészt viszont tudnod kell, hogy a „néha”, az nem elég. Amikor találnak egy biztonsági rést a WordPressben, vagy bővítményben, akkor első körben jelzik a fejlesztőknek. Ha a hibát javították, kijön a frissítés, és ebben a pillanatban lehet a hibát publikálni. Ahogy a hibát publikálják, szinte azonnal megindulnak a támadások, amelyek megpróbálják ezt a hibát kihasználni. Így ha mondjuk vasárnaponként frissítesz, és hétfőn publikálnak egy biztonsági hibát / javítást, akkor a következő vasárnapig védtelen vagy egy ismert támadással szemben. Ha ilyenkor bekapsz egy támadást, általában az első dolog, hogy a támadó telepít egy backdoor-t, hátsó bejáratot az oldaladra, amit viszont a következő frissítések nem fognak eltűntetni. Így innentől kezdve az oldalad a támadó kezében van, akárhogy is frissítesz.
Végül két fontos kérdés:
Melyek azok az alapvető konfigurációs lehetőségek, amelyek segítségével a támadások nagy része kizárható?
Első sorban mindig frissítsd mindent. Ez alap. Ezen kívül 3 egyszerű dologgal már elég jó eredményeket érhetsz el: xmlrpc.php törlése, felesleges országok kiszűrése, és a felhasználónevek kinyerésének abszolút tiltása. Figyelem! Az xmlrpc.php-t ha le is törlöd, egy frissítésnél vissza fog kerülni, így ezt „folyamatosan” figyelni kell!
Sokszor kérdezik előadásomon, hogy miért kell tiltani a „felesleges” országokat? Gondolj csak bele. Ha neked magyar nyelvű oldalad van, magyar célpiaccal, akkor mennyire releváns az, hogy orosz, kínai, esetleg szudáni látogatóid legyenek? Van belőlük profitod? Ha nem célpiac, akkor véleményem szerint jobb bezárni a kapukat.
Pár évvel ezelőtt sikerült feltörni az oldalaimat, nem volt nehéz dolguk. Ma már napi szinten nézem a frissítéseket, és azonnal megteszem. iThemes Security-t és Wordfence-t használok, egyelőre az ingyenes verziót. Zúdul is be a sok e-mail jelentés a próbálkozásokról.
Ezzel viszont nem vagyok tisztában: a WP-t nem telepítettem újra, miután felfedeztem a PHP fájlokba beírt kódokat, csak letöröltem a tárhelyről a teljes tartalmat, és felmásoltam az aktuális WP-t. Elegendő ez így, vagy az adatbázisba is lehet telepíteni egy backdoort?
A legtöbb fertőzés, illetve backdoor megszűntethető ezzel a módszerrel. Backdoor telepítése az adatbázisba lehetséges, de a mai napig elenyésző százalékban találkoztam ilyen jellegű támadással. Maximum 2-3% volt eddig az arányuk. Az idei évben azonban úgy látom, hogy elég gyors evolúción mennek keresztül a kártevők, egyre több új mintázat jelenik meg, és mintha az adatbázisba ágyazódók aránya is nőne.
A probléma ott van, hogy ha adatbázisba kerül a tartalom, akkor általában olyan post_type / post_status párral hozza létre a támadó, amit az admin felület nem fog megjeleníteni számodra. Van pár bővítmény, ami pedig imád az adatbázisba szemetelni, így nem triviális eldönteni, hogy mi a kártékony rész, és mi a normális működést támogató adat.
Van ultimate megoldás?
Azt szoktam mondani, hogy a védelem akkor jó, ha több rétege is van… Mint a hagymának… Vagy Shreknek. Több védelmi vonal több támadást fog megfékezni. Gyakran kérdezik ügyfeleim, hogy a már fent lévő védelmi bővítményeiket (pl WordFence, iThemes) kikapcsolják-e miután előfizettek a WebShield-re. A válaszom határozott nem. Hacsak nem okoz valamelyik érezhető lassulást az oldalon, vagy túlzott kényelmetlenséget, akkor jobb ha több védelmi megoldást is felsorakoztat az oldal.
A 100% biztonsági szintet valószínűleg sosem fogja elérni egyetlen szoftver sem, de szépen lehet konvergálni a teljes védettség felé. Minél több dolgot állítasz be helyesen, annál nagyobb biztonságban lesz az oldalad!