Pravidlá pre vstup SSH a VPN: čo skutočne riadi zoznam povolených

Pripojte sa raz predtým, než zmeníte pravidlo, a všimnite si, či klient visí alebo je hneď odmietnutý. Ten jediný rozdiel vám povie, ktoré rozhodnutie paket zahodilo, a ušetrí hodinu čítania súborov s politikou. Zvyšok cesty je krátky: paket prejde hákom, zhoduje sa s pravidlom a buď dorazí k poslucháčovi, alebo nie. Zoznam povolených je len evidencia okolo týchto troch faktov.

Prejdite jeden pokus o SSH až k vstupnému háku

Klient pošle SYN na adresu hostiteľa na porte 22 a jadro rozhodne, či je tento paket pre miestnu službu. Ak áno, prebehne vstupná cesta a sada pravidiel paket buď prijme, alebo zahodí. Ticho znamená, že SYN zomrel skôr, než ho poslucháč uvidel, zatiaľ čo rýchle odmietnutie znamená, že niečo odpovedalo resetom. To sú rôzne verdikty z rôznych pravidiel a oba sú legitímne výsledky.

Potom overte poslucháča, pretože žiadne pravidlo nezachráni službu, ktorá tam nie je. Spustite ss -ltnp a skontrolujte, či je niečo viazané na port a rodinu adries, ktorú očakávate, a potom si na klientovi prečítajte ssh -v, aby ste videli, kde sa zastaví.

Preposielanie je samostatné rozhodnutie

Na serveri VPN je zaujímavejší hák forward, pretože prevádzka klienta sa smeruje cez stroj namiesto toho, aby mu bola doručená. Hostiteľ, ktorý prevádzkuje len vlastného klienta VPN, potrebuje oveľa menšiu sadu pravidiel ako ten, ktorý preposiela pakety iných ľudí. Miešanie oboch návrhov na jednom stroji vytvára pravidlá, ktoré vyzerajú správne a nič neprepúšťajú.

Napíšte vnútornú politiku ako samostatnú otázku: ktoré klientske adresy smú dosiahnuť ktoré ciele cez tunel. Administratívnu cestu, napríklad SSH, držte na vstupnej ceste s vlastným obmedzením zdroja. Povoľujúce pravidlo forward pridané počas testovania je klasická chyba, ktorá prežije test, preto po zmene prejdite celú sadu pravidiel, nie riadok, ktorý ste upravili. Otvorenie poslucháča tunela nie je povolenie, aby každý pripojený klient spravoval hostiteľa.

Zahadzovanie a odmietanie sú akcie, nie politiky

Politika základnej reťaze prijíma alebo zahadzuje a to je celý zoznam volieb, ako uvádza referenčná príručka nftables. Odmietnutie existuje ako akcia pravidla so zvolenou odpoveďou, a preto zápis ako politika zlyháva na nftables aj na iptables. V praxi zahodenie nedá klientovi žiadnu informáciu, zatiaľ čo odmietnutie mu dá chybu, s ktorou môže pracovať.

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
    }
}

Čítajte ten náčrt ako tvar rozhodnutia, nie ako súbor na vloženie, pretože rozsahy adries sú príklady. Explicitné odmietnutie na porte SSH spôsobí, že neoprávnený klient zlyhá za sekundu namiesto čakania na časový limit, čo skracuje vaše vlastné ladenie. Ticho odrádza od náhodného skenovania a oprávnenému používateľovi nepovie vôbec nič. Vyberajte pre každú službu a zapíšte prečo, inak to nabudúce niekto vráti späť.

Ponechajte si riadiacu prevádzku, ktorú skutočne potrebujete

Blokovanie celého ICMP je obľúbené predvolené nastavenie, ktoré ničí objavovanie MTU cesty, a príznakom je spojenie, ktoré sa nadviaže a potom sa zasekne na väčších paketoch. Objavovanie susedov na IPv6 závisí od vlastných typov ICMPv6 a ich zahodenie preruší spojenie skôr, než sa prečíta akékoľvek pravidlo TCP. Oboje patrí do zoznamu povolených ako pomenované závislosti, nie ako plošné povolenia. Politika, ktorá potichu ničí objavovanie, je horšia ako tá, ktorá pustí trochu diagnostickej prevádzky.

Povoľte stavy established a related pre spojenia, ktoré ste začali sami, a nechajte stavový engine vybaviť odpovede. Potom overte, že cesta odpovede nie je ďalej blokovaná, pretože obmedzenie len na odchádzajúcu prevádzku vyššie vytvára rovnaký časový limit, ktorý ste chceli zvaliť na hostiteľa.

Dokážte obnovu, než starú cestu opustíte

Nechajte otvorenú konzolovú reláciu, aplikujte zmenu a otvorte úplne nové riadiace spojenie z iného terminálu. Existujúca relácia nič nedokazuje, pretože môže prežiť pravidlo, ktoré blokuje každé nové prihlásenie, čo z nej robí najpresvedčivejší falošný pozitívny výsledok pri práci s firewallom. Ak hostiteľa kontroluje monitorovací systém, pridajte jeho zdrojovú adresu pred zmenou, nie po prvom upozornení. Potom otestujte jeden veľký a jeden malý paket, aby ste dokázali, že objavovanie stále funguje.

Pri službe VPN to zopakujte z klienta, ktorý sa nikdy nepripojil, pretože obnovená relácia môže znova použiť stav, ktorý nová musí vyjednať. Zapíšte presnú sadu pravidiel, ktorá prešla, s kontrolným súčtom alebo kópiou, aby sa neskoršia úprava dala porovnať a nie hádať. Koordinujte sa s tým, kto vlastní poradie pravidiel, pretože skoršie pravidlo potichu vyhrá nad tým, ktoré ste pridali.