Lidhje të përkohshme të listës së IP-ve të lejuara: çfarë lejon vërtet autorizimi

Shndërrimi i një klikimi në një rregull të përkohshëm firewall-i është i përshtatshëm, dhe ndërkohë ndërton një sistem autorizimi që vendos kush mund të arrijë një shërbim. Ai lëshon një adresë dhe jo një person, dhe ky ndryshim ka rëndësi në momentin kur dy njerëz ndajnë një NAT. Kufizoni shtrirjen e autorizimit, konfirmojeni me qëllim dhe jepini kuptim skadimit përpara se të ndërtohet lidhja. Vendimi përpara jush është ku të vendoset kufiri, jo nëse duhet të ekzistojë një i tillë.

Vendosni se për cilën pyetje përgjigjet autorizimi

Filloni nga kërkesa. Nëse një person i emërtuar duhet të arrijë shërbimin dhe aplikacioni e vërteton tashmë atë person, një portë e vërtetuar e mban identitetin në pikën e zbatimit dhe nuk ka fare nevojë për pranim adrese. Nëse objektivi është një agjent ndërtimi, një port kërcimi administrativ ose një pajisje që nuk mund të marrë pjesë në hyrjen e përdoruesit, një autorizim adrese me shtrirje të kufizuar mund të jetë kontrolli i vetëm praktik i disponueshëm.

Zgjedhja e pranimit sipas adresës për një aplikacion të drejtuar nga përdoruesit e zhvendos problemin e vërtetë të autorizimit diku tjetër, dhe atëherë portali trashëgon fajin për një boshllëk që nuk e mbylli kurrë.

Kufizoni kërkesën në server

Shfletuesi nuk duhet të zgjedhë destinacionin, portin ose prefiksin. Portali e zgjidh shërbimin nga regjistrat e tij dhe e kontrollon të drejtën me një test në anën e serverit, që është i njëjti parim që udhëzimet e OWASP për autorizimin e zbatojnë për çdo kërkesë. Edhe nxjerrja e adresës i përket kufirit të mbrojtur: kur një proxy i kundërt raporton adresën e klientit, pranoni vetëm zinxhirin e konfiguruar të proxy-ve dhe trajtimin e tij të dokumentuar të kokave. Koka e përcjelljes e siguruar nga një vizitor është një pohim për origjinën, jo dëshmi e saj.

Pastaj verifikoni që portali dhe shërbimi shohin të njëjtin burim. Tuneli i ndarë, një kërcim proxy dhe IPv4 kundrejt IPv6 mund t'u japin dy destinacioneve dy adresa të ndryshme, kështu që një autorizim i aktivizuar nga një rrugë mund të mos e mbulojë kërkesën pasuese.

Shfaqni autorizimin përpara se ta instaloni

Hapja e një lidhje duhet të shfaqë shërbimin e propozuar, burimin e vëzhguar dhe kohëzgjatjen, dhe ende të mos ndryshojë asgjë. Ai hap i vetëm e kthen lidhjen e ardhur me email nga veprim në propozim, dhe e pengon një bot parashikimi ose një skaner poste të japë akses thjesht duke e marrë.

Konfirmimi duhet të jetë një kërkesë që ndryshon gjendjen, me mbrojtjet e zakonshme ndaj faqeve të ndryshme dhe origjinës. Shenja duhet të jetë njëpërdorimshe dhe të konsumohet në mënyrë atomike në momentin që instalohet rregulli, dhe regjistri duhet të kapë pronarin, shërbimin, adresën, identifikuesin e autorizimit dhe skadimin pa regjistruar kurrë shenjën e papërpunuar.

Dërgimi i shenjës meriton të njëjtin kujdes si vetë rregulli. Një lidhje e skaduar ose tashmë e konsumuar që ende prodhon një rregull është një derë e dytë e pajisur me të njëjtin çelës.

Adresa ndahet edhe ndërsa autorizimi është i gjallë

Një NAT zyre, një NAT operatori dhe një dalje VPN e ndarë secili vendos disa njerëz pas një adrese. Pranimi i asaj adrese pranon të gjithë ata që janë pas saj — për sa i përket kufirit të ardhshëm të shërbimit —, pa dëshmuar asgjë për atë se kush e mban llogarinë që pret shërbimi.

Heqja e rregullit nuk është as një shkëputje universale. Lidhjet e vendosura, shenjat e aplikacioneve në memorie dhe sesionet jetëgjata mund ta mbijetojnë rregullin me minuta ose shumë më gjatë, prandaj jetëgjatësia që zgjidhni duhet të pasqyrojë atë që bën shërbimi pas pranimit, e jo vetëm sa kohë ekziston rregulli.

Provoni katër raste, dhe të dyja familjet e adresave

Një autorizim vlen aq sa katër rastet që përballon: një kërkesë e re e lejuar, një kërkues i palejuar, një përsëritje e së njëjtës lidhje dhe e njëjta kërkesë pas skadimit.

Pastaj provoni secilën familje veçmas, sepse adresa e burimit që vëzhgon shërbimi mund të ndryshojë mes tyre.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Rezultati i dobishëm është një vendim pranimi i përkohshëm dhe i auditueshëm nën autorizimin normal të përdoruesit, e jo një hapje e përhershme që mban emrin e atij që klikoi i pari.