Webszerverek és weboldalak üzemeltetése: a legjobb gyakorlatok
Számos weboldalt üzemeltető cég van a piacon. Esetenként a hostingszolgáltató ad egy könnyen kezelhető webes felületet is, amelyen minimális szakmai tudással is el lehet igazodni.
Az ezeken a felületeken egyszer jól beállított weboldal kis látogatottság esetén hosszú ideig üzemelhet.
Azonban a weboldalt üzemeltető szerver időnként karbantartást is igényel, ugyanúgy, ahogy a weboldal forráskódja (motorja) is, vagy éppen a tartalma.
Ha fontos a maximális rendelkezésre állás, és szeretnénk biztonságban tudni a weboldalunkat, akkor a szerverkörnyezetnek a kialakításába is több energiát kell fektetnünk, és a karbantartása is rendkívül ajánlott.
Milyen technológiákat válasszunk mindehhez? Mire ügyeljünk? Mik az általános szükségletei egy weboldalnak, és milyen buktatói lehetnek a hostingnak hosszútávon?
Biztonsági mentések
A biztonsági mentés lényegében pillanatkép a weboldalunk teljes állapotáról egy adott időpontban.
Ha valamilyen probléma vagy egyéb ok miatt – például véletlenül töröltünk egy tartalmat vagy elvégeztünk egy téves beállítást – vissza szeretnénk állítani a weboldalunkat egy korábbi állapotba, akkor valószínűleg a biztonsági mentésből való visszatöltés, azaz a biztonsági mentés visszaállítása lesz a megoldás.
A hostingszolgáltatóknál a biztonsági mentés gyakran benne van a csomagban.
A biztonsági mentések visszaállítása viszont általában szakembert igénylő feladat (ritkábban fordul elő, hogy a webes felületen ez is néhány kattintással kivitelezhető), így fontos, hogy legyen „kéznél” megfelelő segítség a szolgáltatónál, aki a visszaállítást is elvégzi.
Jó tudni, hogy bár a biztonsági mentés általában része a hostingszolgáltatásnak, ezeknek a visszaállítása már gyakran extra költséggel jár.
Az sem mindegy, hogy a biztonsági mentés mennyi időre visszamenőleg van tárolva. Egy gyakran látogatott és felügyelt weboldalnál elegendő a napi 1, nagyjából 1 hétre visszamenőleg.
Mindenképp érdemes legalább egyszer tesztelni ezt a funkciót, mielőtt elköteleződünk egy hostingszolgáltató mellett.
SSL tanúsítvány
Az SSL tanúsítvány megléte ma már alapkövetelmény egy weboldallal szemben.
Ha a weboldalnak van SSL tanúsítványa, akkor a böngészőben a webcím bal oldalán egy lakat ikont látunk, illetve ha kimásoljuk az URL-t a böngésző címsávjából, és beillesztjük egy szövegfájlba, akkor azt látjuk, hogy http helyett https-sel kezdődik (az „s” ebben az esetben „secure”-t jelent).
Változó, hogy egy hostingszolgáltató mennyire teszi kényelmessé az ügyfélnek az SSL tanúsítvány igénylését és konfigurálását.
Lehet, hogy elegendő egy kattintás, de az is lehet, hogy rendszergazdai beavatkozást igényel.
Mire kell az SSL tanúsítvány valójában?
- Megléte esetén a böngésző és a szerver között az adatforgalom titkosított csatornán zajlik, amit egy támadónak meglehetősen költséges lenne lehallgatnia. Nem véletlen, hogy a https 2014 óta Google-rangsorolási tényező!
- Bizalmat kelt a felhasználóban, még akkor is, ha a weboldal csak információt jelenít meg, nincs rajta semmilyen bejelentkezési funkció. Ugyanis ha a weboldalnak nincs SSL tanúsítványa, akkor a böngésző címsávjában a lakat helyén a „Not secure”, azaz a „nem biztonságos” felirat jelenik meg:
Milyen SSL tanúsítványt válasszunk?
Létezik ingyenes, olcsó és drága tanúsítványkiadó, és az emberben joggal merülhet fel a kérdés: a drágább jobb? A válasz: nem feltétlenül.
Minden a szerver konfigurációján múlik. A tanúsítvány ugyanis lehet nagyon drága, ha a szerveroldali biztonsági beállítások nem megfelelőek.
A beállítások ellenőrzésére az Ssllabs.com weboldalon elérhető online SSL szervertesztelő például meglehetősen közérthető. Ez egy összesített értékelésben osztályzatot ad az SSL tanúsítvány minőségére.
A Web.prompt.hu például A+ biztonsági minősítést kap, amit az ingyenes Let’s Encrypt tanúsítványkiadóval ér el:
Uptime
Az uptime az az idő, amíg a weboldal elérhető. Ez minél magasabb, annál jobb.
A downtime-ból pedig, vagyis amikor a weboldal nem elérhető, minél kevesebb, annál jobb.
Akár a weboldal, akár az azt üzemeltető szerver esetén időnként van némi downtime, például karbantartáskor.
A legjobb, ha a downtime-ot akkorra időzítik, amikor a weboldal látogatottsága minimális. Az is fontos, hogy a downtime-ok maximum néhány másodpercig tartsanak.
Az uptime-ot manuálisan természetesen csak úgy tudjuk ellenőrizni, hogy időnként ellátogatunk a weboldalunkra, és megnézzük, működik-e.
Viszont ennél hatékonyabbak az online monitorozók, mint például az ingyenesen elérhető UptimeRobot, ami akár percenként teszteli a weboldal elérhetőségét, és e-mailes értesítést vagy akár push notificationt küld a telefonunkra, ha a weboldalunk nem elérhető.
Ez a funkció jó esetben be van állítva a weboldalt üzemeltető cégnél is, és downtime esetén azonnal megteszik a szükséges intézkedéseket.
Kevésbé szerencsés esetben maga a tulajdonos is beállíthatja ezt a telefonján, és ha értesítést kap, jelezheti a hostingszolgáltatónak a downtime-ot.
Űrlapok, bejelentkezési felületek védelme
Egy egyszerű weboldalon is elég gyakran találkozunk kapcsolatfelvételi űrlappal, amelyet ha egy látogató kitölt, arról a weboldal tulajdonosa e-mailes értesítést kap, és reagálhat rá.
Ezeket az űrlapokat megfelelő technológiával kell védeni, úgynevezett CAPTCHA védelemmel kell ellátni, hogy automatizált scriptek, spamelő robotok ne tölthessék ki őket, és ne tudják elárasztani a weboldal tulajdonosát a kéretlen levelek.
Ez a weboldal fejlesztőjének a feladata, de vannak olyan szerveroldali szolgáltatások is, amelyek ilyen űrlapok vagy akár bejelentkezési felületek védelmére szolgálnak.
Az ismertebb tartalomkezelő – például WordPress vagy Drupal – alapú weboldalaknak mindig van egy bejelentkezőfelületük, ahol felhasználónév és jelszó megadásával léphetnek be adminisztrátorok.
Ha egy támadó megtalálja ezt a felületet, akkor egy rosszul beállított weboldal és szerver esetén végtelen próbálkozási lehetősége van felhasználónév és jelszó megadására. És ha folyamatosan próbálkozik, egy gyengébb jelszót idővel meg is talál, és adminisztrátori jogosultságot szerez a weboldalra.
Az ilyen bejelentkezési felületeket úgy védjük, hogy például három téves jelszó megadása után a próbálkozó személyt IP cím vagy egyéb azonosító alapján korlátozzuk, vagy teljesen letiltjuk.
Ez a védelem a legtöbb hostingszolgáltatónál nincs beállítva, így a weboldal egyrészt támadható, mástrészt a teljesítménye is csökken.
Hiszen az alatt az idő alatt, amíg a weboldalt támadják (folyamatosan próbálkoznak), a weboldalt kiszolgáló szerver azzal van elfoglalva, hogy a támadót kiszolgálja, így kevesebb erőforrás marad a valódi látogatónak (mivel a szerver nem képes megkülönböztetni a támadót az átlagos látogatótól).
Vannak szerveroldali szoftverek, amelyek jól védhetnek az ilyen támadások ellen. Egy átlagos látogatottságú, tartalomkezelő rendszeren alapuló webhely esetén a megfelelően beállított Fail2ban például tökéletes lehet.
Ezeknek a szerveroldali szoftvereknek a beállítása azonban szakembert igényel.
Monitorozás
A weboldal az üzemeltetése során változó mértékű terhelésnek van kitéve.
A felhasználási módtól függően a weboldalt üzemeltető szerver különböző paramétereit érdemes monitorozni, éppúgy, ahogy a weboldal uptime-ját.
Ugyanis ha például a webtárhely betelik, mert túl sok, illetve nagy méretű képet, videót töltünk fel, akkor a weboldal működése is leállhat.
Ha a processzor túlterhelt, akkor a szerver nem képes kiszolgálni minden látogatót, aminek következtében néhány látogatónál betölt az oldal, néhánynál viszont nem.
A szerver alapvető paraméterei – mint például a processzor kihasználtsága, tárhely, memóriakihasználtság, de a weboldal látogatottsága is – mind monitorozhatók akár ingyenes szerveroldali szoftverek segítségével is.
A Promptnál mi a Prometheus ingyenes adatgyűjtőt és a Grafana dashboardot használjuk arra, hogy a szervereink életjeleit monitorozzuk.
A szervermonitorozás persze nem annyit jelent, hogy beállítunk egy ilyen rendszert, majd a monitorozó szép grafikonjait kivetítjük egy nagy képernyőre, és odaültetünk valakit.
Azért fontos, hogy vissza tudjuk nézni az eseményeket, mert előfordulhat, hogy valamit ki akarunk deríteni.
A monitorozó másik fontos funkciója az, hogy vizsgálja a szerver különböző paramétereinek értékeit, és ha ezek elérnek egy beállított határértéket megadott időn belül, akkor értesítést küld az üzemeltetőnek.
Az ilyen szoftverek beüzemelése is szakembert igényel, és ezek a monitorozó szoftverek már meglehetősen ritkán elérhetőek egy átlagos hostingszolgáltatónál.
Persze ha van ilyen, akkor az értesítések, amelyeket a rendszer küld, a hostingszolgáltató belső IT-s csapatára tartoznak, és ők a felelősek azért, hogy reagáljanak a monitorozó által küldött értesítésekre.
Nyitott portok
A legkisebb jogosultság elve szerverkörnyezetben is alkalmazandó, abból a szempontból, hogy azok a szolgáltatások, amelyekre nincs szükség, ne legyenek fölöslegesen bekapcsolva, illetve ne legyenek elérhetőek bárki számára, akinek semmi szüksége rájuk.
Általános értelemben a portszám egy olyan (számozott) „kapu”, amelyen keresztül kommunikálhatunk egy szerveren futó szolgáltatással (ha az persze üzemel).
Egy webszervert (általában) a TCP 80-as és TCP 443-as porton keresztül tudunk elérni, így válik lehetővé az, hogy a böngészőnkben megjelenjen az a weboldal, amit éppen meglátogattunk.
Ha egy weboldal betölt a böngészőnkben, akkor az azt jelenti, hogy a weboldalt üzemeltető szerveren nyitva van a TCP 80-as (http esetén) és a TCP 443-as (https esetén) port. Ez a két port szükséges ahhoz, hogy a webszerver normálisan tudjon üzemelni, és ki tudja szolgálni a látogatóit.
Azonban vannak olyan portok, amelyek arra adnak lehetőséget, hogy egy rendszergazda távolról bejelentkezzen a szerverbe, és adminisztrátori módosításokat, illetve karbantartást végezzen a szerveren.
Azonban az a szituáció meglehetősen ritka, hogy a rendszergazda a világ bármely pontjáról be kell hogy tudjon lépni a szerver adminisztrációs területeire, tehát azokat a portokat, amelyek erre lehetőséget nyújtanak(pl. SSH, RDP stb.), el kell zárni.
Persze felmerül a kérdés: hogyan végezzünk adminisztrátori karbantartást a szerveren, ha ezek a portok zárva vannak?
A válasz az, hogy a portokat bizonyos IP címekről ki lehet nyitni.
Így például a rendszergazda a munkahelyén keresztüli IP címről bejelentkezve már elérheti a szerveren az adminisztrációs felületet, de a világ bármely más pontjáról nem.
Ezzel azt érjük el, hogy a világ bármely pontjáról lehetetlen lesz ezeket a szolgáltatásokat a nyitott porton keresztül támadni, mert a szerver tűzfala egyszerűen eldobja az ezekre a portokra érkező kérést, ha azok nem a cég saját irodáján keresztüli IP címről érkeznek be.
Linux szervereken az nftables (korábbi nevén iptables) nevű tűzfallal állíthatunk be ilyen védelmet.
Ezek alapján persze ismét jogos a kérdés: hogyan végez a rendszergazda karbantartást a szerveren, ha épp nincs az irodában?
A válasz: VPN szolgáltatás segítségével.
Vírusellenőrzés
A szerver által üzemeltetett weboldal forráskódja gyakran tartalmaz harmadik féltől származó forráskódot.
Ennek következtében a tartalomkezelő weboldalban előfordulhatnak olyan sérülékenységek, amelyek lehetővé teszik, hogy a támadó fertőzött kódot vagy fájlt juttasson el a szerverre.
Ebből következik, hogy a szerveren is szükséges a vírusellenőrzés, amely kiszűri a vírusos forráskódot vagy fájlt, és karanténba helyezi, vagy törli a szerverről.
Szerveren működő vírusellenőrző például az Amavis, valamint az ISPProtect, amely kifejezetten weboldalak ellenőrzésére való (és amely az Amavist is használja a háttérben).
Ilyen vírusellenőrző szoftvereket is hozzáértő szakember kell hogy telepítsen és rendszeresen futtasson a szerveren.
Webalkalmazás-tűzfal
Elsődleges biztonsági védvonal lehet az üzemeltetésben a webalkalmazás-tűzfal.
Ez egy olyan különálló szoftver, amely a webszerver és a látogató között helyezkedik el, monitorozza a forgalmat, és ha gyanús tevékenységet észlel, tiltja a kérést.
Webalkalmazás-tűzfal telepíthető közvetlenül a szerverre is, de külső szolgáltatók, pl. a Cloudflare segítségét is igénybe lehet venni ehhez.