Egy kompromittált szerver nemcsak adatvesztést jelent – az üzleti hírnevet, az ügyfelek bizalmát és akár a vállalkozás egészének működését is veszélyeztetheti. A kibertámadások száma évről évre növekszik, és a célpontok egyre inkább a kis- és középvállalkozások szerverinfrastruktúrái. Ez a részletes checklist segít megérteni és implementálni azokat a biztonsági intézkedéseket, amelyek valóban védik a rendszert – a tűzfal konfigurációtól kezdve a penetrációs tesztelésig.

A lista 20 konkrét lépésre épül, amelyek együttesen egy robusztus, többrétegű védelmi rendszert alkotnak. Ne hagyjunk ki egyetlen pontot sem – a biztonság csak annyira erős, mint a leggyengébb láncszeme.

Alapszintű rendszerbiztonság

1. Operációs rendszer és szoftverek naprakészen tartása

A legegyszerűbb és leghatékonyabb védelmi intézkedés: minden szoftvert és az operációs rendszert mindig a legfrissebb verzióra frissítve kell tartani. A sérülékenységek döntő többségét ismert sebezhetőségek kihasználásával érik el, amelyekre már léteznek biztonsági javítások. Engedélyezzük az automatikus biztonsági frissítéseket (pl. unattended-upgrades Linuxon), és rendszeresen ellenőrizzük a szoftver függőségeket is.

2. Tűzfal konfiguráció – csak a szükséges portok legyenek nyitva

A tűzfal az első védelmi vonal. Az alapelv egyszerű: deny all, allow by exception – alapból mindent tiltunk, és csak a valóban szükséges portokat és protokollokat engedélyezzük. Linux szervereken az iptables vagy az egyszerűbb ufw ajánlott. Tipikusan elegendő nyitva tartani a 80-as (HTTP), 443-as (HTTPS) és 22-es (SSH) portokat. Érdemes a webes adminisztrációs felületeket (pl. phpMyAdmin) VPN mögé zárni, vagy legalább IP-alapú szűréssel védeni.

3. SSH védelem – kulcsalapú hitelesítés és portváltás

Az SSH az egyik legtámadottabb protokoll. Három alapvető lépéssel drasztikusan csökkenthetjük a kockázatot: (1) tiltsuk le a jelszóalapú bejelentkezést, és engedélyezzük kizárólag az SSH-kulcsalapú hitelesítést; (2) változtassuk meg az alapértelmezett 22-es portot egy magasabb, kevésbé nyilvánvaló portra; (3) aktiváljuk a fail2ban szolgáltatást, amely automatikusan blokkolja a brute-force próbálkozásokat.

4. Root hozzáférés letiltása

Soha ne engedélyezzük a közvetlen root bejelentkezést SSH-n keresztül. Hozzunk létre normál felhasználói fiókokat, és csak szükség esetén emeljük a jogosultságokat a sudo parancs segítségével. Állítsuk be a PermitRootLogin no paramétert az SSH konfigurációban. Ez jelentősen megnehezíti a kompromittálást, még ha a támadó meg is szerzi az SSH-hozzáférést.

5. Minimális szoftverkörnyezet – csak a szükséges szolgáltatások

Minden telepített csomag és futó szolgáltatás potenciális támadási felületet jelent. Távolítsunk el minden felesleges szoftvert, és tiltsuk le az inaktív szolgáltatásokat. Rendszeresen ellenőrizzük a futó folyamatokat és a nyitott portokat a netstat -tulpn vagy az ss -tulpn parancsokkal.

Hozzáférés-kezelés és hitelesítés

6. Erős jelszópolitika és MFA bevezetése

Minden rendszerfiókhoz kötelező legyen a legalább 16 karakteres, összetett jelszó. Vezessük be a többfaktoros hitelesítést (MFA) minden adminisztrációs hozzáférésnél. Linux szervereken a Google Authenticator PAM modul egyszerűen integrálható. Jelszókezelő alkalmazás (pl. Bitwarden, 1Password) használatát javasoljuk az adminisztrátori csapat számára.

7. Principle of Least Privilege – minimális jogosultság elve

Minden felhasználó és folyamat csak annyi jogosultsággal rendelkezzen, amennyire valóban szüksége van a feladatai elvégzéséhez. Rendszeresen auditáljuk a felhasználói fiókokat és töröljük a már nem aktív hozzáféréseket. Az adatbázis-felhasználók számára is hozzunk létre dedikált, korlátozott jogosultságú fiókokat.

8. VPN a belső hálózati hozzáféréshez

Az adminisztrációs felületek és belső szolgáltatások elérését kizárólag VPN-en keresztül tegyük lehetővé. A WireGuard modern, gyors és könnyen konfigurálható megoldást jelent. Ezzel az összes szensitív adminisztrátori forgalom titkosított csatornán zajlik, és a kiszolgálók adminisztrációs portjai nem lesznek közvetlenül elérhetők az internetről.

9. Fiókok és munkamenetek időkorlátja

Konfiguráljuk az automatikus munkamenet-lejáratot inaktivitás esetén. SSH kapcsolatoknál alkalmazzuk a ClientAliveInterval és ClientAliveCountMax paramétereket az elavult munkamenetek leválasztásához. Webes adminisztrációs felületeknél állítsunk be rövid session timeout értéket (pl. 15-30 perc).

10. Privilegizált hozzáférések naplózása (PAM)

Minden privilegizált tevékenységet (sudo parancsok, rendszergazdai bejelentkezések) részletesen naplózzunk. Érdemes megfontolni egy Privileged Access Management (PAM) megoldás bevezetését, amely rögzíti a teljes munkameneteket, és lehetővé teszi az auditálást. Ez különösen fontos a compliance követelmények teljesítéséhez.

Monitoring, naplózás és incidens-kezelés

11. Centralizált log management rendszer

A napló fájlok (logok) a szerveren való biztonságos tárolása önmagában nem elegendő – ha a rendszer kompromittálódik, a naplók is törlhetők. Implementáljunk centralizált log management megoldást (pl. ELK Stack: Elasticsearch, Logstash, Kibana), ahol a naplók egy külön, biztonságos szerverre kerülnek valós időben. Konfiguráljuk a syslog-ot, az authlognaplókat, a webszerver access és error logjait egyaránt.

12. Valós idejű riasztások és anomália-detekció

Állítsunk be automatikus riasztásokat gyanús tevékenységek esetén: sikertelen bejelentkezési kísérletek sorozata, szokatlan időpontban történő root hozzáférés, nagy mennyiségű adatátvitel, vagy ismeretlen IP-ről érkező kapcsolatkísérlet. Az OSSEC vagy a Wazuh HIDS (Host Intrusion Detection System) megoldások ingyenesen elérhetők és hatékonyak.

13. Fájlrendszer integritás-ellenőrzés

A fájlrendszer-integritás monitoring (FIM) figyeli a kritikus rendszerfájlok és konfigurációk változásait, és riaszt, ha jogosulatlan módosítás történt. Az AIDE (Advanced Intrusion Detection Environment) vagy a Tripwire kiváló, nyílt forráskódú megoldások. Alapállapot-adatbázist kell létrehozni a szerver tiszta telepítése után, és azt rendszeresen frissíteni.

14. Rendszeres biztonsági mentések és helyreállítási terv

A biztonsági mentés maga is biztonsági intézkedés: ransomware támadás vagy rendszerhiba esetén ez az egyetlen visszaút. A 3-2-1 szabályt kövessük: 3 másolat, 2 különböző adathordozón, 1 külső helyszínen. A mentések titkosítva tárolandók, és rendszeresen tesztelni kell a visszaállíthatóságukat. Egy nem tesztelt mentés olyan, mintha nem is lenne.

15. Incidens-kezelési terv kidolgozása

A technikai védelem mellett elengedhetetlen egy dokumentált incidens-kezelési folyamat. Ki az értesítési lánc? Hogyan kell elszigetelni a kompromittált rendszert? Mikorra kell értesíteni az érintett felhasználókat? GDPR szempontból különösen fontos a 72 órás bejelentési határidő. Az incidensre adott gyors, szervezett válasz akár napokat spórolhat meg az állásidőből.

Haladó biztonsági intézkedések

16. SSL/TLS tanúsítványok és titkosítás

Minden nyilvánosan elérhető szolgáltatáshoz kötelező a HTTPS. A Let’s Encrypt ingyenes, automatikusan megújítható tanúsítványokat kínál. Emellett tiltsuk le az elavult TLS 1.0 és 1.1 protokollokat, és konfiguráljuk a szerver csak erős titkosítási algoritmusokat (cipher suite-okat) fogadjon el. Az SSL Labs tesztjével ellenőrizzük a konfiguráció minőségét – az „A” minősítés legyen a minimum.

17. SELinux vagy AppArmor bekapcsolása

A kötelező hozzáférés-vezérlési (MAC) rendszerek, mint a SELinux (Red Hat/CentOS) vagy az AppArmor (Ubuntu/Debian), az operációs rendszer szintjén korlátozza a folyamatok tevékenységét, még akkor is, ha egy alkalmazást sikeresen kompromittálnak. Ez egy rendkívül hatékony biztonsági réteg, amelyet sajnos sok rendszergazda letilt, mert konfigurálása némi tanulást igényel – de a befektetett idő megéri.

18. Web Application Firewall (WAF) alkalmazása

Webalkalmazásokat kiszolgáló szervereknél elengedhetetlen a WAF bevezetése. A ModSecurity nyílt forráskódú megoldás Apache és Nginx mellett is működik, és az OWASP Core Rule Set-tel kombinálva hatékonyan véd az SQL injekció, XSS és más webes támadásokkal szemben. Felhőalapú WAF megoldások (pl. Cloudflare WAF) is elérhetők, amelyek DDoS védelmet is nyújtanak.

19. Rendszeres sérülékenység-vizsgálat (Vulnerability Scanning)

Havi rendszerességgel végezzünk automatizált sérülékenység-vizsgálatot a szerveren és a futtatott alkalmazásokon. Az OpenVAS és a Nessus (korlátozott ingyenes verzióban is elérhető) kiváló eszközök erre a célra. A vizsgálat azonosítja a javítandó sérülékenységeket, helytelen konfigurációkat és elavult szoftverkomponenseket, mielőtt a támadók kihasználnák azokat.

20. Penetrációs tesztelés – valódi támadói szemszögből

A penetrációs teszt (pen test) a végső próba: egy etikus hacker megkísérli feltörni a rendszert, és dokumentálja a talált réseket. Évente legalább egyszer, de jelentős infrastrukturális változások után mindig érdemes elvégeztetni professzionális szakértőkkel. A pen teszt nem csupán technikai hibákat tár fel – rámutat a folyamatok és az emberi tényezők gyengeségeire is (social engineering, phishing).

Összefoglalás: a biztonság egy folyamat, nem egy cél

Ez a 20 lépéses checklist lefedi a szerver biztonság legfontosabb aspektusait – az alapszintű hardening intézkedésektől a haladó monitoring és tesztelési megoldásokig. Fontos azonban megérteni: a biztonság nem egy egyszeri feladat, amelyet elvégzünk és utána elfelejtünk. Ez egy folyamatosan karbantartandó rendszer, amely rendszeres auditokat, frissítéseket és az újabb fenyegetésekre adott proaktív válaszokat igényel.