Most, hogy már lassan 2 hónapja elérhető a WordPress 5 gyenge pontja videó, elkezdtem összesíteni a kapott kérdéseket. Ezekből a kérdésekből válogatok most, illetve ahogy mennyiséget elnézem, még lehet hogy pár alkalommal.
Őszintén szólva a tervem az volt, hogy egy bejegyzésben válaszolok ezekre a kérdésekre, de be kell látnom, ez reménytelenül hosszú posztot eredményezne. Így jobbnak látom kisebb csoportokban válaszolni rájuk.
Dávid kérdése:
Ugyebár elengedhetetlen a WP és pluginjeinek frissítése. Na ha most ezt automatizálom, van rá esély, hogy egy idő múlva inkompatibilitás forduljon elő. Szóval ha elkészítek egy weblapot, plugineket használva, van esély rá, hogy a plugin-nak egy olyan része frissül, ami már a weblap egyes részeivel nem kompatibilis. Ezt csak úgy lehet kiküszöbölni, ha „hozzá programozom” a pluginhez az adott részt, ugye? Minél több ilyen plugin van, annál több esélye van az inkompatibilitásra, annál több munka van később. Aztán lehet hogy később hozzá igazítom a kódot, de utána megint frissül, és megint később megint hozzá kell igazítani. Ez egy ördögi kör talán?
Nos, amit először le kell szögeznünk, hogy ha valaki belenyúl a WordPress, vagy egy bővítmény, esetleg sablon kódjába, akkor a legrosszabb megoldást választotta. Fő szabályként elmondható, hogy a WordPress Core részében TILOS módosítani! Ha sablont akarsz módosítani, akkor gyermeksablont kell készíteni (child theme). Ezzel a megoldással a „fő” sablonod frissíthetősége is megmarad, tehát ha valamilyen biztonsági frissítés kijön hozzá, akkor fel tudud frissíteni (általában) gond nélkül.
Ha bővítményhez kell hozzányúlni, akkor mindenképpen meg kell változtatnod a header részét is (ahol a bővítmény neve / gyártója / verziószáma van), hogy elkerüld azt, hogy a frissítések felülírják a változásokat. Viszont ettől még egy támadó úgynevezett fingerprinting technikával kiderítheti, hogy milyen ismert bővítményre (és annak melyik verziójára) hasonlít legjobban az általad módosított plugin, és annak az időközben kiderült hibáit kihasználva el lehet kezdeni támadni az oldalt.
Ebben az esetben tehát figyelned kell az eredeti bővítmény frissítéseit, és az abban lévő változtatásokat át kell vezetned a saját verziódba. Egyáltalán nem triviális feladat.
Legjobban akkor jársz, ha WP Core-hoz, bővítményhez nem nyúlsz. Ha nem tudja azt, amire szükséged van, keress másikat. Ha nem találsz másikat, írj egyet. (fogsz találni…)
A bővítményeket a közösség rendszeresen teszteli. Ha megnézed egy-egy bővítmény oldalát a https://hu.wordpress.org/plugins/ oldalon, láthatod hogy a bővítmény mely verziója melyik WP verzióval kompatibilis.
Tudnod kell továbbá, hogy nem elég a bővítményeket / sablonokat frissíteni, de ugyanígy oda kell figyelni az WordPress frissítésére is. Amikor nincs nagyverzió váltás, akkor biztos nem lesz gond a kompatibilitással. Ha pedig van, és esetleg probléma lenne, akkor a bővítmény fejlesztői is kiadnak egy frissítést. Így együtt frissítve a bővítményeket és WordPress-t, túl nagy problémád nem lehet. (főleg, ha van mentésed 🙂 )
T.B kérdezte:
Nincs legnagyobb kérdésem, mert én csak a saját szerveremen tartok honlapot és ott több lehetőségem van a védekezésre.
A wp-nek és a szervernek együtt van lehetősége, külön-külön sokkal sérülékenyebbek. Tulajdonképpen az egész http protokoll megérett a korszerűsítésre. Tulajdonképpen a folyamatos ellenőrzést a www területen kívülről lehet megoldani valójában szerver szinten működő ellenőrzés nem rossz. Tulajdonképpen a veszéjes js kódokról még szó sem esett..
Múltkor már említettem, hogy ha egy feltörés esetén a tárhelyszolgáltatót hibáztatod, akkor több mint valószínű, hogy rossz úton jársz. Persze ha saját szervert üzemeltetsz, akkor szabad a vásár, olyan védelmet állítasz be, amilyet szeretnél.
A szerver nem lesz sérülékenyebb a WP nélkül (főleg ha nincsenek az egyes domainek jól elszeparálva egymástól), és a WP sem lesz sérülékenyebb a szerver nélkül.
Szerver oldalon ugyanis bár be tudsz állítani egy csomó mindent (pl.: hogy az uploads vagy tmp könyvátrból ne futhasson PHP), ezzel még csak a támadások egy kis részét zártad ki. Tűzfallal sokat nem érsz, mert a 80-as vagy 443-as portot (http és https) be kell engedned ha azt akarod, hogy üzemeljen az oldalad. A WP-t érő támadások pedig pont ezeken keresztül érkeznek.
A veszéjes JS (JavaScript) kód is ugyan úgy kerül a szerveredre, mint egy-egy fertőzött WP fájl. A támadó valamilyen hibát, vagy gyenge jelszót kihasználva módosítani tudja a fájlokat. Itt mindegy hogy .php, .png, vagy .js az, amit módosít. Sokan azt gondolják, hogy ha írásvédetté teszik a teljes WP struktúrát, akkor nem lehet megtámadni azt. Ez csak tüneti kezelés sajnos. Egyre több olyan támadással találkozok, ahol az adatbázisba kerülnek be a kártékony kódok. Ezekben az esetekben az írásvédettség nem jó megoldás. Továbbá ha egy biztonsági résen keresztül (pl: SQL injection) le tudom kérdezni a felhasználóid adatait, esetleg rendeléseket, akkor egyáltalán nincs szükségem a fájlok módosítására.
Amit szerver szinten megtehetsz, hogy fokozd a biztonságot:
Állíts be megfelelő jogosultságokat. Ahogy említettem leginkább a php futtatást kéne letiltani a wp-content/uploads könyvtár alól, és az éppen használt tmp alól. Írásvédettséget nem tennék rá, mert szerintem lábon lövöd magad vele. Megakadályozod azt, hogy hogy egyszerűen frissíthesd a WP-t. Helyette – ha már úgyis Te üzemelteted a szervert, érdemes valamilyen checksum-ot előállító ellenőrzést tenned a WP-re, és figyelni hogy nem változik-e akkor, amikor nem kéne. Továbbá minél több dolgot kell naplózni, hogy ha esetleg mégis becsúszik egy támadás, akkor a támadás időpontjából kiindulva vissza lehessen fejteni hogy mi is történt valójában.
Mai utolsó kérdésünk:
Kérdés: Olyan biztonság mentés készítése az adatbázisról és minden egyéb tartalomról, amelyből – szükség esetén – könnyen vissza tudom állítani az oldalt, illetve át tudom „költöztetni” az oldalt egy másik doménre.ű
Megmondom őszintén, hogy én low-level dolgokhoz nyúlok ilyenkor, abban mozgok otthonosan. Csinálok egy adatbázis mentést, komplett mentést a tartalomról, és ezeket mozgatom / állítom vissza. Ezt egyrészt nem minden szolgáltató engedi meg, másrészt pedig nem várható el az oldal tulajdonosától, hogy képes legyen erre. Egy-két ügyfelemnél találkoztam a duplicator bővítménnyel, úgy látom ez pont az, amire szükséged van!
Innen elérhető, és még egy kis how-to videó is van hozzá: https://hu.wordpress.org/plugins/duplicator/
De vigyázz! Ha a tárhelyen nincs jól beállítva valami, és engedi a könyvtárak listázását annak ellenére, hogy ez egy .htaccess fájlban tiltva van, akkor könnyen megtalálható lesz az így elkészített csomag, amit tipikusan a wp_snapshot könyvtárba tesz a bővítmény.
Ha valaki ehhez hozzáfér, akkor gyakorlatilag az összes adatod a kezében van! (és hozzáférhet egy biztonsági résen keresztül is!) Tehát amint lementetted ezeket a csomagokat, azonnal töröld őket! Az új helyen amint feltelepítetted, töröld!