Biztonságos a Divis oldalad?

Szerző: | 2018. 10. 24. | DIVI Basic

Helló!

A Divis oldalad biztonságáról raktunk össze egy “rövid” összefoglalót. Mielőtt azt gondolnád, hogy ennyire okos vagyok, el kell szomorítsalak, ez hosszas gyűjtögető munka eredménye és nem a szárnyaló fantázia szülötte. Régebb óta szedegetem ezeket a morzsákat, de most eljött az ideje, hogy egyben is átlátható legyen.

Figyelem: alapvető technikákat, ajánlásokat szedtem össze, nem lehet (minthogy a biztonság sosem 100%-os) mindenre felkészülni, de a leggyakoribb biztonsági veszéllyel tisztában kell lenni és be kell foltozni az eseleges hasadásokat. Az elővigyázatosságnak a józan ész szabályai mellett figyelemmel kell lenni azokra a támadási formákra, amelyeket ismerünk már. Egyszerű ajánlások, pár soros kódok lesznek, amik a tárhelyünk .htaccess (Apache szerver) fájljába és/vagy a gyereksablonunk functions.php fájljába lehet beilleszteni.

Egyetlen alkalommal tapasztaltam meg, hogy milyen hülye érzés, amikor arra ébredsz, hogy az általad készített weboldalon nem az a tartalom van, amit te tettél fel, hanem valami teljesen más. Ennél az esetnél az derült ki, hogy a tárhelyet (egy osztott tárhelyen volt az oldal) egy másik tárhely sebezhetőségén keresztül törték fel és a szolgáltató nem kellő figyelmességgel választotta el a tárhelyeket és gyakorlatilag a teljes szerver felett átvették a hatalmat. Az oldal egy kis forgalmú “bemutatkozó” weboldal volt és sikerült 1 óra alatt helyreállítani mindent. Az érzés viszont azóta is kísért, hogy valaki valamiért be fog törni.

A következő listában a legelemibb biztonsági megoldások szerepelnek, egyszerűek, de hatásosak. A legtöbbje megoldható valamilyen bővítménnyel vagy egy-egy komplexebb biztonsági pluginnal is. Ezekről tervezek egy részletes összehasonlító tesztet is.

Készen állsz? Akkor induljon útjára a gyönyör…

Sohase gondold azt, hogy a Te oldaladat nem éri meg feltörni!

A WordPress oldalad elleni támadást ne tekintsd személyes ügynek, a rosszfiúk szisztematikusan keresik a lehetőséget arra, hogy az automatizált robotjaik segítségével gyengeségeket fedezzenek fel weboldalakon. Hogy miért? Na ez egy jó kérdés.  A támadások motivációja nagyon eltérő lehet: például lehetséges, hogy a tárhelyed erőforrásait szeretnék megszerezni, hogy aztán ott bitcoint/más kryptovalutát bányásszanak, vagy megmutassák a világnak, hogy mennyire ügyesek, vagy kihasználják a tárhely szervered erőforrásait, vagy megszerezzenek személyes adatokat, bankadatokat. Nem lehet tudni.

Úgyhogy felejtsd el azt, hogy csak egy egyszerű oldalad van és ki lenne az az őrült, aki fel akarná törni. Minden weboldal egy potenciális erőforrás, amit más is akarhat használni  a te pénzedért. 

Ezekről lesz szó:

1. Fejezd be a WordPress telepítését megfelelően
2. Válassz nagyon biztonságos jelszót magadnak
3. Válassz egy biztonságos bejelentkezési nevet
4. Tartsd  a rendszeredet naprakész állapotban
5. Rendszeresen mentsd a weboldaladat
6. Csak tiszta forrásból legyen pluginod vagy sablonod
7. Ne felejtsd el a biztonsági kulcsokat és a sót kitölteni
8. Ne engedd, hogy az oldalad szerzőinek ID-ját ki lehessen deríteni
9. Védjük meg az érzékeny fájlokat és mappákat a hozzáféréstől
10. Távolítsuk el a bejelentkezési hiba üzeneteket
11. Tiltsuk le az XML-RPC-t
12. Rejtsd el a verziószámokat
És az összes kód egyben

1. Fejezd be a WordPress telepítését megfelelően

Ez egy kicsit furán hangzik, de gondolj csak bele, hogy amennyiben felmásolod a WordPress fájlokat a tárhelyedre és még nem kezdted el a telepítést (csak ott marad, vagy éppen félbe hagytad), akkor egy nagyon sebezhető állapotban van a tárhelyed, mert  /wp-admin/setup-config.php fájlod szabadon elérhető.

Manapság robotok hadserege szkenneli a világhálót, hogy “befejezzék” helyetted a telepítést és egy back doort telepítsenek az oldaladba.

Ha azon gondolkodnál, hogy hogyan a fenében tudják a hackerek megtalálni a még nem telepített WordPress oldaladat, akkor olvasd el ezt a cikket.

2. Válassz nagyon biztonságos jelszót magadnak

Válassz komplikált jelszót a hackerek felé, de egyszerűen megjegyezhetőt magadnak:

  • A régi közmondás szerint ne rakd az összes tojást egy kosárba, mert mind eltörhet egyszerre. Pont így kezeld a jelszavaidat is. Ne használd ugyanazt a jelszót több oldalon.
  • Minél hosszabb egy jelszó annál több időt emészt fel a kitalálása. Manapság a számítási kapacitások növekedése mellett is egy körülbelül 15-20 karakterből álló jelszó gépi megfejtése már olyan hosszú idő is lehet, hogy kellő védelmet nyújthat.
  • Ha a jelszóban kis és nagybetűs karaktereket is használsz vegyesen, akkor jelentősen megnöveled a kitalálási idejét.
  • Kerüld el a szótárban is fellelhető szavak használatát, ezt tök gyorsan meg fogja fejteni egy robot. Elég neki azt a pár tízezer szót lepróbálni, amit elektronikusan szótárként beletölthetnek.
  • Egy teljes mondatot sokkal könnyebb megjegyezni, de nagyságrenddel nehezebb kitalálni. Ha ezt megvariálod még számokkal és jelekkel, akkor egy trezorban érezheted magad. (ebből a szempontból)

De a legjobb, ha kipróbálod a jelszavad erősségét például itt: https://howsecureismypassword.net/ 

3. Válassz egy biztonságos bejelentkezési nevet

Igen, nyertél az “admin” lesz az első, amit egy robot megpróbál az oldalad adminisztrációs felületén, hogy vajon “Kismalac, kismalac engedj be” működik-e. Hasonlóan az adminhoz a “root” vagy az oldal neve is az első próbálkozások között lesz.

A fentiekkel nagyvonalúan megkönnyítheted a szegény hackerek és robotjaik fáradságos munkáját :-). Úgyhogy, ha kívül szeretnéd tartani őket, ezeket a felhasználó neveket most felejtsd el. Találj ki valami általad használható, de nehezen megtippelhető felhasználói azonosítót. Én sem a Fecsót használom :-).

4. Tartsd  a rendszeredet naprakész állapotban

Sajnos a WordPress magjának és kiegészítő részeinek frissen tartása még nem feltétlen reflexe mindannyiunknak. Magamon már lassan kezdem észrevenni, hogy, ha bejelentkezem egy WordPress admin felületre, akkor azonnal megnézem a frissítési lehetőségeket.  A teljes mentést követően pedig rá is nyomulok a frissítésre azonnal. A biztonsági rések legnagyobb része az elavult komponoensekből ered.

Akinek az életében történt már olyan is, hogy a frissítés miatt letérdepelt a weboldala egy-egy nagyobb verziószám váltásnál, vagy rosszul összerakott bővítmény frissítésnél, annak számára nem kérdés, hogy egy mentés nem mentés, két mentés félmentés, stb.

Én magam az a típus vagyok, aki ilyenkor 1-2 napot várni szoktam a frissítésekkel, hogy a fórumokon, Facabook fanpage-eken elolvassam az esetleges hibabejelentéseket. Érdemes úgynevezett staging oldalakat készíteni. Ezeken gyakorlatilag teljesen le lehet próbálni a frissítést és, ha zökkenőmentesen megy minden, akkor az éles oldalra is vissza lehet tenni.

Általában igyekszem csak a legrövidebb időt hagyni a NEM friss témáknak, bővítményeknek, és a magnak. Még egy fontos dolgot viszont fontos megjegyezni: MINDEN BŐVÍTMÉNYT, TÉMÁT frissíts le, még akkor is, ha éppen nem aktívak.

Figyu: Túl a biztonsági szempontokon, azt is figyelmbe kell venni, hogy sok időt tudsz megspórolni azzal, ha rendszeresen frissítesz, mint ha egyszerre egy nagyobb csomagban végzed el. Másrészről, ha nagyobbak a rések a karbantartásban, akkor nem lehetsz abban biztos, hogy mi okozhat egy esetleges összeomlást. Persze lehetsz szerencsés és minden 100%-osan működik. Statisztikailag viszont előbb-utóbb bekövetkezik egy-egy hiba is. És ha éppen 21 frissítés volt akkor nehezebben fogod a bűnöst megtalálni…

5. Rendszeresen mentsd a weboldaladat

Egy dologban lehetünk csak bizonyosak, mégpedig abban, hogy nem létezik 100%-os biztonság. (Aki ezt garantálja, az vagy hazudik, vagy totálisan amatőr)

Ahhoz, hogy az oldalad tartalmát, értékeidet meg tudd tartani, rendszeresen készíts mentéseket. Biztonságban nem ismerünk elégségest, ezért a mentést több helyre érdemes végezni. Az én gyakorlatomban ez úgy néz ki, hogy a rendszer automatikusan készít egy mentést a saját szerverére.

Na de mi van, ha egy gonosz behatoló törölné azt is?

Van másik, mert a rendszer a mentést elküldi automatikusan a DropBox fiókomba, ahonnan a NAS-om azonnal magába szippantja és még egy példányban megőrizi ott is.

Természetesen olyan tárhely szolgáltatóm van, ahol naponta van tárhely mentés.

Valahonnan mindenképpen vissza fogom tudni állítani az oldalamat.

6. Csak tiszta forrásból legyen pluginod vagy sablonod

Mindig sokkal egyszerűbb leellenőrizni a telepíteni szándékozott szoftvert a számítógépeden, mint a webszervereden, tárhelyeden.

A bővítmények és sablonok piacterein általában nagyon nagy biztonsággal megbízható szoftvert kapsz. Na pont ez nem biztos az ingyenesen letölthető, varez, és egyéb fekete oldalakon.

AZ INGYENESSÉG ÁRÁT MEG FOGOD FIZETNI VALAHOL. 

Lehet, hogy csak annyival, hogy nem kapsz segítséget, ha valamiben szükséged lenne rá. De nagyobb valószínűséggel egy virust vagy egy malwaret is telepíthetnek az oldaladra. Ezeknek a kigyomlálása pedig sok idő és pénz is lehet. Arról nem is beszélve, hogy milyen veszteséget szenvedhet el a márkád megbízhatósága.

Tegyük hozzá azt is, hogy még akkor is, ha teljesen tiszta forrásból származik minden egységed, akkor is összeakadhat valamivel az oldaldon egy-egy frissítésnél. Csak abba gondolj bele, hogy a hivatalos plugin gyűjteményben mennyi bővítmény van, mennyi ingyenes sablon, hány féle php verzió fut még mindig (néha a halála után is) és hányféle adatbázis kezelő és verziója. Ha ennek a variációját kiszámolod, akkor rájössz, hogy nincsen olyan bővítmény, amit mindennel leteszteltek és mindennel 100%-osan kompatibilis (lehet, de nem bizos).

Elég csak arra gondolni, mikor a Woocommerce-et frissítettük 3.0-ás verzióra, vagy a Yoast SEO is okozott tömeges összeomlásokat.

7. Ne felejtsd el a biztonsági kulcsokat és a sót kitölteni

Mi a fene ez a só?

A titkos kulcsokat a weboldalad config.php fájljában találod meg (a fájlt pedig a weboldalad gyökérkönyvtárában) és ezek olyan “hash” kulcsok, amiket a WordPress használ arra, hogy a jelszavakat tikosítsa (amiket aztán az adatbázisban tárol le) és más információkat is ezekkel a kulcsokkal titkosít, például a sütiket vagy a felhasználói azonosítókat és jelszavakat.

Ez egy példa a WordPress sóra. Érdemes észrevenni, hogy hosszú, véletlenszerű karaktersorozat. Ha nem férnek hozzá direktben a telepítési mappádban, akkor elég nehéz lesz visszafejteni :-).


				

Ezeket a kulcsokat töltsd fel te magad a telepítéskor a config.php fájlba, legrosszabb esetben a WordPress automatikusan generál valamit és azt fogja eltenni az adatbázisodba ugyanoda, ahol a jelszavakat tárolja.

Ha szükséged lenne egy gyors eszközre a só előállításához, akkor használd ezt a sógenerátort a WordPresshez.

Ezt az eszközt használhatod akkor is, ha kicserélnéd a sót az oldaladon, ezzel a korábbi sütiket is érvényteleníted persze. De az is lehet, hogy csak elővigyázatosságból teszed meg ahhoz hasonlóan, ahogyan rendszeresen cseréled a jelszavaidat. Ugye cseréled?

És persze akkor is cseréld ki ezt, ha a legcsekélyebb gyanúd merül fel arra, hogy behatoltak az oldaladra vagy esetleg megszerezték a jelszavadat!

Figyu: Itt találsz további infókat a WordPress sóval kapcsolatosan:  Miért fontosak a WordPress só kulcsok.

8. Ne engedd, hogy az oldalad szerzőinek ID-ját ki lehessen deríteni

8.1. Rejtsd el a szerzők profil oldalát

Próbáld ki a saját oldaladon (vagy a konkuresedén), hogy a domain név után ezt írod be ezt: “?Author = 1” a böngésződben. Jó eséllyel (persze WordPress esetében) átirányít egy olyan oldalra, melynek az URL-je a domain neve után így néz ki: /author/<user>/, ahol a <user> megjeleníti az oldalt létrehozó adminisztrátor bejelentkezési nevét.

Viszont, ha ez működik az 1-gyel, akkor működik más számokkal is. Egy pici programozással akár le is szedegetheti egy hacker az összes felhasználói nevet az oldalaról. Mi több ezek a bejelentkezéshez használt nevek, tehát elég egy gyenge jelszavú felhasználót találni közülük és Szezám tárulj lehet…

Éppen ezért ezt az információt nem biztos, hogy ki szeretnénk adni. Ehhez nem kell mást tenni, csak ezt a lekérdezést ignoráljuk a lentebbi pár soros kóddal, amit a tárhelyeden a .htaccess fájlba kell beillesztened:

# Lécci rejtsük el az oldalunk szerzőit
<IfModule mod_rewrite.c>
 RewriteCond %{QUERY_STRING} ^author=([0-9]*)
 RewriteRule .* - [F]
</IfModule>

8.2. Távolítsuk el a szerzők bejelentkezési nevét a hozzászólásokból

Amikor egy regisztrált felhasználó válaszol egy WordPresses hozzászólásra, akkor a bejelentkezési neve megjelenik a hozzászólás HTML kódjában.

Na ezt sem szeretnénk…

Úgyhogy ismét csak takarítsunk egy kicsit. Ezt a kódot viszont már a gyerektémánk  functions.php fájljába kell betenünk:


9. Védjük meg az érzékeny fájlokat és mappákat a hozzáféréstől

Vannak olyan fájlok és mappák a WordPress oldalunk gyökerében, amit nem szeretnénk, ha elérnének. Nagyon fontosak, nagyon bizalmasak, elérésük esetén minden kaput kinyitnak,

Adjuk hozzá a .htaccess fájlunkhoz a következőket:

# Védd meg a mappák tartalmát
Options -Indexes

# Védd meg a wp-config.php-t
<files wp-config.php>
 Order allow,deny
 Deny from all
</files>

# Védd meg a .htaccess-t és a .htpasswds-t
<Files ~ "^.*\.([Hh][Tt][AaPp])">
 Order allow,deny
 Deny from all
</Files>

10. Távolítsuk el a bejelentkezési hiba üzeneteket

Mi ez?

Ha egy WordPress bejelentkezési oldalon elkövetsz egy hibát, akkor egy hibaüzenetben informálja a rendszer a felhasználót, hogy a felhasználó nem létezik, vagy a megadott jelszó nem megfelelő a felhasználóhoz.

Ez egy kényelmes dolog nekünk és persze kényelmes a hackereknek is. Csak annyit kell tenniük, hogy találnak egy felhasználónevet és második lépésben megpróbálják megtalálni a hozzátartozó jelszót.

Hogy ennek elejét vegyük ennek használjuk ki a functions.php fájlunkat a gyerektémában:


				

11. Tiltsuk le az XML-RPC-t

Az XML-RPC egy olyan protokol, amit arra használ a WordPress, távolról be lehessen jelentkezni például (másokra is még, de itt a probléma). Na ennek a kapunak van egy funkciója az ún. system.multicall() metódus, ami lehetővé teszi nagyszámú bejelentkezési kísérlet végrehajtását egy egyszerű hívással. Mintha egyszerre ezer kulccsal lehetne egy ajtó kinyitását megpróbálni…

Le is tilthatod kompletten a  .htaccess fájlban:

# Védd meg az xmlrpc.php-t
<Files xmlrpc.php>
 Order allow,deny
 Deny from all
</Files>

Másik lehetőséged – ha nem használod – ezzel a pár soros kóddal a functions.php fájlodban:


				

12. Rejtsd el a verziószámokat

Miért könnyítenénk meg hackerek dolgát, azzal, hogy eláruljuk nekik,  hogy milyen rendszert kell feltörniük?

FIGYU: Gyakorlott hackerek és fejlett webes szkriptek mindenképpen meg tudják szerezni azt, hogy milyen verziójú a WordPress (vagy a használt bővítmények az oldaladon), de miért ne nehezítsük meg az egyszerűbbek dolgát. Ráadásul tök egyszerűen útját állhatjuk egy csomó kísérletnek, úgyhogy távolítsuk el vagy rejtsük el ezeket az egyébként számunkra is haszontalan infókat.

12.1. Az oldalaink fejlécéből és az RSS feedből

A WordPress beilleszt a saját fejlécébe a (<head> tag) néhány elemet, ami gyakorlatilag haszontalan a normál működésünkhöz, de feltöréshez információkat adhat az oldalon lévő CSS/JS fájlok verziószámairól.

Ezeknek a verziószámoknak az eltávolítására a fejlécekből (és az RSSből is) illesszd be a következő kódot a gyerektémád  functions.php fájljába:

12.2. Olvassel, liszensz, changelog fájlok …

Ezeket a fájlokat a weboldalad gyökerében találod meg, illetve a sablonok és bővítmények mappáinban. Ezek segítenek beazonosítani a kinyitandó páncélszekrényt…

Sajnos hiába töröljük le manuálisan a szerverről, mert minden frissítés alkalmával visszateszi a WordPress vagy az adott bővítmény.

Törölni felesleges, akkor védjük meg a .htaccess segítségével:

# Védjük meg az infó fájlokat
<FilesMatch "^(readme.html|readme.txt|README.txt|README.md|changelog.txt|license.txt|LICENCE.txt|LICENCE)">
 Order allow,deny
 Deny from all
</FilesMatch>

12.3. A webszerver verziójának információi

Néhány hibaoldalon előszedhető a weboldalunkat üzemeltető szerver verzió informciója a használt modulokkal és a szoftverek adataival.

Ezeket nem szeretnénk megadni egy olyannak, akinek semmi dolga (vagy legalábbis hasznos dolga) nincsen a weboldalunkkal. Ezzel a kóddal tudjuk a .htaccess fájlbann letiltani ezt az infót:

# Rejtsük el a szerver információkat
ServerSignature Off

És az összes kód egyben:

ez megy bele a function.php-ba


				

ez pedig a .htaccess fájlba

#########################################
#  Divi Sablon Klub WORDPRESS SECURITY  #
#########################################

# Kövesd a symbolic linkeket
Options +FollowSymLinks

#Védd meg a mappák tartalmát
Options -Indexes

# Rejtsd el a szerver információkat 
ServerSignature Off 

#Védd meg a wp-config.php-t
<files wp-config.php>
 Order allow,deny 
 Deny from all 
</files>

#Védd meg a .htaccess-t és a .htpasswds-t
<Files ~ "^.*\.([Hh][Tt][AaPp])">
Order allow,deny
Deny from all
</Files> 

#Lécci rejtsük el az oldalunk szerzőit
<IfModule mod_rewrite.c>
 RewriteCond %{QUERY_STRING} ^author=([0-9]*) 
 RewriteRule .* - [F] 
</IfModule>

# Védd meg az xmlrpc.php-t
<Files xmlrpc.php>
 Order allow,deny
 Deny from all 
</Files>

# Védjük meg az infó fájlokat 
<FilesMatch "^(readme.html|readme.txt|README.txt|README.md|changelog.txt|license.txt|LICENCE.txt|LICENCE)">
 Order allow,deny
 Deny from all 
</FilesMatch>

És egy mítosz is a porba hull

Nagyon sok helyen olvastam, hogy az adatbázisunk biztonságának egy Grálja az, ha az adatbázis táblák előtagját megváltoztatjuk. Na ez például nemhogy nem Grál, de maximum egy Viagra Light…

Jól mutat a strandon, de semmi másra nem alkalmas.

Érdemes elolvasni egy cikket ennek ellenkezőjéről itt. Egy egyszerű SQL lekérdezéssel meg lehet találni az adatbázis tábla előtagját és onnatól már a nagykapu is nyitva áll.

Persze azt is látni kell, hogy nagyon sok biztonsági bővítmény ajánlja fel az adatbázis előtag cserét, valószínűleg azért, hogy marketing szmpontból jobban szerepeljen, az ez még azt is tudja veresenyen a plugin.

Figyu: Ha egy adatbázisban fogsz több weboldalt használni, akkor a táblaelőtagokkal megkülönböztetheted az egyes oldalakat, de érdemesebb önálló adatbázisban tartani az egyes oldalakhoz tartozó adatbázistáblákat.

Összegzés

Remélem kiderült ebből a “rövid” cikkből is, hogy mennyire fontos a WordPresses Divis oldalak biztonsága és az is, hogy nagyon sok felől érkezhet támadás. Természetesen ez nem a teljes lista, csak a leggyorsabban, legegyszerűbben bevezethető ajánlások gyűjteménye.

Ennek ellenére nagyon sok felesleges rizikótól szabadulhatsz meg, ha figyelsz a biztonság betartására.

Biztonságos Divizést kívánok:

Fecsó