Uus UFW reegel, vana ühendus: kehtestatud olek võidab

Keeldumisreegli lisamine ja avatud allalaadimise jätkumine ei ole UFW viga. Lisatud reegel asub pärast reegleid, mis on selle voo juba vastu võtnud, ja varem loodud ühendus jätkab nendega sobimist. Parandus tähendab õigesse kohta lisamist ja arusaamist, mida varasemad reeglid lubavad. Selle muudatuse kitsas versioon järgneb.

Otsustab järjekord, mitte reegli olemasolu

UFW on liides, mis kirjutab netfilteri reegleid etappide kaupa: raamistiku osa, mis jookseb enne kasutaja reegleid, seejärel kasutaja reeglid ise ja lõpuks osa, mis jookseb pärast neid. Tavalised eelreeglid lubavad kehtestatud ja seotud ühenduste liiklust ning neid reegleid hinnatakse enne kõike, mida lisate tavalise allow või deny abil. UFW käsureaviide dokumenteerib lisamise süntaksi ja numereeritud olekuvaate, millest see muudatus sõltub.

See järjekord seletab üllatust. Teie uus reegel on tõeline ja asub õiges tabelis, kuid see ei ole esimene otsus, millega pakett kokku puutub. Ühendus, mida juba jälgitakse kehtestatuna, ei jõua kunagi selleni.

Kasutage selle töö jaoks route reegleid, sest paketti edastatakse lüüsi kaudu, mitte ei adresseerita lüüsi enda teenustele. Sisendreegel filtreeriks vale liiklust ja näiks, nagu ei teeks midagi.

Sisestage laia loa kohale

Eelvaadake lisamist enne selle rakendamist ja kinnitage, et reegel ei ole juba mujal loendis. Identse poliitika dubleerimine muudab hilisema eemaldamise mitmetähenduslikuks ja inimene, kes eemaldab vale koopia, ei märka seda nädalaid.

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

Kui eelvaade näitab täpselt ühte reeglit oodatud kohas, rakendage sama käsk ilma dry-run liputa. Positsioon 1 asetab selle laiemate kasutajalubade kohale, mitte varem käsitletud raamistikureeglite kohale. Kinnitage, et liidese nimi vastab selle lüüsi tunneliseadmele, sest liidesega seotud reegel, mida enam ei ole, seisab loendis ja näeb korrektne välja, samal ajal kui see ei sobi mitte millegagi. Muutke seadme viidet enne rakendamist, mitte pärast testi ebaõnnestumist.

Selles reeglis ei ole sihtporti, seega keelab see kõik TCP-pordid sellel aadressil, mitte ainult HTTPS-i. Kui kavatsus on üks teenus, nimetage port; poliitikast laiem reegel on tulevane juhtum, mis ootab oma esimest lugejat.

Piirake allikas ühe aadressiga ainult siis, kui see aadress on seotud kavandatud identiteediga. Dünaamilise määramisega VPN-i pool võib homme anda sama aadressi teisele kliendile ja keeld järgiks pigem aadressi kui inimest.

Kehtestatud vood jäävad uue reegli üle elama

Ühenduste jälgimine on põhjus, miks olemasolev seanss jätkub. Kui voog on registreeritud kehtestatuna, võtavad eelreeglid selle paketid vastu enne, kui teie keeldu üldse vaadatakse, ja ülekanne lõpeb nii, nagu poleks midagi muutunud. Seetõttu ei ütle avatud ühendust taaskasutava brauseriga testimine teile uue poliitika kohta midagi. Keeld võib paari minuti pärast juurutamist tunduda kasutu ja olla täiesti tõhus järgmisele kasutajale, kes ühendub.

Kui nõue hõlmab reaalse liikluse katkestamist, ei suuda see kasutajareegli muudatus seda pakkuda. Jälgitud oleku tühistamine on eraldi toiming oma mõjuraadiusega ja see kuulub tulemüüri omanikule, mitte sellele, kes reegli lisas. Kõigi ühenduste tühjendamine lüüsil, et üks seanss kaoks, on selline parandus, mis tekitab teise juhtumi.

Pidage meeles ka piire. See reegel ei ütle midagi ICMP, UDP ega IPv6 kohta, seega edukas ping ei ole tõestus, et keeld ebaõnnestus. Üks IPv4 aadress ei ole samuti veebisait: nimi võib lahenduda mitmeks aadressiks ja kaetud on ainult see, mille nimetasite.

Testige värske vooga

Lugege numereeritud kasutajareegleid ja tegelikku töötlemata vaadet, seejärel avage valitud kliendist uus ühendus:

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

Töötlemata vaade on oluline, sest status jätab välja käsitsi kirjutatud raamistikureeglid, mistõttu võib järjekord paista teistsugune kui see, mida tuum rakendab. Võrrelge mõlemat, enne kui järeldate, et reegel on vales kohas.

Seejärel kontrollige kahte kontrolli, mis tõestavad, et reegel on kitsas, mitte lai: sama kliendi lubatud sihtkoht töötab endiselt ja teine klient jõuab endiselt keelatud sihtkohta, kui tema poliitika seda lubab. Keeld, mis rikub mõlemat testi, on poliitika muudatus, mitte sihitud meede.

Kui test on läbi, eemaldage ainult teie lisatud reegel, korrates seda täpselt. Kui poliitika on püsiv, andke see üle tulemüüri omanikule koos kliendi identiteedi, sihtkoha omaniku ja ülevaatamise kuupäevaga, et ümber määratud tunneliaadress ei jätaks maha aegunud keeldu.