Nyilvánvalóan ők nem informatikai szakemberek. Nagyon hálás vagyok a tudásért amit tőlük kaptam, a lehető legnagyobb tisztelettel gondolok rájuk, pusztán arra szeretném felhívni figyelmüket, hogy az ajánlás felelősséggel is jár.
A Drupal, Joomla, Wordpress rendszerek a nyílt forráskódú CMS rendszernek csoportjába tartoznak. A továbbiakban így nevezem őket
Ezzel a cikkel nem kívánok vitát indítani illetve állást foglalni arról, hogy a nyílt forráskódú CMS rendszerek jók vagy rosszak. Nem kívánom minősíteni sem, hanem a saját tapasztalatainkat írom le, illetve az indokaimat, hogy miért nem használunk ilyeneket. A nyílt forráskódú CMS rendszereket is lehet jól vagy rosszul üzemeltetni, vannak előnyeik. Alapesetben azonban nincsenek jól beállítva, optimalizálva. Ezek konfigurálásához is szaktudás szükséges amelynek hiánya nem hozza a kívánt eredményt kereső optimalizálás területén illetve főleg biztonsági kérdésekben.
Fogok írni később egy cikket, hogy ha már egyszer ilyen van akkor mire kell figyelni.
Korábban készültek munkáim Joomla rendszerekben, elég jól megtanultam hogyan kell szabványosan programozni de minden megrendelőmnek elmagyaráztam, hogy azért ebben a rendszerben dolgozom mert rövid idő alatt nem tudok jobbat produkálni, valószínűleg elégséges lesz de lehetnek vele problémák. (lettek is)
Az első pillanatban tudtam, hogy nem lehet ilyen rendszerre pénzt (kártyás fizetés, komolyabb webáruház) és kritikus adatokat rábízni. Az ingatlan irodás honlapot már például nem mertem ilyen rendszer alatt létrehozni.
A legfontosabb szempont amiért nem használunk Drupal, Joomla, Wordpress alapú oldalakat a
Biztonság
Kicsit bizonytalan voltam, hogy ez csak az én fóbiám de néhány napja olvastam egy cikket teljesen más témában ami megerősített:
"By a conservative estimate, more than 70% of today’s WordPress installations are vulnerable to known exploits (and WordPress powers more than 23% of the web). Just a few months ago, 1.2 million Drupal installations got infected with malware in the span of a few days 12 million Drupal sites needed emergency patching, and any not patched within 7 hours of the exploits’ announcement should be considered infected with malware."
itt a forrás, ha valaki szeretné elolvasni teljes terjedelmében
Lényeg: Óvatos becslések szerint a jelenlegi Wordpress oldalak 70%-a ismert módszerekkel feltörhető ami az Intenet 23%-a. Néhány hónapja 1,2 millió Drupal oldalt kellett frissíteni 7 órán belül.
Némi kutatást is végeztem, beírtam a keresőbe, hogyan kellene feltörni ilyen oldalakat és 540 000 találatot kaptam, csak az egyik rendszerre.
Olyan videók vannak, amelyeknek nincs hangja (mert valószínűleg kiszűrné a szolgáltató), csak egy szövegszerkesztőbe gépel valaki és lépésről lépésre elmagyarázza milyen szoftvert, honnan kell letölteni és hogyan kell feltörni.
A nem nyílt forráskódú, kevésbé ismert nevű rendszerek feltörési instrukciójára viszont nem lesz egyetlen találat sem.
"Az Én weblapom nem érdekes, alig ismerik, ki akarná feltörni,..."
Sokan így gondolják, de sajons ez nem így van. Az egyik ügyfelem honlapját magukat "Black Muslim hackers" csoportnak nevező támadók törték fel. Kiderítettem, hogy a támadást a dzsakartai repülőtérről hajtották végre valószínűleg ingyenes Wi-Fi hálózatról. Biztosan nem beszéltek Magyarul, nem célzottan azt a honlapot akarták feltörni.
Kérdeztem szakembereket mit lehet ilyen esetben tenni általában azt mondták semmit. Megkerestem az aktuális tárhely szolgáltatót, hogy tudnak-e segíteni valamilyen információt adni. Lepattintottak, hogy ott van a szerver log, egy végtelenül hosszú szövegfájl, abban van minden.
Nagyjából tű a szénakazalban. Ennek ellenére megtaláltam és találtam egy magyarországi oldalt ami látszólag nem volt feltörve (működött) de alatta elrejtettek egy fájlt ami legalább 100 további magyarországi, weboldal adminisztrátori jelszavát tárolta, közöttük sok közismert kis-középvállalat. Ezzel az információval legalább 100 weboldal felett tudtam volna átvenni az irányítást ha lettek volna ilyen szándékaim.
Nem voltak. Bemutattam a szolgáltatónak, megköszönték az információt és néhány percen belül eltűnt az Internetről az a honlap ahová a jelszavakat rejtették. Ez a tény egy kicsit sokkolt akkor. Még most is.
Következméyek: Ha bárkinek betesznek ilyet a honlapja alá (márpedig simán megcsinálják) akkor akár egyik pillanatról a másikra volt honlap, nincs honlap. Ugranak a keresési eredmények, nagyjából minden. És akkoriban még nem volt ilyen terrorista veszély meg Iszlám Állam. Olyan jellegű tartalomra most még a TEK is kivonulna. De nem kell radikalizmus, elég egy szaftos ágyjelenet kép és megy az egész oldal a pornó spam-be. A tulajdonos nem is fogja tudni, hogy ott van csak azt veszi észre, hogy hirtelen eltűnt a keresőből. Mire a nagy hatalmú Google előtt tisztára mossa magát sok idő el fog telni.
Vannak feltérképező eszközök, mint például a "Blind Elephant". (Nem teszek be linket rá a saját oldalunkon.) Meg tudja mondani egy honlapról, hogy milyen CMS, milyen verzió, al-verzió, al-al verzió 98%-os pontossággal és azt is, milyen kiegészítők vannak telepítve. Érdemes kipróbálni. A verzió információ nagy kincs egy támadónak mert onnan tudja, hogy milyen feltörési módszerre érzékeny.
Ezek az egyéni eszközök de vannak robotok is, amelyek tömegesen törik fel az oldalakat, válogatás nélkül. Onnan azután információkat lopnak. Megszerzik az email címeket, felhasználóneveket és bizonyos esetekben a teljes adatbázist is. Ha pedig a teljes adatbázis megvan akkor abból "otthon", saját gépen, sokkal könnyebb jelszavakat visszafejteni. Persze nem a mi honlapun jelszavai az érdekesek, az már úgyis mindegy de sok felhasználó ugyanazt a név/jelszó kombinációt használja mindenhol. Így már könnyen beléphetnek a levelezőbe, közösségi oldalakra, stb...
Születtek cikkek beállításokra, védelmekre. Itt van például ez is, sokat tanultam belőle.
A cikk tanulsága az, hogy ha az ott leírtakat végrehajtjuk akkor nem a mi oldalunkat törik fel, hanem egy másikat.
Nagyjából annyi, mint amikor a Balkán félszigeten nagy értékű autóval csak és kizárólag egy másik, legalább ugyanolyan értékű autó mellé parkolunk és egy esernyőzárral összekötjük a kormányt a fékpedállal. Örülünk minden alkalommal amikor megvan az autó de valószínűleg nem az esernyőzár miatt maradt ott, inkább csak szerencsénk volt.
Ilyen rendszerekre nem lehet informatikai vállalkozást építeni, nem lehet garanciát nyújtani. Túl sérülékenyek. A megrendelőink a készítő munkáját ítélik meg negatívan egy feltörés után.
Kereső barátság
Elvileg a legnagyobb előnyük a keresőbarát felépítés. Így is van, de itt is nagyon fontos az, hogy mit állítunk be, és hogyan. Alapbeállítás szerint "saját maguk" részére keresőbarátok. Itt egy példa az egyik CMS-ben készült oldalról, melyek a legfontosabb tartalmi kulcsszavak rekonstrukció előtt.
A tartalmi kulcsszavak alapján (is) rangsorolja a Google a weboldalakat. Elég fontos paraméter. Amelyik tartalmi kulcsszónál nagyobb a "jelentőség" értéke ott nagyobb az esély, hogy arra a szóra keresve elölre kerül a találati listában.
A cég (kereskedelmi kisvállalkozás) kiválóan szerepelt a keresőben a "joomla","used","sites", "szavazat" kulcsszavakra de sajnos "joomla"-t , "used"-et , "sites"-ot, "szavazat"-ot nem árulnak.
Egy héttel a honlap rekonstrukciója után a tartalmi kulcsszavak lényegesen átalakultak. A régi, nem releváns tartalom a 21.-23.-helyre csúszott vissza és idővel ezek is el fognak tűnni. A kisatírozott részek mind releváns kulcsszavak amelyek jó, ha megjelennek a találatok között, ilyeneket "árulnak".
Üzemeltetés - frissítés
A nyílt forráskódú CMS-eket frissíteni kell, méghozzá elég gyakran. Van előfizetésem egy biztonsági hírlevélre és legalább hetente jön egy frissítési értesítés. Ilyenkor minél előbb frissíteni kell a rendszert mert sebezhetővé vált.
A CMS-ekben van egy frissítés gomb amivel a rendszer frissíthető ez azonban fájlok felülírásával jár ami hatalmas biztonsági kockázat, a legtöbb szerver nem is engedi meg.
Miért? Alap dolog, hogy a program fájlokat FTP-vel töltjük fel jelszóval, felhasználó névvel egy fájlkezelő alkalmazással a honlapot pedig böngészőből tekintjük meg. A kettőt nem keverjük. Soha. Ha a böngészőből is tudunk program fájlokat feltölteni akkor azt más is megteheti, átveheti az irányítást a honlap felett.
A frissítésnek is vannak szabályai. Normális menete, hogy fejlesztői környezetben (otthoni vagy irodai gépen) frissítünk, kipróbálunk, tesztelünk és utána töltjük rá az éles rendszerre. Bármikor előfordulhat leállás, hiba és akkor megáll az egész oldal. Frissítéskor tesztelni kell a kiegészítőket, hogy működnek-e az új verzióval. Aki egy cseppnyi felelősséget is érez az általa üzemeltetett honlap iránt az így csinálja. Működő szerveren nem. Feltöltés alatt még ilyenkor is megállhat az egész rendszer mert 20 000 fájlt kell felmásolni egyesével, és egy óra is eltelik mire végrehajtódik. Ez alatt az idő alatt szinte biztosan van leállás egy kis időre.
Egy szakszerű frissítés legalább egy óra munka és van benne kockázat, hogy nem sikerül. Tudom, csináltam, sokszor. Tegyük fel, hogy van egy kis cég aki csak 20 honlapot üzemeltet. Hetente jön a frissítő hírlevél. Hetente megy el 20 óra a frissítésekre.
Ez egy ember fél havi munkaideje. Ki fizeti ezt meg? Számlázzunk ki az ügyfelének havonta 4x5 000 Forintot "frissítés" miatt, az ingyenes CMS-re?
Elmaradt frissítések
Vannak olyan verziók amelyek egyszerűen nem frissíthetőek vagy csak nagyon kis részben. Az azonban általános, hogy ha két-három al-verzió kimarad akkor már egyáltalán nem frissíthető vagy nem érdemes, az egész honlapot rekonstruálni kell.
Függőségek
A CMS-ek önmagukban ritkán működnek, sokan rátöltenek kiegészítőket mint például egy képcserélő, Google térkép, stb... Sajnos ezek a kiegészítők is mind verzió függőek, tehát frissítés előtt meg kell várni amíg kijön ezeknek az új verzióval kompatibilis változata és csak akkor lehet frissíteni. Addig pedig ott áll a honlap védtelenül.
Hibás vagy rosszindulatú kiegészítők
Előfordult velem sajnos, hogy egy olyan kiegészítőt telepítettem ami egy idő után támadó weboldallá minősítette a honlapokat ahol működött. A kiegészítőt többen ajánlották, jó minősítése volt a letöltő oldalakon, ingyenes licenc, mi kellhet még? Letöltöttem, telepítettem és sajnos ezzel kár okoztam az ügyfeleink honlapjában.
Itt van olvasnivaló egy "ártatlan" kis képcserélő kiegészítőről.
Sebesség-lomhaság
A nyílt forráskódú rendszerek próbálnak minden beállíthatóságot megoldani úgy, hogy lehetőleg ne kelljen programozni, vagy az admin felületet elhagyni. Próbálnak teljesen általánosak lenni, minden problémára kattinthatós megoldást kínálni. Ezáltal túl nagyra nőttek. Rengeteg a fájl (több tízezer), átláthatatlan a működés, és lomha. Olyannyira túlméretezettek mintha mindenki 7,5t súlyú teherautóval közlekedne az utakon, nem lehetne kisebb járművet kapni.
Ez persze senkit nem érdekel elsőre de egyre fontosabb lesz a Google számára az oldal betöltés ideje és annak felépítése, minősége. A lassabbakat hátrasorolja. Ezt ezekben a rendszerekben optimalizálni -hát nem egyszerű, ha egyáltalán lehetséges. Én mindenesetre nem szívesen vállalkoznék rá.
Most még nem annyira téma, de ha Matt Cutts (Google webspam vezetője) teker egyet a nagy piros gombon a Google-nél (mint ahogy az már többször is megtörtént pl: panda algoritmus vagy 2015-ben a nem mobilbarát weboldalak) akkor hirtelen nagyon fontos lesz.
Ez a cikk erről szól.
Összefoglalva, ha egy sablont választunk kedvenc rendszerünkhöz, járjunk utána milyen gyorsan töltődik be, teszteljük le több helyen és valószínűleg megvásárlás után a tárhely szolgáltatónál lassabban fog működni mert ott sok a honlap a szerveren. (ezt egyébként saját tapasztalataim is alátámasztják)
A saját (w2d) rendszerünkben vannak több tízezer adatos nyilvántartások. Itt egy sorba rendezés, ha semmilyen adat nincs leszűrve nagyságrendileg 0,8-1 másodpercet vesz igénybe. Ezt már észre lehet venni, nem azonnali az eredmény, de még kielégítő. Egyébként a válaszidő 0,2-0,5mp körül van, amit az ember gyorsnak érez.
Saját tapasztalataink szerint a CMS-ek 5-10x lassabbak mint a saját rendszerünk.
5-10 másodperces válaszidő már nem lassú szoftver, az már használhatatlan.
Szakmai presztízs
A nyílt forráskódú CMS-ek (informatikai, programozás) szakmai presztízse nagyon alacsony. Ilyen területen munkát találni nehéz, mindenki lenézi.
A másik oldalról nézve, nehéz jó szakembert találni ezekhez a rendszerekhez mert akiben van akarat a fejlődésre az hamar kinövi és utána már nagyon nem akar oda visszamenni.
Konklúzió
Meg lehet oldani nagyon sok mindent nyílt forráskódú CMS-sel is azonban összességében:
- Sebezhetőek
- Működtetésük lényegesen több élő munkát igényel
- Mindig marad 10% az ötletből, elképzelésből amit nem lehet bennük megvalósítani, kompromisszumokat kell kötni
Zakar Viktor
Ügyvezető - Webtoday Kft.
+36 30 984 1520
webtoday[a]webtoday.hu
