Ei tun0:ta? Sovita purettu IPsec nftablesissa meta ipsec -ilmaisulla

Odotat tunneliliitäntää, etsit sitä, eikä palomuurissa ole mitään sovitettavaa. Se on käytäntöpohjaisen yhdyskäytävän tapauksessa normaalia: salattu vaihto saapuu fyysiselle liitännälle, ja salauksesta purettu sisäinen paketti, joka välitetään eteenpäin, havaitaan myös saapuvaksi samalle liitännälle. tun0:ta ei ole, koska mikään ei luonut sellaista.

Sisäinen pyyntö on edelleen oma paketti omine lähteineen, kohteineen ja palveluineen, ja ydin tietää, mistä turva-assosiaatiosta se tuli. Juuri tätä tietoa palomuurisääntö voi sovittaa.

Kaksi pakettia, yksi liitäntä

Kuvittele saapuva suunta. ESP- tai UDP-kapseloitu paketti saapuu, ydin löytää vastaavan käytännön, purkaa salauksen ja antaa selkeän paketin välityspolulle. Sääntö, joka katsoo vain liitännän nimeä, ei voi erottaa sitä pakettia mistään muusta samalla johdolla saapuvasta liikenteestä.

Sen erottaa pakettiin liitetty saapuvan turvapolun konteksti. nftables esittää sen muodossa meta ipsec exists, joka on tosi, kun paketti saapui IPsec-turvapolkua pitkin. Yhdistä se asiakaspooliin, kohteeseen ja palveluun, niin säännöstä tulee riittävän täsmällinen ollakseen turvallinen.

Kontekstin pois jättäminen on tavallinen virhe, ja se on turvallisuusvirhe eikä kosmeettinen. Sääntö, joka hyväksyy kaiken asiakaspoolista tulevan, hyväksyy yhtä mielellään paikallisverkosta väärennetyn paketin, koska lähdeosoite ei itsessään todista mitään. Turvapolun konteksti on halvin tapa tehdä lähteestä merkityksellinen. Kirjoita sääntö sen kanssa alusta asti sen sijaan, että lisäisit sen auditoinnin jälkeen.

Kirjoita välityssääntö

Oletetaan todennettu IPv4-etäkäyttöpalvelu, jonka asiakkaat ovat osoitteessa 10.90.0.0/24, ja yksi hyväksytty kohde osoitteessa 203.0.113.40. Sääntökatkelma tälle virralle näyttää tältä.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Osoitteet ja liitäntä ovat korvattavia esimerkkejä. Sijoita tarkistettu vastine välityskäytäntöön ennen sääntöä, joka muuten hylkäisi virran, äläkä tyhjennä olemassa olevaa sääntöjoukkoa sen asentamiseksi; yhdyskäytävä ei ole puhdashuonekoe.

Termi oifname kannattaa pitää. Se dokumentoi lähtöpäätöksen ja estää sääntöä osumasta suunnassa, jota et tarkoittanut, millä on merkitystä yhdyskäytävässä, jolla on useita reittejä internetiin. Yhden ylälinkin testilaatikossa termi näyttää tarpeettomalta, ja juuri siksi se pudotetaan ennen kuin laatikko saa toisen ylälinkin.

Ulkoisen vaihdon käyttöoikeudet ovat erilliset. Yhdyskäytävän tulosuunta tarvitsee ne IKE- ja ESP- tai UDP-kapselointiportit, joita se tosiasiassa käyttää, eivätkä ne oikeudet valtuuta mitään sisällä olevan salauksesta puretun paketin osalta. Näiden kahden sekoittaminen on se tapa, jolla toimiva tunneli päätyy palomuuriin, joka välittää kaiken.

Saapuva konteksti ei ole lähtevä konteksti

Sama lausekeperhe kattaa toisen suunnan lausekkeella rt ipsec, joka kuvaa lähtevän turva-assosiaation, jota paketti käyttää. Se vastaa toiseen kysymykseen: ei siihen, mistä tämä paketti tuli, vaan siihen, suojataanko se seuraavalla osuudellaan.

Tällä erolla on merkitystä yhdyskäytävässä, joka sekä päättää yhden tunnelin että välittää toiseen. Paketti voi saapua salauksesta purettuna ja silti joutua lähtemään salattuna, eikä vain saapuvalle kontekstille kirjoitettu hyväksyntä kerro mitään lähtevästä vaatimuksesta. Jos käytäntö vaatii tuon suojauksen, sääntöjoukon pitäisi ilmaista se sen sijaan, että oletetaan reitityksen hoitavan sen.

Pidä kaksi kysymystä erillisissä säännöissä, jotta lukija näkee, kumpaa valvotaan. Yksi ovela sääntö, joka tarkistaa molemmat, on vaikeampi katselmoida ja paljon vaikeampi debugata, kun sen toinen puolisko lakkaa osumasta. Kaksi laskurillista sääntöä kertovat myös, kumpi vaatimus epäonnistuu, mitä yhdistetty sääntö ei koskaan tee.

NAT ei ole palomuuripäätös

Internetiin menevä liikenne yksityisestä asiakaspoolista tarvitsee yleensä lähdeosoitteen käännöksen, jotta vastaus löytää takaisin. Mutta toiseen lähtevään IPsec-käytäntöön valittu liikenne on pidettävä vaaditussa poikkeuksessaan, ja jokaisen yksityisen lähteen naamioiminen ajattelematta seuraavaa suojauspäätöstä rikkoo sen.

Hyväksyntä NAT-ketjun sisällä ei sekään ole yleinen lupa. NAT:lla ja suodatuksella on eri tehtävät, eikä NAT-ketju tutki vakiintuneen virran jokaista myöhempää pakettia, ja juuri siksi siihen turvallisuudessa luottaminen tuottaa sääntöjä, jotka näyttävät testissä toimivilta ja pettävät kuormituksessa.

Päinvastainenkin pitää paikkansa ja yllättää ihmiset: hyväksyntä jossakin yhdessä suodatuksen perusketjussa ei paina mitään myöhempää hylkäystä vastaan toisessa sovellettavassa ketjussa. Järjestys ja ketjun laajuus ratkaisevat lopputuloksen, eivät hyväksynnän olemassaolo tiedostossa.

Vahvista täsmällinen sisäinen palvelu

Testaa täsmällinen kohde ja portti, jonka valtuutit, oikealta asiakkaalta ja varmista, että vastaus tulee takaisin. Testaa sitten jotain, mitä et valtuuttanut, ja tarkista, ettei se mene läpi, koska liian leveä sääntö läpäisee ensimmäisen testin yhtä hyvin kuin oikea. Pyyntö, joka ei koskaan lähde asiakkaalta, ei sekään ole palomuurin tulos, joten lue laskurit nähdäksesi, arvioitiinko paketti ylipäätään. Kaksi testiä ja yksi laskurin lukema kertovat sinulle enemmän kuin kokonainen iltapäivä sääntöjoukon lukemista.

nftables-viite dokumentoi lausekkeet meta ipsec, rt ipsec ja suuntakohtaiset lausekkeet, ja juuri siellä syntaksi tarkistetaan asennettua versiota vasten. Ja pidä laajuus selvänä: tämä on IPv4-esimerkki, se ei kerro mitään IPv6:sta eikä tee mielivaltaisesta julkisten porttien välityksestä osaa VPN-palvelua.