Linux firewall

Linux firewall: jeden systém, čtyři rozhraní

Nejčastější nedorozumění v celé téhle oblasti zní: „mám vypnout iptables a zapnout ufw?" Otázka nedává smysl, protože to nejsou konkurenční firewally.

Mentální model

V jádře Linuxu je jediný firewall a jmenuje se netfilter. Ten skutečně zahazuje a propouští pakety. Nikdy s ním nemluvíš přímo — mluvíš s ním přes některý z nástrojů:

flowchart TD
    A[iptables] --> N
    B[nftables] --> N
    C[ufw] --> B
    D[firewalld] --> B
    N[netfilter v jádře<br/>tady se to skutečně děje]

Loading

Z toho plyne několik věcí, které řeší většinu zmatků:

Nemůžeš mít „zapnuté dva firewally". Můžeš mít dva nástroje, které zapisují do stejného místa a nevědí o sobě. To je horší.

ufw a firewalld jsou nadstavby. Nedělají nic, co by neuměl nftables — jen ti dávají příjemnější příkazy. Pod kapotou generují stejná pravidla.

iptables už na moderních distribucích většinou není iptables. Na Debianu 11+, Ubuntu 22.04+ a všem novějším je iptables ve skutečnosti iptables-nft, tedy překladová vrstva zapisující do nftables. Příkazy fungují, ale nft list ruleset ti ukáže pravdu.

Pravidla, která nevidíš, pořád platí. ufw status ti ukáže jen to, co zapsalo ufw. Když ti Docker přidá vlastní pravidla, ufw o nich mlčí. Viz Docker a firewall.

Co použít

Situace	Doporučení
Jednoduchý server, pár portů	ufw
Potřebuješ NAT, forwarding, složitější logiku	nftables
Zděděná konfigurace, staré návody	iptables
Red Hat, Fedora, Rocky	firewalld
Docker v hostiteli	vždycky navíc DOCKER-USER, viz Docker a firewall

Když začínáš dnes na čistém stroji: ufw pro jednoduché věci, nftables když ufw nestačí. iptables se uč jen proto, abys rozuměl existujícím konfiguracím a návodům na internetu — nových věcí v něm nepiš.

Kudy paket letí

Tohle je společné všem nástrojům a je to jediná věc, kterou musíš mít v hlavě. Netfilter má body, ve kterých může do paketu zasáhnout, a záleží na tom, jestli paket míří na tenhle stroj, nebo skrz něj.

flowchart LR
    IN[příchozí paket] --> PRE[PREROUTING<br/>DNAT]
    PRE --> R{je to pro mě?}
    R -->|ano| INP[INPUT] --> L[lokální proces]
    R -->|ne| FWD[FORWARD] --> POST
    L --> OUT[OUTPUT] --> POST[POSTROUTING<br/>SNAT/masquerade]
    POST --> EXT[ven]

Loading

Praktické důsledky, kvůli kterým se ta pravidla nejčastěji píšou špatně:

INPUT je provoz na tenhle stroj. Sem patří „povol SSH", „povol web".

FORWARD je provoz skrz tenhle stroj. Sem patří všechno, co se týká routeru, VPN a kontejnerů. Když píšeš pravidlo do INPUT a ono „nefunguje", v devíti z deseti případů měl paket jít přes FORWARD.

PREROUTING je před rozhodnutím o směrování. Sem patří DNAT, tedy port forwarding.

POSTROUTING je těsně před odesláním. Sem patří SNAT a masquerade, tedy NAT ven.

Souvislost s tím, co se děje na drátě, je v cestě paketu.

Stavovost

Netfilter je stavový — sleduje otevřená spojení. Proto začíná skoro každá rozumná konfigurace tímhle:

povol vše ve stavu ESTABLISHED,RELATED
zahoď vše ve stavu INVALID

a teprve pak řešíš nová spojení. Bez toho bys musel psát pravidla pro odpovědi, což nikdo nedělá.

Než začneš experimentovat

Zamkneš se. Ne možná, určitě. Když ladíš firewall přes SSH, dřív nebo později si zahodíš vlastní spojení.

Pojistka, která tě zachrání — naplánuje vypnutí firewallu za deset minut:

echo "nft flush ruleset" | at now + 10 minutes

Když se odřízneš, počkáš deset minut a jsi zpátky. Když je všechno v pořádku, úlohu zrušíš (atq a atrm).

Na Proxmoxu nebo VM máš konzoli, takže je to méně dramatické. Na vzdáleném VPS bez konzole je tohle rozdíl mezi nepříjemností a reinstalací.

Vždycky si zálohuj současný stav:

nft list ruleset > /root/firewall-zaloha.nft
iptables-save > /root/iptables-zaloha.rules