Uusi UFW-sääntö, vanha yhteys: vakiintunut tila voittaa

Kieltosäännön lisääminen ja avoimen latauksen jatkuminen ei ole UFW-virhe. Lisäämäsi sääntö on sääntöjen jälkeen, jotka ovat jo hyväksyneet virtauksen, ja aiemmin muodostettu yhteys vastaa edelleen niitä. Korjaus tarkoittaa lisäämistä oikeaan kohtaan ja ymmärtämistä, mitä aiemmat säännöt lupaavat. Tämän muutoksen kapea versio seuraa.

Järjestys ratkaisee, ei säännön olemassaolo

UFW on käyttöliittymä, joka kirjoittaa netfilter-säännöt vaiheittain: kehysosio, joka ajetaan ennen käyttäjän sääntöjä, sitten käyttäjän säännöt itse ja lopuksi osio, joka ajetaan niiden jälkeen. Vakio-alkusäännöt hyväksyvät vakiintuneiden ja niihin liittyvien yhteyksien liikenteen, ja ne säännöt arvioidaan ennen mitään, mitä lisäät tavallisella allow- tai deny-komennolla. UFW-komentoviite dokumentoi lisäysyntaksin ja numeroidun tilanäkymän, josta tämä muutos riippuu.

Tuo järjestys selittää yllätyksen. Uusi sääntösi on todellinen ja se on oikeassa taulukossa, mutta se ei ole ensimmäinen päätös, jonka paketti kohtaa. Yhteys, jota on jo seurattu vakiintuneena, ei koskaan saavuta sitä.

Käytä tähän työhön route-sääntöjä, koska paketti välitetään yhdyskäytävän kautta eikä sitä osoiteta yhdyskäytävän omiin palveluihin. Syöttösääntö suodattaisi väärää liikennettä ja näyttäisi siltä, ettei tee mitään.

Lisää laajan luvan yläpuolelle

Esikatsele lisäys ennen sen soveltamista ja varmista, ettei sääntö ole jo muualla luettelossa. Saman käytännön kopioiminen tekee myöhemmästä poistosta monitulkintaisen, eikä väärän kopion poistaja huomaa sitä viikkoihin.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Jos esikatselu näyttää täsmälleen yhden säännön odottamassasi kohdassa, sovella sama komento ilman dry-run-lippua. Sija 1 asettaa sen laajempien käyttäjälupien yläpuolelle, ei aiemmin käsiteltyjen kehyssääntöjen yläpuolelle. Varmista, että liittymän nimi vastaa tämän yhdyskäytävän tunnelilaitetta, sillä sääntö, joka on rajattu liittymään jota ei enää ole, seisoo luettelossa ja näyttää oikealta osuessaan kuitenkin tyhjään. Nimeä laiteviittaus uudelleen ennen soveltamista, älä sen jälkeen kun testi epäonnistuu.

Tuossa säännössä ei ole kohdeporttia, joten se kieltää jokaisen TCP-portin tuossa osoitteessa eikä vain HTTPS:ää. Jos tarkoitus on yksi palvelu, nimeä portti; käytäntöä laajempi sääntö on tuleva tapaus, joka odottaa ensimmäistä lukijaansa.

Rajoita lähde yhteen osoitteeseen vain, jos se osoite on sidottu aiottuun identiteettiin. Dynaamisesti jakava VPN-allas voi antaa saman osoitteen toiselle asiakkaalle huomenna, ja kielto seuraisi osoitetta eikä henkilöä.

Vakiintuneet virtaukset selviävät uudesta säännöstä

Yhteyksien seuranta on syy siihen, että nykyinen istunto jatkuu. Kun virtaus on kirjattu vakiintuneeksi, alkusäännöt hyväksyvät sen paketit ennen kuin kieltoasi edes katsotaan, ja siirto päättyy kuin mitään ei olisi muuttunut. Siksi testaaminen selaimella, joka käyttää avointa yhteyttä uudelleen, ei kerro sinulle mitään uudesta käytännöstä. Kielto voi näyttää hyödyttömältä minuutteja käyttöönoton jälkeen ja olla täysin tehokas seuraavalle käyttäjälle, joka yhdistää.

Jos vaatimus sisältää live-liikenteen katkaisemisen, tämä käyttäjäsäännön muutos ei pysty siihen. Seuratun tilan peruuttaminen on erillinen toimi, jolla on oma vaikutusalueensa, ja se kuuluu palomuurin omistajalle eikä sille, joka säännön lisäsi. Kaikkien yhteyksien tyhjentäminen yhdyskäytävällä yhden istunnon katoamiseksi on sellainen korjaus, joka synnyttää toisen tapauksen.

Muista myös rajat. Tämä sääntö ei kerro mitään ICMP:stä, UDP:stä tai IPv6:sta, joten onnistunut ping ei ole todiste siitä, että kielto epäonnistui. Yksi IPv4-osoite ei myöskään ole verkkosivusto: nimi voi ratketa useaksi osoitteeksi, ja vain nimeämäsi on katettu.

Testaa tuoreella virtauksella

Lue numeroidut käyttäjäsäännöt ja tehokas raakanäkymä ja avaa sitten uusi yhteys valitusta asiakkaasta:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Raakanäkymä on tärkeä, koska status jättää pois käsin kirjoitetut kehyssäännöt, joten se voi saada järjestyksen näyttämään erilaiselta kuin mitä ydin pakottaa. Vertaa molempia ennen kuin päättelet, että sääntö on väärässä paikassa.

Tarkista sitten kaksi kontrollia, jotka todistavat säännön olevan kapea eikä laaja: saman asiakkaan sallittu kohde toimii edelleen, ja toinen asiakas saavuttaa yhä kielletyn kohteen, jos sen käytäntö sallii sen. Kielto, joka rikkoo molemmat testit, on käytännön muutos eikä kohdennettu toimi.

Kun testi on ohi, poista vain lisäämäsi sääntö toistamalla se täsmälleen. Jos käytäntö on pysyvä, luovuta se palomuurin omistajalle asiakkaan identiteetin, kohteen omistajan ja tarkistuspäivän kanssa, jotta uudelleen osoitettu tunneliosoite ei jätä vanhentunutta kieltoa taakseen.