Tűzfal és hálózati elkülönítés szolgáltatás

Amit a hálózatodon konkrétan beállítunk

Alapértelmezett tiltásból indulunk ki, mind bejövő, mind kimenő irányban, és csak azt engedjük, amire ténylegesen szükség van: kívülről szinte mindig csak a 80-as és a 443-as port. Az adatbázis, a cache, a sorkezelő és az admin panelek soha nem kapnak nyilvános IP-t, csak privát hálózatot vagy VPN-t. A hálózatot rétegekre bontjuk: edge, alkalmazás, adat, mindegyik saját szabálykészlettel, hogy egy kompromittált réteg ne jelentsen automatikus hozzáférést a következőhöz.

• Alapértelmezett tiltás bejövő és kimenő irányban egyaránt
• Kívülről csak 80/443, minden más zárva vagy privát hálózaton
• Rétegzett szegmentálás: edge, alkalmazás, adat, külön szabályokkal
• nftables vagy UFW a szerveren, plusz a szolgáltatói tűzfal

Bevált gyakorlatok, amelyeket alkalmazunk

Egy nyitva felejtett port nem elméleti kockázat: automatizált scannerek óránként pásztázzák a nyilvános IP-tartományokat, és percek alatt megtalálják a véletlenül kinyitott adatbázis- vagy admin-portot. Ezt a listát minden szerveren alkalmazzuk, és a te dokumentációdban is rögzítjük, a rendszeres ellenőrzés eredményeivel együtt. Nem elég egyszer beállítani: a konfiguráció eltolódását folyamatosan figyeljük, mert egy kézi módosítás hetekig észrevétlen maradhat. Az eredményt a havi DevOps órák keretében is átnézzük veled. Ezt a listát minden szerverünkön ugyanúgy alkalmazzuk, a legkisebb VPS-től a legnagyobb dedikált gépig.

• Alapértelmezett tiltás bejövő irányban, korlátozott kimenet
• Szegmentálás rétegenként: edge, alkalmazás, adat
• Adatbázis, Redis és MongoDB soha nem kap nyilvános IP-t
• Automatizált, rendszeres port-audit kívülről, eltéréskor riasztással
• Naplózás, plusz geo- és ASN-szabályok, ahol ez indokolt

Fail2ban, CrowdSec és a folyamatos ellenőrzés

A tűzfalszabályok mellett a folyamatos figyelés is számít: a Fail2ban vagy a CrowdSec a naplókból ismeri fel az ismétlődő bejelentkezési kísérleteket vagy a gyanús forgalmat, és automatikusan tiltja az IP-t. Ehhez rendszeres, kívülről futtatott port-auditot adunk, hogy ne csak a beállított szabályokban, hanem a tényleges, élő állapotban is lássuk, mi érhető el az internet felől. Egy eltérés azonnali riasztást vált ki, mielőtt bárki kihasználhatná.

• Fail2ban vagy CrowdSec a naplók alapú automatikus tiltásra
• Rendszeres, kívülről futtatott port-scan, riasztással eltérésnél
• Geo- vagy ASN-alapú szűrés, ha az indokolt

A beleértett órák és a bevezetés

A hálózat szegmentálása, a tűzfalszabályok bevezetése és a folyamatos audit beállítása a havi órák terhére történik: 1–8 óra a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken. Az ügyfélpanel DevOps szolgáltatások menüpontjából kéred, javasolt határidővel. Az első bevezetés jellemzően egy hónapot vesz igénybe, utána a havi keretből a szabályok karbantartása és az auditok követése történik. A kereten felüli munkát külön számlázzuk.

Hogyan dolgozunk

1. Igényled a panelből

   Elmondod, milyen szolgáltatásaid futnak, és melyik portok legyenek nyilvánosan elérhetők, majd javasolsz egy határidőt a DevOps szolgáltatások menüpontban.

2. Egyeztetjük a kereteket

   Feltérképezzük a jelenlegi kitettséget, meghatározzuk a hálózati rétegeket, és kijelöljük, mely szolgáltatások kerülnek kizárólag privát hálózatra vagy VPN mögé.

3. Megvalósítjuk és auditáljuk kívülről

   Bevezetjük a tűzfalszabályokat és a szegmentálást, majd kívülről futtatott port-scannel ellenőrizzük, hogy valóban csak a tervezett portok érhetők el.

4. Dokumentálva átadjuk

   Megkapod a szabálykészletet, a hálózati diagramot, az audit eredményét és azt az eljárást, amellyel új szolgáltatás hozzáadásakor eljárunk.

Felhasználási esetek

Technológiák

• nftables
• UFW
• Fail2ban
• CrowdSec
• WireGuard
• nmap
• Prometheus

Gyakori kérdések

• Miért ne legyen az adatbázis port nyilvánosan elérhető, ha erős jelszó védi?

  Mert a nyilvánosan elérhető port önmagában is támadási felület: automatizált scannerek folyamatosan pásztázzák a nyilvános IP-tartományokat, és egy jövőbeli sérülékenység azonnal kihasználhatóvá válik, ha a port elérhető. A privát hálózat mögötti adatbázis csak a valóban jogosult gépekről érhető el.

• Mi az a default-deny tűzfalszabály?

  Azt jelenti, hogy alapértelmezésben minden forgalmat tiltunk, és csak azt engedjük külön szabállyal, amire ténylegesen szükség van. Ez ellentéte annak, amikor mindent engednek, és csak a rossznak ismert forgalmat tiltják, ami a gyakorlatban mindig lemarad az új fenyegetések mögött.

• Mi a különbség az nftables és az UFW között?

  Az UFW egy egyszerűsített felület, amely az nftables vagy az iptables fölé épül, gyors beállításra jó. Az nftables közvetlen, finomabb kontrollt ad, jobban illik összetettebb szegmentáláshoz. A választás a rendszer méretétől és a csapatod tapasztalatától függ.

• Milyen gyakran kell port-auditot futtatni?

  Rendszeresen, automatizáltan, nem csak a bevezetéskor egyszer. A konfiguráció idővel eltolódhat, egy új szolgáltatás telepítése véletlenül nyithat portot. A rendszeres, kívülről futtatott audit észreveszi az eltérést, mielőtt bárki más megtalálná.

• Hogyan véd a tűzfal a DDoS-támadások ellen?

  Önmagában korlátozottan: a tűzfal a portokat és a szabályokat kezeli, a nagy volumenű DDoS-t inkább hálózati szinten kell megállítani. Ezért a szerverek hálózati DDoS-védelemmel érkeznek, a tűzfal pedig a fennmaradó, célzott forgalom ellen véd, a szegmentálással együtt.

• Mit jelent a hálózati szegmentálás gyakorlatban?

  Azt, hogy az edge, az alkalmazás és az adatréteg külön hálózati zónában van, külön szabályokkal. Ha valaki bejut az edge-rétegbe, az nem jelent automatikus hozzáférést az adatréteghez. Minden zóna csak azzal kommunikálhat, amivel ténylegesen kell.