Pravidla firewallu, na kterých skutečně záleží

Firewall je seznam toho, co je povoleno, a všechno ostatní se odmítá. Takhle napsané to zní banálně a sada pravidel, která chrání skutečný server, je opravdu krátká: jeden nebo dva veřejné porty, administrátorský přístup omezený na adresy, které ovládáš, a nic dalšího.

Chyba málokdy spočívá v chybějícím pravidlu. Bývá to pravidlo přidané ve tři ráno při hledání závady a nikdy neodstraněné, nebo služba, která vůbec neměla poslouchat na veřejném rozhraní, a tiše to dělá. Tento článek popisuje sadu pravidel, kterou stojí za to mít, v ufw i v nftables, porty, které zůstávají otevřené, aniž by to někdo rozhodl, důvod, proč Docker tvůj firewall úplně ignoruje, a co z toho všeho plyne, když tvůj server neběží na vlastním stroji, ale v cizím panelu.

Co firewall dělá a jak vypadá sada pravidel, která obstojí#

Firewall hostitele rozhoduje u každého paketu zvlášť, zda ho jádro předá poslouchajícímu procesu. Je to úzký úkol a stojí za to jasně říct, co mimo něj zůstává.

Nezastaví objemový záplavový útok. Ve chvíli, kdy paket dorazí na tvůj stroj, už prošel tvým uplinkem, takže jeho lokální zahození nevrátí kapacitu, kterou spotřeboval. Filtrování velkých záplav se musí dít výš v síti - co děláme proti útokům je upřímný popis toho, co se tak zachytí, a DDoS útoky na herní servery vysvětleně popisuje typy útoků. Nepomůže proti provozu, který vypadá přesně jako hráč, protože na úrovni paketů hráčem je. A nic nenadělá se slabým heslem, nezáplatovaným pluginem ani škodlivým modem, což jsou způsoby, jak se většina serverů ve skutečnosti ztrácí.

Co dělá, je omezení vystavené plochy na dvě nebo tři věci, které záměrně publikuješ. To má velkou cenu a zabere to asi deset minut.

Kostru tvoří pět pravidel, v tomto pořadí:

1. Přijmi navázaný a související provoz. Sledování spojení znamená, že odpovědi na spojení, která jsi otevřel ty, jsou povoleny bez pravidla pro každé z nich. Bez toho politika výchozího zákazu blokuje odpověď na každý požadavek, který tvůj server odešle.
2. Zahoď neplatné pakety. Provoz, který nepatří k žádnému sledovanému spojení a není ani legitimním novým.
3. Přijmi vše na loopbacku. Lokální služby spolu komunikují přes 127.0.0.1 a ::1. Jeho blokování rozbíjí věci matoucími způsoby.
4. Povol ICMP, které potřebuješ. Echo požadavky, aby tě šlo pingnout, a hlavně zprávy, díky kterým funguje zjišťování path MTU. Plošné zahazování ICMPv6 rozbije IPv6 úplně - IPv6 a herní servery vysvětluje proč.
5. Potom krátký seznam povolených věcí a všechno ostatní ve výchozím stavu zakázat.

Pravidla port po portu#

Každé pravidlo odpovídá na tři otázky: který port, který protokol a komu je otevřený. Třetí otázku lidé přeskakují a právě ta je nejdůležitější.

U dvou položek je třeba poznámka. Query porty musí být otevřené, jinak server běží bez problémů a nikdy se neobjeví v ničím prohlížeči, což je porucha, která na problém s firewallem vůbec nevypadá - proč tomu tak je, popisuje porty herních serverů vysvětleně. A RCON enginu Source je TCP na stejném čísle portu, které hra používá přes UDP, takže je nelze oddělit jen podle čísla portu: pravidlo musí rozlišovat protokoly.

„Komu je otevřeno“ má tři užitečné hodnoty. Všem, u služby, kterou skutečně publikuješ. Konkrétní adrese nebo prefixu, u administrace. A jen loopback, což není pravidlo firewallu, ale rozhodnutí o vazbě v konfiguraci samotné služby, a pokud je k dispozici, je vždy lepší než pravidlo firewallu.

Zápis pomocí ufw#

ufw je nadstavba nad iptables, díky které má běžná sada pravidel čtyři příkazy. Na Debianu a Ubuntu bývá obvykle už nainstalovaný.

$ ufw default deny incoming$ ufw default allow outgoing$ ufw allow from 203.0.113.5 to any port 22 proto tcp comment 'ssh admin'$ ufw allow 25565/tcp comment 'minecraft java'$ ufw allow 2456:2457/udp comment 'valheim game and query'$ ufw enable

Pár poznámek k tomuto postupu:

• Pravidlo pro SSH přidej dřív, než firewall zapneš. Zapnutí politiky výchozího zákazu přes SSH bez pravidla pro SSH tě ze stroje vyzamkne a jediná cesta zpět vede přes konzoli v panelu poskytovatele.
• Rozsah portů potřebuje protokol. ufw allow 2456:2457/udp je platné, ufw allow 2456:2457 ne.
• Používej `comment`. Za půl roku je pravidlo, které neumíš vysvětlit, pravidlem, které z obavy necháš na místě. Komentář z toho udělá rozhodnutí.
• `ufw limit 22/tcp` povolí SSH, ale zpomalí adresu, která naváže víc než šest spojení za třicet sekund. Hodí se, pokud musíš SSH vystavit světu, čemuž by ses měl pokud možno vyhnout.
• IPv6 je samostatná sada pravidel a ufw ji spravuje, jen když je v /etc/default/ufw nastaveno IPV6=yes. Na moderních instalacích je to zapnuté ve výchozím stavu a přesto to stojí za kontrolu.

Pak si přečti, co jsi postavil, protože ten seznam je dokumentace:

$ ufw status numberedStatus: active     To                         Action      From     --                         ------      ----[ 1] 22/tcp                     ALLOW IN    203.0.113.5     # ssh admin[ 2] 25565/tcp                  ALLOW IN    Anywhere        # minecraft java[ 3] 2456:2457/udp              ALLOW IN    Anywhere        # valheim$ ufw delete 3

Zapni logování pomocí ufw logging low a zahozené pakety skončí v /var/log/ufw.log. Je to hlučné - internet skenuje každou adresu neustále - ale právě tak zjistíš, že se blokuje něco, co mělo fungovat. Průvodce ufw ten nástroj prochází pořádně a první hodina na novém VDS ho řadí do pořadí, které si žádá zbytek nastavení.

Stejná pravidla v nftables#

Pokud stavíš něco, co budeš udržovat roky, je nftables lepším základem. Jedna tabulka inet pokrývá IPv4 i IPv6 v jedné sadě pravidel, čímž zmizí celá kategorie chyb typu „na v4 funguje, na v6 se tiše zahazuje“.

#!/usr/sbin/nft -fflush rulesettable inet filter {  chain input {    type filter hook input priority filter; policy drop;    ct state established,related accept    ct state invalid drop    iif lo accept    ip protocol icmp icmp type { echo-request, destination-unreachable, time-exceeded } accept    ip6 nexthdr icmpv6 accept    tcp dport 22 ip saddr 203.0.113.5 accept    tcp dport { 80, 443 } accept    tcp dport 25565 accept    udp dport 2456-2457 accept  }  chain forward { type filter hook forward priority filter; policy drop; }  chain output  { type filter hook output  priority filter; policy accept; }}

Načti ji příkazem nft -f /etc/nftables.conf a zkontroluj pomocí nft list ruleset. Povol nftables.service, aby sada přežila restart, a otestuj ji z druhé relace dřív, než zavřeš tu, ve které pracuješ.

Docker a proč se tvá pravidla ignorují#

Tohle lidi překvapí natolik, že si to zaslouží vlastní oddíl. Kontejner s publikovaným portem je často dosažitelný z internetu, přestože ufw status ukazuje politiku výchozího zákazu a žádné pravidlo pro něj.

Důvodem je, že Docker zapisuje vlastní pravidla přímo do iptables, do tabulky nat a do řetězců, které se vyhodnocují dřív než ty, které spravuje ufw. Publikování portu pomocí -p 5432:5432 nastaví cílový NAT, který řetězec INPUT úplně obchází. Tvůj firewall není rozbitý, jen se ho nikdo neptá.

Východiska jsou tři a použít máš první:

1. Publikuj na loopback. -p 127.0.0.1:5432:5432 naváže publikovaný port jen na lokální rozhraní, takže je kontejner dostupný z hostitele a odnikud jinud. V souboru Compose je to "127.0.0.1:5432:5432".
2. Piš pravidla do řetězce `DOCKER-USER`, který Docker vyhodnocuje před svými vlastními a nepřepisuje ho. Funguje to a snadno se to pokazí, protože pakety už prošly NAT a adresy nejsou ty, které čekáš.
3. Port vůbec nepublikuj. Kontejnery ve stejné síti Dockeru se oslovují jménem na portu kontejneru. Pokud s databází mluví jen tvá aplikace, databáze žádný publikovaný port nepotřebuje.

Docker na VDS pokrývá zbytek nastavení a stejná úvaha platí pro každý kontejnerový runtime, který si spravuje síť sám.

Porty, které lidé nechávají otevřené, a jak je najít#

Tři z nich se objevují pořád dokola a všechny otevřel rozumný člověk z rozumného důvodu.

Databázový port otevřený kvůli zkoušce připojení z domova. Postgres na 5432 a MongoDB na 27017 se vystaví na deset minut kvůli dotazu z desktopového klienta a pak zůstanou vystavené. U Postgresu je firewall stejně jen polovina kontroly: listen_addresses v postgresql.conf rozhoduje, na která rozhraní se naváže, a pg_hba.conf rozhoduje, kdo se smí přihlásit a jak. Řádek jako host all all 0.0.0.0/0 md5 v pg_hba.conf jsou skutečné dveře a zavření firewallu při ponechání tohoto řádku je oprava, která vydrží přesně tak dlouho jako pravidlo firewallu. Bezpečnostní kontrolní seznam pro databáze je celý seznam a vzdálené připojení k PostgreSQL to dělá bezpečným způsobem.

Port RCON otevřený pro nástroj, který byl odinstalován před rokem. RCON vznikl v důvěřivější době: ve většině implementací putuje heslo sítí jen s minimální ochranou a kdokoli, kdo ho má, může dělat všechno, co konzole. Pokud máš konzoli v panelu, RCON vystavený vůbec nepotřebuješ - RCON bezpečně to obhajuje v plném rozsahu.

Administrátorské nebo ladicí rozhraní navázané na všechna rozhraní, protože to bylo výchozí. Webová administrace na 8080, endpoint metrik na 9090, vývojový server na 3000, profiler ponechaný běžet po vyšetřování. Hromadné skenery je najdou během hodin po otevření, ne dnů.

K jejich nalezení stačí dva příkazy. Přímo na stroji:

$ ss -ltnp$ ss -lunp

Cokoli navázané na 0.0.0.0 nebo [::] poslouchá na všech rozhraních. Cokoli na 127.0.0.1 je jen lokální a není to tvůj problém. Projdi seznam a každou položku nahlas obhaj.

Pak zkontroluj i zvenčí, protože to, čemu věří stroj, a to, co je dosažitelné z internetu, jsou dvě různé otázky:

$ nmap -Pn -p- --open node.example.com$ nmap -Pn -sU --top-ports 50 node.example.com

Skenuj jen vlastní servery. Sken UDP je pomalý a kvůli povaze protokolu méně spolehlivý než TCP, což je také důvod, proč se na služby UDP tak často zapomíná.

Dělej to čtvrtletně a po každém incidentu. Pokud neumíš říct, k čemu pravidlo nebo poslouchající socket slouží, odstraň ho a počkej, kdo si postěžuje - je to rychlejší a upřímnější audit než čtení dokumentace, kterou sis napsal sám.

Egress: pravidla, která nikdo nepíše#

Téměř každá sada pravidel povoluje veškerý odchozí provoz a u většiny serverů je to správné rozhodnutí. Je dobré vědět, co tím přijímáš.

Napadený proces - škodlivý mod, plugin z fóra, závislost se zadními vrátky - používá odchozí spojení pro vše, co následuje: stažení druhé fáze, připojení k botnetu, odeslání tvých dat jinam nebo rozesílání spamu. Příchozí strana tvého firewallu s tím nemá nic společného.

Dvě pravidla pro odchozí provoz jsou levná a na téměř každém serveru se vyplatí:

• Zablokuj odchozí TCP 25. Nic na herním ani aplikačním serveru legitimně neposílá poštu přímo. Díky tomuto pravidlu se z „náš stroj sloužil k rozesílání spamu a teď je naše adresa na blocklistu“ stane řádek v logu.
• Zablokuj odchozí spojení z kontejneru s databází, pokud nějaký provozuješ. Databáze nemá co navazovat spojení do internetu, a pokud začne, chceš to vědět.

Úplné povolování odchozího provozu podle seznamu - pojmenování každého cíle, kam server smí - je realistické pro zařízení a bolestivé pro herní server, kde se mody stahují z tuctu hostitelů, o kterých jsi nikdy neslyšel. Posuzuj to podle toho, co server dělá. Pokud se aktualizace modu rozbije, protože se nedostala na CDN, pravidla stála víc, než ušetřila - širší verzí tohoto kompromisu je udržování moddovaného serveru v čistotě.

Pokud je na něco z toho už pozdě, co dělat, když ti hacknou server má pořadí omezení škod: nejdřív izolovat, potom vyměnit přihlašovací údaje, potom obnovit a nakonec najít, kudy se útočník dostal dovnitř.

V panelu firewall není tvůj#

Pokud tvůj server běží ve spravovaném panelu, a ne na stroji, který vlastníš, nic z výše uvedeného o ufw a nftables se tě netýká, a to je většinou dobrá zpráva: ty části práce, kvůli kterým lidé přicházejí o servery, jsou už vyřešené a nejde je omylem upravit.

Co místo toho ovládáš:

• Které porty existují. Každý tarif uvádí své alokace a porty se přidávají a odebírají na záložce Network serveru, včetně query a RCON. Port, který není alokován, není dosažitelný, což je pravidlo firewallu vyjádřené seznamem, který přečteš jedním pohledem.
• Izolace. Jeden kontejner na server, s CPU jako tvrdým omezením na zakoupený podíl. Tví sousedé nejsou na tvém stroji v žádném smyslu, na kterém záleží.
• Konzole místo RCON. Konzole v panelu je stejná schopnost za účtem, který už chráníš pořádně, místo druhých přihlašovacích údajů na otevřeném portu.
• Zabezpečení účtu, které je teď skutečným perimetrem. Dvoufaktorové ověření TOTP s jednorázovými záložními kódy, hesla uložená jako hash bcrypt, captcha a limity přihlašování, seznam relací, ze kterých se můžeš odhlásit, a API klíče, které lze omezit podle adresy. Dvoufaktorové ověření na účtu v panelu je pět minut, které se vyplatí.
• Nejmenší nutná oprávnění pro lidi. Subuživatelé, role a týmy s podrobnými oprávněními - jen konzole, jen soubory, žádná fakturace - časově omezený přístup a protokol aktivity pro každý server. To je kontrola, na které záleží, jakmile má přístup víc než jedna osoba, a popisuje ji subuživatelé a nejmenší oprávnění.

Tajemství jsou druhá polovina perimetru a často nejslabší článek: heslo k databázi ve veřejném repozitáři zruší všechna výše uvedená pravidla. Proměnné prostředí a tajemství popisuje, jak je držet mimo místa, kam se lidé dívají nejdřív.

Pokud chceš plný firewall zpět, je to argument pro VDS, spolu se vším ostatním, co pak musíš udržovat sám - volba mezi VDS a herním panelem obě možnosti upřímně váží.

FAQ#

Potřebuji firewall, když můj server provozuje jen jednu hru?

Pokud jde o tvůj vlastní stroj, ano. Herní server málokdy běží sám: SSH, služby správce balíčků, monitorovací agent a cokoli, co sis minulý měsíc nainstaloval kvůli ladění, to všechno poslouchá. Výchozí zákaz zařídí, že seznam vystavených služeb odpovídá seznamu, který jsi zamýšlel.

Chrání mě firewall před DDoS útoky?

Ne. Zahozený paket už spotřeboval tvou šířku pásma, takže firewall hostitele nepomůže proti záplavě, která zahltí linku. Filtrování takového objemu provozu probíhá před strojem a i tam se dá odlišit jen zjevný objemový a reflexní provoz.

Mám změnit port SSH z 22?

Sníží to šum v lozích od automatických skenerů a není to zabezpečení. Skutečně záleží na ověřování jen klíčem s PasswordAuthentication no, omezení portu na adresy, které ovládáš, a fail2ban navrch. Přesun portu je volitelný a na tom, kdo se dostane dovnitř, nic nemění.

Proč se lidé dostanou ke kontejneru, i když ufw všechno zakazuje?

Protože Docker zapisuje vlastní pravidla iptables, která se vyhodnocují dřív než řetězce spravované pomocí ufw, takže publikovaný port tvou politiku obchází. Publikuj na 127.0.0.1 místo na všechna rozhraní, nebo port nepublikuj vůbec, pokud ho potřebuje jen jiný kontejner.

Jak často mám kontrolovat pravidla firewallu?

Čtvrtletně a po každém incidentu nebo migraci. Kontrola je krátká: vypiš pravidla, vypiš, co skutečně poslouchá, pomocí ss -ltnp, a smaž všechno, co neumíš obhájit jednou větou. Většina sad pravidel se pokaždé zmenší.