Vstupní pravidla pro SSH a VPN: co seznam povolených skutečně řídí

Připojte se jednou, než změníte pravidlo, a všimněte si, zda klient visí, nebo je okamžitě odmítnut. Ten jediný rozdíl vám řekne, které rozhodnutí paket zahodilo, a ušetří hodinu čtení souborů s politikou. Zbytek cesty je krátký: paket projde hákem, shoduje se s pravidlem a buď dorazí k posluchači, nebo ne. Seznam povolených je jen evidence kolem těchto tří faktů.

Projděte jeden pokus o SSH až ke vstupnímu háku

Klient pošle SYN na adresu hostitele na port 22 a jádro rozhodne, zda je tento paket pro místní službu. Pokud ano, proběhne vstupní cesta a sada pravidel paket buď přijme, nebo zahodí. Ticho znamená, že SYN zemřel dřív, než ho posluchač uviděl, zatímco rychlé odmítnutí znamená, že něco odpovědělo resetem. To jsou různé verdikty z různých pravidel a oba jsou legitimní výsledky.

Potom ověřte posluchače, protože žádné pravidlo nezachrání službu, která tam není. Spusťte ss -ltnp a zkontrolujte, zda je něco vázáno na port a rodinu adres, kterou očekáváte, a pak si na klientovi přečtěte ssh -v, abyste viděli, kde se zastaví.

Přeposílání je samostatné rozhodnutí

Na serveru VPN je zajímavější hák forward, protože klientský provoz se směruje přes stroj, místo aby se mu doručoval. Hostitel, který provozuje jen vlastního klienta VPN, potřebuje mnohem menší sadu pravidel než ten, který přeposílá pakety jiných lidí. Smíchání obou návrhů na jednom stroji vytváří pravidla, která vypadají správně a nic nepropustí.

Napište vnitřní politiku jako samostatnou otázku: které klientské adresy smějí dosáhnout kterých cílů přes tunel. Administrativní cestu, například SSH, držte na vstupní cestě s vlastním omezením zdroje. Povolující pravidlo forward přidané během testování je klasická vada, která přežije test, proto po změně projděte celou sadu pravidel, ne řádek, který jste upravili. Otevření posluchače tunelu není svolení, aby každý připojený klient spravoval hostitele.

Zahazování a odmítání jsou akce, ne politiky

Politika základního řetězce přijímá nebo zahazuje a to je celý seznam voleb, jak uvádí referenční příručka nftables. Odmítnutí existuje jako akce pravidla se zvolenou odpovědí, a proto zápis jako politika selhává jak na nftables, tak na iptables. V praxi zahození nedá klientovi žádnou informaci, zatímco odmítnutí mu dá chybu, se kterou může pracovat.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Čtěte ten náčrt jako tvar rozhodnutí, ne jako soubor ke vložení, protože rozsahy adres jsou příklady. Explicitní odmítnutí na portu SSH způsobí, že neoprávněný klient selže za sekundu místo čekání na timeout, což zkracuje vaše vlastní ladění. Ticho odrazuje náhodné skenování a oprávněnému uživateli neřekne vůbec nic. Vybírejte pro každou službu a zapište proč, jinak to příští člověk zase vrátí.

Ponechte si řídící provoz, který skutečně potřebujete

Blokování všeho ICMP je oblíbené výchozí nastavení, které rozbíjí objevování MTU cesty, a příznakem je spojení, které se naváže a pak se zasekne na větších paketech. Objevování sousedů na IPv6 závisí na vlastních typech ICMPv6 a jejich zahození rozbije spojení dřív, než se přečte jakékoli pravidlo TCP. Obojí patří do seznamu povolených jako pojmenované závislosti, ne jako plošná povolení. Politika, která tiše rozbíjí objevování, je horší než ta, která pustí trochu diagnostického provozu.

Povolte stav established a related pro spojení, která jste zahájili, a nechte stavový engine vyřídit odpovědi. Pak ověřte, že cesta odpovědi není dál blokovaná, protože omezení jen na odchozí provoz výš proti proudu vytváří stejný timeout, který jste chtěli svést na hostitele.

Dokažte obnovu, než starou cestu vyřadíte

Nechte otevřenou konzolovou relaci, použijte změnu a otevřete zcela nové řídící spojení z jiného terminálu. Existující relace nic nedokazuje, protože může přežít pravidlo, které blokuje každé nové přihlášení, což z ní dělá nejpřesvědčivější falešně pozitivní výsledek při práci s firewallem. Pokud hostitele kontroluje monitorovací systém, přidejte jeho zdrojovou adresu před změnou, ne po prvním upozornění. Pak otestujte jeden velký a jeden malý paket, abyste dokázali, že objevování stále funguje.

U služby VPN to zopakujte z klienta, který se nikdy nepřipojil, protože obnovená relace může znovu použít stav, který nová musí vyjednat. Zapište přesnou sadu pravidel, která prošla, s kontrolním součtem nebo kopií, aby se pozdější úprava dala porovnat, ne hádat. Koordinujte se s tím, kdo vlastní pořadí pravidel, protože dřívější pravidlo tiše vyhraje nad tím, které jste přidali.