SSH- og VPN-indgangsregler: hvad tilladelseslisten egentlig styrer

Forbind én gang, før du ændrer en regel, og noter, om klienten hænger, eller om den afvises med det samme. Den ene forskel fortæller dig, hvilken beslutning der smed pakken, og sparer en time med at læse politikfiler. Resten af turen er kort: pakken krydser en hook, matcher en regel og når enten en lytter eller ej. En tilladelsesliste er blot bogholderi omkring de tre fakta.

Følg ét SSH-forsøg til input-hooken

En klient sender en SYN til værtens adresse på port 22, og kernen afgør, om pakken er til en lokal tjeneste. Er den det, kører input-stien, og regelsættet accepterer pakken eller kasserer den. Tavshed betyder, at SYN døde, før lytteren så den, mens et hurtigt afslag betyder, at noget svarede med et reset. Det er forskellige kendelser fra forskellige regler, og begge er legitime udfald.

Bekræft derefter lytteren, for ingen regel kan redde en tjeneste, der ikke er der. Kør ss -ltnp og kontrollér, at noget er bundet til den port og adressefamilie, du forventer, og læs så ssh -v på klienten for at se, hvor den stopper.

Videresendelse er en beslutning for sig

På en VPN-server er den mere interessante hook forward, fordi klienttrafik rutes gennem maskinen i stedet for at blive leveret til den. En vært, der kun kører sin egen VPN-klient, har brug for et langt mindre regelsæt end en, der videresender andres pakker. Blander man de to design på én maskine, får man regler, der ser rigtige ud og ikke lukker noget igennem.

Skriv den indre politik som sit eget spørgsmål: hvilke klientadresser må nå hvilke destinationer gennem tunnelen. Hold den administrative vej, fx SSH, på input-stien med sin egen kildebegrænsning. En eftergivende forward-regel, der blev tilføjet under test, er den klassiske fejl, der overlever testen, så gennemgå hele regelsættet efter en ændring i stedet for den linje, du redigerede. At åbne tunnel-lytteren er ikke tilladelse for hver tilsluttet klient til at administrere værten.

Drop og reject er handlinger, ikke politikker

En basiskædes politik accepterer eller dropper, og det er hele listen af valg, som nftables-referencen siger. Reject findes som en regelhandling med et valgt svar, og derfor fejler det at skrive den som politik på både nftables og iptables. I praksis giver et drop klienten ingen information, mens et reject giver den en fejl, den kan handle på.

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

Læs den skitse som formen på en beslutning i stedet for en fil, der skal indsættes, da adresseområderne er eksempler. Et eksplicit reject på SSH-porten får en uautoriseret klient til at fejle på et sekund i stedet for at vente et timeout ud, hvilket forkorter din egen fejlfinding. Tavshed afskrækker tilfældig scanning og fortæller en autoriseret bruger absolut intet. Vælg pr. tjeneste, og skriv hvorfor, for ellers ændrer den næste person det tilbage.

Behold den kontroltrafik, du faktisk har brug for

At blokere al ICMP er en populær standard, der bryder path-MTU-opdagelse, og symptomet er en forbindelse, der etableres og derefter går i stå på større pakker. Nabo-opdagelse på IPv6 afhænger af sine egne ICMPv6-typer, og kasserer man dem, brydes linket, før nogen TCP-regel bliver spurgt. Begge hører i tilladelseslisten som navngivne afhængigheder i stedet for som brede tilladelser. En politik, der lydløst bryder opdagelsen, er værre end en, der lukker lidt diagnostisk trafik ind.

Tillad tilstandene established og related for forbindelser, du selv startede, og lad den tilstandsfulde motor klare svarene. Bekræft derefter, at svarvejen ikke er blokeret længere ude, for en begrænsning, der kun gælder udgående trafik tidligere i kæden, giver samme timeout, som du var ved at give værten skylden for.

Bevis genopretning, før du pensionerer den gamle vej

Hold en konsolsession åben, anvend ændringen, og åbn en helt ny administrationsforbindelse fra en anden terminal. En eksisterende session beviser intet, for den kan overleve en regel, der blokerer hvert nyt login, hvilket gør den til det mest overbevisende falske positiv i firewall-arbejde. Hvis et overvågningssystem tjekker værten, tilføj dets kildeadresse før ændringen i stedet for efter den første alarm. Test derefter én stor og én lille pakke for at bevise, at opdagelsen stadig virker.

For en VPN-tjeneste gentages det fra en klient, der aldrig har været forbundet, for en genoptaget session kan genbruge tilstand, som en frisk skal forhandle. Skriv det præcise regelsæt ned, der bestod, med en kontrolsum eller en kopi, så en senere redigering kan sammenlignes i stedet for gættes. Koordinér med den, der ejer regelrækkefølgen, for en tidligere regel vinder lydløst over den, du tilføjede.