Nuk ka tun0? Përputhni IPsec e dekriptuar në nftables me meta ipsec

Prisni një ndërfaqe tuneli, e kërkoni dhe në firewall nuk ka asgjë për të përputhur. Kjo është normale për një portë të bazuar në politika: shkëmbimi i kriptuar mbërrin në ndërfaqen fizike, dhe paketa e brendshme e dekriptuar që përcjellët më pas vërehet gjithashtu duke mbërritur në të njëjtën ndërfaqe. Nuk ka tun0 sepse asgjë nuk krijoi një të tillë.

Kërkesa e brendshme mbetet një paketë e veçantë me burimin, destinacionin dhe shërbimin e vet, dhe kerneli e di nga cili asociacion sigurie doli. Është pikërisht kjo njohuri që një rregull firewall mund të përputhë.

Dy paketa, një ndërfaqe

Imagjinoni drejtimin hyrës. Mbërrin një paketë e inkapsuluar në ESP ose UDP, kerneli gjen politikën përkatëse, e dekripton dhe ia dorëzon paketën e qartë rrugës së përcjelljes. Një rregull që shikon vetëm emrin e ndërfaqes nuk mund ta dallojë atë paketë nga çdo trafik tjetër që mbërrin në të njëjtin kabllo.

Ajo që e dallon është konteksti i rrugës hyrëse të sigurisë i lidhur me paketën. nftables e ekspozon si meta ipsec exists, që është e vërtetë kur paketa mbërriti përmes një rruge sigurie IPsec. Kombinojeni me grupin e klientëve, destinacionin dhe shërbimin, dhe rregulli bëhet mjaft specifik për të qenë i sigurt.

Të lësh kontekstin është gabimi i zakonshëm, dhe është gabim sigurie, jo estetik. Një rregull që pranon gjithçka që vjen nga grupi i klientëve pranon po aq me dashje një paketë të falsifikuar nga rrjeti lokal, sepse adresa burimore nuk është provë e asgjëje në vetvete. Konteksti i rrugës së sigurisë është mënyra më e lirë për ta bërë burimin kuptimplotë. Shkruajeni rregullin me atë që në fillim në vend që ta shtoni pas një auditimi.

Shkruani rregullin e përcjelljes

Supozoni një shërbim aksesi në distancë IPv4 të vërtetuar me klientë në 10.90.0.0/24 dhe një destinacion të miratuar në 203.0.113.40. Një fragment rregulli për atë rrjedhë duket kështu.

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

Adresat dhe ndërfaqja janë shembuj për t'u zëvendësuar. Vendosni ekuivalentin e shqyrtuar në politikën e përcjelljes përpara rregullit që përndryshe do ta refuzonte rrjedhën, dhe mos e zbrazni një grup rregullash ekzistues për ta instaluar; një portë nuk është eksperiment në dhomë të pastër.

Termi oifname ia vlen të mbahet. Dokumenton vendimin e daljes dhe pengon rregullin të përputhet në një drejtim që nuk e kishit ndërmend, gjë që ka rëndësi në një portë me disa rrugë drejt internetit. Në një kuti prove me një lidhje të vetme lart termi duket i tepërt, dhe pikërisht për këtë hiqet para se kutia të marrë një lidhje të dytë.

Lejet për shkëmbimin e jashtëm janë të veçanta. Rruga hyrëse e portës kërkon portat IKE dhe ESP ose inkapsulimit UDP që përdor në të vërtetë, dhe ato leje nuk autorizojnë asgjë për paketën e dekriptuar brenda. Përzierja e të dyjave është mënyra se si një tunel funksional përfundon me një firewall që përcjell gjithçka.

Konteksti hyrës nuk është konteksti dalës

E njëjta familje shprehjesh mbulon drejtimin tjetër me rt ipsec, që përshkruan asociacionin dalës të sigurisë që do të përdorë një paketë. I përgjigjet një pyetjeje tjetër: jo nga erdhi kjo paketë, por nëse do të mbrohet në pjesën tjetër.

Ky dallim ka rëndësi në një portë që përfundon një tunel dhe njëkohësisht përcjell në një tjetër. Një paketë mund të mbërrijë e dekriptuar dhe gjithsesi duhet të dalë e kriptuar, dhe një pranim i shkruar vetëm për kontekstin hyrës nuk thotë asgjë për kërkesën dalëse. Nëse politika kërkon atë mbrojtje, grupi i rregullave duhet ta shprehë atë në vend që të supozojë se rrugëtimi do të merret me të.

Mbani dy pyetjet në rregulla të veçanta që lexuesi të shohë cila po zbatohet. Një rregull i vetëm i zgjuar që kontrollon të dyja është më i vështirë për t'u rishikuar dhe shumë më i vështirë për t'u korrigjuar kur njëra gjysmë e tij ndalon së përputhuri. Dy rregulla me numërues ju thonë gjithashtu cila kërkesë po dështon, gjë që një rregull i kombinuar nuk do ta bëjë kurrë.

NAT nuk është vendim i firewall-it

Trafiku drejt internetit nga një grup klientësh privat zakonisht kërkon përkthim burimi që përgjigja të gjejë rrugën e kthimit. Por trafiku i zgjedhur për një politikë tjetër dalëse IPsec duhet të mbajë përjashtimin e kërkuar, dhe maskimi i çdo burimi privat pa menduar për vendimin e ardhshëm të mbrojtjes e prish atë.

Një pranim brenda një zinxhiri NAT nuk është as ai leje e përgjithshme. NAT dhe filtrimi kanë detyra të ndryshme, dhe një zinxhir NAT nuk shqyrton çdo paketë të mëvonshme të një rrjedhe të vendosur, dhe pikërisht për këtë mbështetja tek ai për siguri prodhon rregulla që duken se punojnë në provë dhe dështojnë nën ngarkesë.

E kundërta është gjithashtu e vërtetë dhe i befason njerëzit: një pranim diku në një zinxhir bazë filtrimi nuk ka asnjë peshë kundër një refuzimi të mëvonshëm në një zinxhir tjetër të zbatueshëm. Rezultatin e vendosin rendi dhe shtrirja e zinxhirit, jo prania e një pranimi në skedar.

Verifikoni shërbimin e saktë të brendshëm

Provoni destinacionin dhe portën e caktuar që keni autorizuar, nga një klient i vërtetë, dhe konfirmoni që përgjigja kthehet. Më pas provoni diçka që nuk e keni autorizuar dhe verifikoni që nuk kalon, sepse një rregull shumë i gjerë e kalon provën e parë po aq mirë sa një i saktë. Një kërkesë që nuk largohet kurrë nga klienti nuk është as ajo rezultat i firewall-it, prandaj lexoni numëruesit për të parë nëse paketa u vlerësua fare. Dy prova dhe një lexim numëruesi do t'ju thonë më shumë se një pasdite e tërë duke lexuar grupin e rregullave.

Referenca e nftables dokumenton meta ipsec, rt ipsec dhe shprehjet specifike për drejtimin, dhe atje është vendi për të kontrolluar sintaksën ndaj versionit të instaluar. Dhe mbani shtrirjen të qartë: ky është një shembull IPv4, nuk thotë asgjë për IPv6, dhe nuk e kthen përcjelljen arbitrare të portave publike në pjesë të shërbimit VPN.