Firewall použitý na každém serveru je jedním z nejjednodušších způsobů, jak zmenšit útočnou plochu firemního prostředí. Omezuje, které systémy se mohou připojit, odkud a za jakým účelem. To je důležité i tehdy, když je server za cloudovou bezpečnostní skupinou, virtuální sítí nebo fyzickým perimetrovým firewallem.
Nejspolehlivějším výchozím bodem je zásada výchozího zákazu: blokovat nevyžádaný příchozí provoz, povolit pouze zdokumentované služby a odchozí provoz řídit tam, kde to odůvodňuje riziko. Pravidla by měla odrážet roli serveru, nikoli být kopírována z obecného seznamu portů. Veřejný webový server, databázový server, poštovní relay a zdroj záloh mají odlišné požadavky.
Tento přístup také zpřehledňuje odpovědnost. Každý server má explicitní síťovou politiku, takže zapomenutá služba není automaticky dostupná jen proto, že naslouchá.
Začněte se zásadou výchozího zákazu
Praktický firewall serveru má obvykle tři vrstvy rozhodování:
- Příchozí provoz: ve výchozím nastavení zamítnout a poté povolit pouze porty potřebné pro legitimní služby.
- Odchozí provoz: povolit potřebná připojení, ale pokud možno omezit citlivé nebo nepotřebné cíle.
- Interní provoz: povolit pouze komunikaci potřebnou mezi definovanými rolemi serverů, sítěmi nebo systémy pro správu.
Před změnou pravidel zdokumentujte funkci serveru, služby, které na něm naslouchají, jejich očekávané klienty a to, zda jsou tito klienti veřejní, privátní nebo administrativní. Užitečnými zdroji jsou konfigurace služeb, cloudové bezpečnostní skupiny, nastavení load balanceru, záznamy DNS, dokumentace aplikace a protokoly připojení.
Nepovažujte port za bezpečný nebo nebezpečný izolovaně. Číslo portu označuje konvenční službu, nikoli kvalitu její konfigurace. Port 443 může stále zpřístupňovat zranitelnou aplikaci, zatímco SSH na portu 22 může být dobře chráněné, pokud je přístup omezený a autentizace posílená. Změna výchozího portu může omezit běžné skenování, ale nenahrazuje řízení přístupu.
Běžné porty služeb a riziko jejich vystavení
Týmy často hledají běžné porty serverového firewallu, které otevřít a blokovat, ale po seznamu by vždy mělo následovat rozhodnutí o přístupu. Důležitou otázkou není jen to, zda služba port používá, ale také kdo se k ní potřebuje připojit a z jaké sítě.
Porty 80 a 443: veřejné webové služby
Porty 80 a 443 jsou obvykle vhodné pro veřejný web nebo webovou aplikaci. Port 443 přenáší HTTPS a měl by být hlavním veřejným vstupním bodem. Port 80 může být potřebný pro přesměrování z HTTP na HTTPS, ověřování certifikátů, kompatibilitu se staršími systémy nebo záměrně veřejnou službu HTTP.
Pokud je server za reverzní proxy, CDN nebo load balancerem, zdrojový server nemusí nutně přijímat webový provoz z celého internetu. Omezení příchozích připojení na zveřejněné rozsahy adres proxy může snížit počet útoků přímo na zdrojový server. Zajistěte, aby aplikace stále dostávala důvěryhodné informace o klientovi a aby návrh zahrnoval kontroly dostupnosti, obnovu certifikátů i procesy nasazení.
U interní aplikace nemusí být žádný z těchto portů veřejný. Místo toho povolte přístup z firemní sítě, VPN, aplikační brány nebo určených privátních podsítí.
Port 22: zabezpečení SSH
SSH je nezbytné pro správu Linuxu, automatizaci a některé pracovní postupy přenosu souborů, ale jeho globální vystavení zve k hádání hesel, útokům na přihlašovací údaje a zneužití slabin v SSH nebo související konfiguraci.
Pro silné zabezpečení SSH povolte port 22 pouze z rozsahu adres VPN, firemní výstupní IP adresy, zabezpečeného bastion hostu nebo privátní sítě pro správu. Upřednostněte autentizaci pomocí klíčů, kde je to praktické zakažte přímé přihlašování heslem, omezte privilegovaný přístup a používejte samostatné pojmenované účty s auditovaným navýšením oprávnění. Vícefaktorová autentizace může přidat další vrstvu ochrany, zejména pokud administrativní přístup prochází nedůvěryhodnou sítí.
Přesun SSH na jiný port může snížit množství šumu v protokolech, ale neudělá z internetové služby privátní službu. Pokud je vzdálená správa pouze příležitostná, VPN nebo firewallové pravidlo aktivované podle potřeby je obvykle lepší kontrolou než spoléhání na utajení.
Port 3389: zabezpečení RDP
RDP je cenným cílem, protože poskytuje interaktivní přístup k systémům Windows. Port 3389 by za běžného provozu neměl být otevřený veřejnému internetu. Použijte VPN, privátní síť, bránu vzdáleného přístupu nebo bastion službu a omezte zdrojové adresy na schválené administrativní sítě.
Dobré zabezpečení RDP závisí také na autentizaci na úrovni sítě, silných kontrolách identity, aktualizacích, uzamykání účtů nebo rovnocenných zásadách detekce a na omezení administrátorů, kteří se mohou přihlásit. Pokud přístup potřebuje tým externí podpory, poskytněte mu definovanou cestu a časově omezené oprávnění namísto trvalého pravidla z libovolného zdroje.
Port 25: SMTP
Port 25 se používá pro doručování e-mailů mezi servery. Poštovní server, který odesílá nebo přímo přijímá poštu, jej může potřebovat, ačkoli poskytovatelé a nadřazené sítě někdy odchozí SMTP omezují kvůli prevenci zneužití. Server, který neposkytuje poštovní služby, by port 25 neměl vystavovat.
Nepředpokládejte, že povolení odchozího portu 25 na každém serveru je neškodné. Napadený aplikační server se může stát zdrojem spamu nebo poškodit reputaci organizace v oblasti e-mailu. Pokud je to možné, směrujte aplikační e-maily přes schválený relay a povolte odchozí SMTP pouze k tomuto relay serveru. Příchozí port 25 by měl být omezen na skutečnou poštovní roli, přičemž opatření proti zneužití je třeba spravovat samostatně.
Port 53: DNS
DNS používá port 53 přes UDP i TCP. Rekurzivní resolver může potřebovat odpovídat na dotazy klientů z interní sítě, zatímco autoritativní DNS server může odpovídat na veřejné dotazy. Jde o odlišné role, které by se neměly bez rozmyslu kombinovat.
Nikdy nevystavujte internetu otevřený rekurzivní resolver. Omezte rekurzi na schválené sítě, povolte přenosy zón pouze mezi určenými nameservery a povolte TCP 53 tam, kde to vyžadují velké odpovědi, DNSSEC nebo přenosy zón. Server, který DNS pouze využívá, by měl obvykle odesílat dotazy na určené resolvery, nikoli přijímat příchozí DNS provoz.
Porty 3306 a 5432: MySQL a PostgreSQL
MySQL běžně naslouchá na portu 3306 a PostgreSQL na portu 5432. Tyto porty by téměř nikdy neměly být veřejné. Databáze obsahují cenná firemní data a často jsou cílem útoků na přihlašovací údaje, hledání chybné konfigurace a zneužití neaktualizovaného softwaru.
Povolte databázový provoz pouze z aplikačních serverů, reportovacích systémů, administrativního bastionu nebo privátní sítě, která jej skutečně potřebuje. Používejte nativní autentizaci databáze, podporované šifrování, účty s nejmenšími nutnými oprávněními a síťová pravidla odpovídající topologii aplikace. Navázání databáze na privátní rozhraní je užitečné, ale mělo by firewall doplňovat, nikoli nahrazovat.
Stejně zacházejte s ovládacími panely, rozhraními pro orchestraci, konzolemi hypervizoru a monitorovacími endpointy. Měly by být dostupné pouze přes síť pro správu, VPN nebo přísně řízený seznam povolených adres. Veřejně vystavené rozhraní pro správu může změnit jediné odcizené heslo nebo neaktualizovanou komponentu v převzetí kontroly nad serverem a potenciálně i nad připojeným prostředím.
Oddělte veřejný, aplikační a administrativní provoz
Pravidla portů jsou účinnější, když je síť segmentovaná. Typické nasazení v malé firmě může oddělovat:
- Veřejné služby: webové nebo poštovní služby, které musí přijímat připojení z internetu.
- Aplikační služby: API, fronty a interní komponenty aplikací dostupné pouze ze schválených systémů.
- Datové služby: databáze a úložiště dostupné pouze z aplikačních nebo administrativních sítí.
- Administrativní služby: SSH, RDP, ovládací panely, monitorovací a orchestrační nástroje dostupné pouze přes privátní cesty pro správu.
- Připojení pro zálohování: odchozí připojení z chráněných serverů ke schválenému cíli záloh, bez obecného příchozího přístupu k úložišti záloh.
Tento model omezuje laterální pohyb útočníka. Pokud je veřejná webová služba napadena, útočník by se automaticky neměl moci připojit k databázi, hypervizoru nebo zálohovacímu systému. Firewallová pravidla by měla uvádět zdrojovou a cílovou roli, nikoli z pohodlnosti povolovat celou virtuální síť.
Kontrolu vyžaduje i interní provoz. Privátní IP adresy nejsou automaticky důvěryhodné. Napadený interní server může skenovat a napadat jiný systém stejně účinně jako internetový hostitel. Mezi podsítěmi a rolemi serverů uplatňujte nejmenší nutná oprávnění a vyhýbejte se širokým pravidlům, například povolení všech portů ze všech interních adres.
Chraňte připojení k zálohám a kopie pro obnovu
Provoz záloh potřebuje záměrně navrženou cestu, protože zálohovací systémy jsou cennými cíli. Běžným bezpečnějším vzorem je, že zdrojový server pod kontrolou zákazníka zahájí odchozí připojení k zálohovací službě, zatímco příchozí připojení z internetu k úložišti záloh zůstávají blokována. Povolte pouze cíl, protokol a směr vyžadované návrhem zálohování.
Nevystavujte úložiště záloh, endpoint úložiště ani rozhraní pro správu záloh přímo internetu. Pokud zálohovací produkt vyžaduje příchozí komunikaci, umístěte ji za privátní síť, VPN nebo přísně omezený seznam povolených adres a zdokumentujte, proč je nezbytná. Přihlašovací údaje pro zálohy oddělte od produkčních údajů a pro operace zálohování nepoužívejte účet doménového administrátora.
Safenix poskytuje off-site zálohování firemních serverů pod kontrolou zákazníka. Zálohy jsou šifrovány klíčem, který Safenix nikdy nedrží, ukládány v Německu a neměnné po celou dobu retenčního období. Zákazník by měl přesto omezit připojení k zálohám na zdrojovém firewallu a povolit pouze provoz potřebný pro přístup ke službě. Podrobnosti o firemním zálohování serverů Safenix a ochraně obnovy mimo lokalitu lze posoudit společně s návrhem firewallu zákazníka.
Vystavené připojení k zálohám vytváří dvě rizika. Útočník je může využít jako cestu do zálohovací platformy nebo může narušit, smazat či zašifrovat kopie pro obnovu. Co nejužší a pokud možno jednosměrný provoz záloh snižuje pravděpodobnost, že napadení produkčního serveru povede i ke kompromitaci prostředí obnovy.
Pravidla pro IPv4 a IPv6 se musí shodovat
Častou chybou firewallu je zabezpečení IPv4 při současném ponechání široké dostupnosti přes IPv6. Pokud má server veřejnou IPv6 adresu, potřebuje politiku firewallu IPv6 se stejnou zásadou výchozího zákazu, omezením služeb a požadavky na logování jako IPv4.
Nepředpokládejte, že vypnutí pravidla IPv4 ochrání službu. U obou protokolů zkontrolujte naslouchající adresy, cloudové bezpečnostní skupiny, konfiguraci firewallu hostitele a kontroly na úrovni poskytovatele. Pokud IPv6 není potřeba, deaktivujte jej až po ověření, že aplikace, monitoring, DNS a síťové závislosti budou dál fungovat. V opačném případě jej řádně udržujte.
Prověřte odchozí IPv6 stejně jako příchozí provoz. Aplikace, která může přes nesledovanou rodinu adres přistupovat k externím systémům, může obejít předpoklady bezpečnostního návrhu založeného pouze na IPv4.
Odchozí pravidla, logování a upozornění
Blokování veškerého odchozího provozu je pro firemní server jen zřídka praktické. Aktualizace, DNS, synchronizace času, e-mail, API, monitoring a zálohy mohou vyžadovat odchozí přístup. Rozumná politika začíná identifikací těchto závislostí a následně podle provozního rizika omezuje cíle a porty.
Aplikační server může například potřebovat HTTPS ke konkrétním softwarovým službám, DNS ke schváleným resolverům, NTP ke schváleným zdrojům času a odchozí připojení k zálohám. Nemusí mít žádný důvod připojovat se k libovolným SMTP serverům, databázovým portům nebo službám vzdálené správy na internetu.
Logujte zamítnutý provoz, ale tak, aby byly protokoly užitečné a nepřetěžovaly vás. Zaznamenávejte zdroj, cíl, port, protokol, rozhraní, akci a časové razítko. Opakující se události omezujte podle frekvence a důležité protokoly odesílejte do umístění, které útočník nemůže snadno pozměnit. Upozorňujte na vzorce, jako jsou opakované pokusy o SSH nebo RDP, skenování mnoha portů, neočekávané odchozí SMTP, nový přístup k databázovým portům nebo náhlá změna chování připojení k zálohám.
Logování má podporovat vyšetřování, nikoli nahrazovat prevenci. Pravidlo, které každý den generuje tisíce upozornění, bude dříve či později ignorováno. Nastavte prahové hodnoty podle běžného provozu a určete, kdo upozornění kontroluje, jak rychle a jaké důkazy se mají uchovávat.
Jak mohou agentury spravovat mnoho klientských prostředí
Agentury potřebují konzistenci, aniž by předstíraly, že každý klient má stejnou architekturu. Řešením je řízený základ s dokumentovanými výjimkami.
- Vytvořte šablony podle rolí pro webové, aplikační, databázové a poštovní servery, servery pro správu Windows a zdrojové servery záloh.
- Namísto pevného zakódování předpokladů používejte proměnné pro rozsahy IP adres klienta, adresy VPN, privátní podsítě a schválené cíle služeb.
- Pokud to platforma umožňuje, ukládejte firewallová pravidla jako konfiguraci ve správě verzí s kontrolou druhou osobou a zaznamenanou historií změn.
- Používejte standardní konvenci pojmenování pravidel včetně účelu, zdroje, cíle, vlastníka a data kontroly.
- Automatizací testujte syntaxi, ověřujte naslouchající požadované porty a kontrolujte shodu politik IPv4 a IPv6.
- Postupy nouzového přístupu uchovávejte odděleně a časově je omezujte; pokud možno nastavte automatické vypršení.
Před nasazením šablony vytvořte inventář služeb. Zkontrolujte dokumentaci aplikace, aktivní připojení a naplánované úlohy a zjistěte, kteří externí dodavatelé potřebují přístup. Krátká fáze zjišťování je levnější než přerušení fakturační integrace, monitorovacího agenta nebo procesu nasazení.
Změny zavádějte postupně. Pokud je to možné, použijte navrhovanou politiku nejprve v režimu auditu nebo logování, porovnejte zjištěný provoz se zamýšleným návrhem a poté ji vynucujte během servisního okna. Ponechte dostupnou konzoli mimo pásmo nebo obnovovací cestu, aby administrátor nebyl uzamčen chybným pravidlem.
Firewally VPS versus sdílený hosting
VPS dává zákazníkovi kontrolu nad operačním systémem, nainstalovanými službami a obvykle i firewallem na úrovni hostitele. Zákazník nebo jeho agentura proto odpovídá za rozhodnutí, které porty naslouchají a které zdroje k nim mohou přistupovat, spolu s případnými kontrolami poskytovanými hostingovou platformou.
Sdílený hosting je odlišný. Více zákazníků využívá prostředí spravované poskytovatelem, který řídí perimetr, izolaci sítě a vystavení služeb. Zákazník obvykle nemůže na základním hostiteli použít úplnou politiku firewallu pro každý server ani měnit příchozí pravidla poskytovatele. Užitečné srovnání infrastruktury VPS spravované zákazníkem a služeb sdíleného hostingu najdete v tomto přehledu VPS a hostingové infrastruktury.
Toto rozlišení je důležité pro bezpečnostní plánování. Web na sdíleném hostingu není totéž co firemní server pod kontrolou zákazníka s firewallem operačního systému. Safenix chrání servery pod kontrolou zákazníka; neposkytuje zálohovací plán pro web pouze proto, že je umístěn na sdíleném hostingu. Před návrhem postupů zálohování a obnovy je nutné potvrdit možnosti poskytovatele hostingu i odpovědnost zákazníka.
Kontrolu firewallových pravidel začleňte do provozu
Politika firewallu se stává nepřesnou okamžitě, jakmile se změní služby, dodavatelé, sítě nebo administrátoři. Pravidla kontrolujte alespoň pravidelně a po významných změnách architektury, migracích, bezpečnostních incidentech nebo personálních změnách.
Při kontrole odstraňte pravidla bez vlastníka, zdroje nebo zdokumentovaného obchodního účelu. Prověřte dočasné seznamy povolených adres, které nebyly nikdy odvolány, příliš široké rozsahy sítí, duplicitní záznamy, nepoužívané naslouchající služby a administrativní porty vystavené přes IPv6. Ověřte, že databázová a zálohovací rozhraní zůstávají privátní a že veřejné služby stále používají aktuální certifikáty a bezpečné konfigurace.
Ke každé výjimce uchovávejte jednoduchý záznam: co povoluje, proč existuje, kdo ji schválil, kdy má být zkontrolována a co by ji mohlo nahradit. Správa firewallu se tak promění ze souboru nahodilých oprav v opakovatelnou kontrolu.
Firewall pro každý server se zásadou výchozího zákazu nezabrání každému napadení, ale může zastavit mnoho zbytečných cest do systému a omezit pohyb po incidentu. Kombinujte jej s posílenou autentizací, správou aktualizací, segmentací, monitoringem a chráněnými zálohami mimo lokalitu. Výsledkem je menší útočná plocha a spolehlivější cesta k obnově ve chvíli, kdy server nebo síť již nejsou důvěryhodné.