Reguli de intrare SSH și VPN: ce controlează de fapt lista de permisiuni

Conectați-vă o dată înainte de a schimba o regulă și notați dacă clientul se blochează sau este refuzat imediat. Această singură diferență vă spune ce decizie a aruncat pachetul și economisește o oră de citit fișiere de politică. Restul drumului este scurt: pachetul traversează un cârlig, se potrivește cu o regulă și ajunge la un ascultător sau nu. O listă de permisiuni este doar contabilitate în jurul acestor trei fapte.

Urmăriți o încercare SSH până la cârligul de intrare

Un client trimite un SYN la adresa gazdei pe portul 22, iar nucleul decide dacă acel pachet este pentru un serviciu local. Dacă da, calea de intrare rulează și setul de reguli acceptă pachetul sau îl aruncă. Tăcerea înseamnă că SYN a murit înainte ca ascultătorul să-l vadă, în timp ce un refuz rapid înseamnă că ceva a răspuns cu o resetare. Sunt verdicte diferite din reguli diferite, iar ambele sunt rezultate legitime.

Confirmați apoi ascultătorul, pentru că nicio regulă nu salvează un serviciu care nu există. Rulați ss -ltnp și verificați dacă ceva este legat de portul și familia de adrese pe care o așteptați, apoi citiți ssh -v pe client pentru a vedea unde se oprește.

Redirecționarea este o decizie separată

Pe un server VPN cârligul mai interesant este forward, pentru că traficul clientului este rutat prin mașină în loc să îi fie livrat. O gazdă care rulează doar propriul client VPN are nevoie de un set de reguli mult mai mic decât una care redirecționează pachetele altor persoane. Amestecarea celor două modele pe o singură mașină produce reguli care par corecte și nu lasă nimic să treacă.

Scrieți politica internă ca o întrebare separată: ce adrese de client pot ajunge la ce destinații prin tunel. Păstrați calea administrativă, cum ar fi SSH, pe calea de intrare cu propria restricție de sursă. O regulă forward permisivă adăugată în timpul testării este defectul clasic care supraviețuiește testului, așa că după o schimbare revizuiți întregul set de reguli, nu linia pe care ați editat-o. Deschiderea ascultătorului tunelului nu este permisiunea ca fiecare client conectat să administreze gazda.

Aruncarea și respingerea sunt acțiuni, nu politici

Politica unui lanț de bază acceptă sau aruncă, și aceasta este întreaga listă de opțiuni, după cum spune referința nftables. Respingerea există ca acțiune de regulă cu un răspuns ales, de aceea scrierea ei ca politică eșuează atât pe nftables, cât și pe iptables. În practică, un drop nu îi dă clientului nicio informație, în timp ce un reject îi dă o eroare pe care poate acționa.

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

Citiți acea schiță ca forma unei decizii și nu ca un fișier de lipit, pentru că intervalele de adrese sunt exemple. Un reject explicit pe portul SSH face un client neautorizat să eșueze într-o secundă în loc să aștepte un timp limită, ceea ce scurtează propria dumneavoastră depanare. Tăcerea descurajează scanarea întâmplătoare și nu îi spune absolut nimic unui utilizator autorizat. Alegeți pentru fiecare serviciu și notați de ce, altfel următoarea persoană va schimba totul la loc.

Păstrați traficul de control de care aveți cu adevărat nevoie

Blocarea întregului ICMP este o valoare implicită populară care strică descoperirea MTU a căii, iar simptomul este o conexiune care se stabilește și apoi se blochează la pachete mai mari. Descoperirea vecinilor pe IPv6 depinde de propriile tipuri ICMPv6, iar aruncarea lor rupe legătura înainte de a fi consultată vreo regulă TCP. Ambele aparțin listei de permisiuni ca dependențe numite și nu ca permisiuni generale. O politică ce strică descoperirea în tăcere este mai rea decât una care admite puțin trafic de diagnostic.

Permiteți stările established și related pentru conexiunile pe care le-ați inițiat, și lăsați motorul cu stare să se ocupe de răspunsuri. Apoi confirmați că calea de răspuns nu este blocată mai departe, pentru că o restricție doar pentru traficul de ieșire mai sus produce același timp limită pe care erați pe punctul de a-l pune în sarcina gazdei.

Dovediți recuperarea înainte de a renunța la calea veche

Țineți deschisă o sesiune de consolă, aplicați schimbarea și deschideți o conexiune de administrare complet nouă dintr-un alt terminal. O sesiune existentă nu dovedește nimic, pentru că poate supraviețui unei reguli care blochează fiecare autentificare nouă, ceea ce o face cel mai convingător fals pozitiv din munca cu firewall-uri. Dacă un sistem de monitorizare verifică gazda, adăugați adresa lui sursă înainte de schimbare și nu după prima alertă. Apoi testați un pachet mare și unul mic pentru a dovedi că descoperirea încă funcționează.

Pentru un serviciu VPN, repetați de la un client care nu s-a conectat niciodată, pentru că o sesiune reluată poate reutiliza o stare pe care una nouă trebuie să o negocieze. Notați setul exact de reguli care a trecut, cu o sumă de control sau o copie, ca o modificare ulterioară să poată fi comparată în loc de ghicită. Coordonați cu cel care deține ordinea regulilor, pentru că o regulă anterioară învinge în tăcere regula pe care ați adăugat-o.