Vlákno názorů k článku Použijte správný firewall pro ochranu své sítě od VViki - Děkuji všem odpovídajícím - nápad, realizovat "HTTPS Proxy"...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
VViki (neregistrovaný)Děkuji všem odpovídajícím - nápad, realizovat "HTTPS Proxy" coby man-in-the-middle je jedna z jeotřesnějších věcí, co bych u produktu řešící zabezpečení čekal...
Osobně by pro mě existence takové "feature" na seznamu podoporovaných "technologií" u firewallu byla zásadní překážkou k nákupu produktu (protože jak bych mohl důvěřovat implementaci ostatních zabezpečovacích funkcí s tímhle přístupem k bezpečnosti?). Kladné hodnocení už vůbec nechápu.
VViki -
VViki (neregistrovaný)Může mi prosím někdo vysvětlit, jak může korektní HTTPS proxy něco (cokoliv) kontrolovat?
Teče přes ni přeci šifrovaný stream dat, do kterých proxy nemůže vidět.
Pokud by se data pokoušela rozšifrovat (tj. byla by koncem SSL tunelu), tak je nebude schopná zpět zašifrovaně předat dál klientovi a každá smysluplná implementace klienta je přeci musí odmítnout...
VViki -
davro (neregistrovaný)kecy v kleci, mrkněte se na web:
A secure surfing session protects user data and privacy, but threatens the security of the company. Sites visited and files downloaded over HTTPS can contain malicious content that can enter the network while the security device remains blind. Astaro’s HTTPS filtering removes this unwanted network blind spot and gives you full visibility into this traffic.
http://www.astaro.com/applications/web-security/https-scanning
Jak z tohoto plyne nějaký frontend k https serverům mně není jasné. -
anonymníOno staci vytahnout na nekoho jen ty logy, protoze stejne jako nevysvetlitelne najete kilometry s firemnim autem tak i komunikace s kubikem s horni dolni muzou vest k vyhazovu a je naprosto jedno kde jste s tim autem byl nebo co jste si s tim kubikem psal.
A prosim odkaz na judikat te prohrane pre, abysme videli ze to bylo skutecne kvuli pouziti nelegalne ziskanych informaci. -
Fis (neregistrovaný)
Me osobne prijde mnohem vetsi prasarna balit do HTTPS trafficu malware, viry, zneuzivat ho pro phishing ze strany serveru nebo napriklad P2P traffic ze strany uzivatelu. Bez ukonceni na proxy a opetovnem zasifrovani a duveryhodnem podepsani trafficu internim duveryhodnym klicem neni mozne se nijak uvedenym problemum branit. Obnasi to samozrejme dalsi bezpecnostni problemy s proxy serverem, ale obecne je toto reseni z bezpecnostniho hlediska jedine mozne a spravne.
-
x (neregistrovaný)ano je, napriklad pro FortiGate tady:
http://docs.fortinet.com/fgt/archives/3.0/techdocs/FortiGate_Administration_Guide_01-30006-0203-20080313.pdf - strana 330, cast "SSL Offloading"
- a naopak tam nikde nepisou ze by to umelo zachazet s https trafficem tak jak chcete vy (jenze ja narozdil od Vas samozrejme netvrdim ze to nejde jinak, a nebo ze se nenajdou pripady kdy by se to tak dalo pouzit)
pro Astaro to podle vseho planuji na dalsi verzi (viz http://feature.astaro.com/forums/17359-astaro-gateway-feature-requests/suggestions/178298-http-reverse-proxy)
kdyz jsem si ale znovu precetl clanek, tak tam je nespis opravdu myslena ta uzivatelska proxy kterou Astaro nejspis umi (a ktera zas takova prasarna to byt nemusi - to uz zalezi na impementaci) -
VViki (neregistrovaný)Aha, pokud jde o reverzní proxy, tak tam to smysl dává (i když osobně si myslím, že je vhodnější protáhnout chráněný kanál co nejdál k cílové serverové aplikaci).
Pokud by ale mělo jít o klasickou proxy (nikoliv reverzní), tak je to zvrácená myšlenka. V mnoha případech nedokáže žádný software zkontrolovat, jestli SSL kanál je chráněný správným serverovým certifikátem. A tím, že zcela vezmu uživateli možnost certifikát ověřit, otevírám vrátka skutečnému man-in-the-middle útoku (nehledě na možnost odposlechu nechráněné komunikace ve vnitřní síti)...
Pro mě jako uživatele se nasazení takového "proxy serveru" rovná znemožnění použití HTTPS.
Podle mě je mnohem čistější řešení HTTPS obecně zakázat a povolovat je pouze pro cílové servery, kam se uživatelé prokazatelně potřebují dostat a kterým jako organizace důvěřuji...
VViki -
Fis (neregistrovaný)
Souhlasim s vami, ale asi zalezi na implementaci. Pro vyjimky se dekrypce neprovadi vubec. Krome toho - co adminovi zabrani v MITM odchytavani provozu? Snad jen sptane svedomi, technicky to neresi v podstate nic. Ve vetsich firmach rozdeleni roli, v mensich je to v kyblu. Proto je nutno alespon vse bezpecne logovat, idealne tak, aby s logy nemohli administratori nijak nakladat.
-
x (neregistrovaný)ja v podstate souhlasim s poslednim odstavcem, ale zase si na druhou stranu nemyslim ze by to proxy reseni nebylo rozumne realizovatelne (tj. s rozumnym snizenim bezpecnosti)
- proxy server muze (mel by) overit ze vzdaleny certifikat je podepsany nejakou autoritou, ktere veri (ostatne stejne jako to dela browser) a pokud ne, tak spojeni dale nepustit nebo zobrazit nejakou error stranku
- na klientske strane by pouzival certifikat narychlo podepisovany firemni certifikacni autoritou, kterou ma uzivatel naimportovanou ve svem browseru
(tj. pri requestu na proxy podle CN z praveho certifikatu vygenerovat vlastni certifikat a ten podepsat - tady bych videl slabe misto v rychlosti generovani crt, ale to by zase bylo jen napoprve, navic by to imho mohlo jit castecne predgenerovat)
to mi prijde sice ne uplne super, ale data necestuji nikde po siti v plain textu a zaroven ma uzivatel alespon trochu jistotu ze mluvi se spravnym serverem -
VViki (neregistrovaný)Kdyby byl svět ideální, tak byste mohl mít pravdu (ale pak by zas nemělo smysl používat HTTPS).
Jenže svět ideální není a proto je tahle úvaha špatná.
Pokud přistoupíte na řešení, které jste popsal, tak prostě ztrácíte kontrolu nad zabezpečeným kanálem a nedokážete jeho bezpečnost nadále posoudit.
Nemůžete si být jistý, zda někdo na proxy server nedostal mezi důvěryhodné autority nějakou svou a nerealizuje man-in-the-middle útok ještě před proxy serverem. Nebo že nedělá totéž mezi proxy serverem a Vaším počítačem.
Nemůžete se podívat, jaké algoritmy používá zabezpečený kanál mezi proxy a cílovým serverem (jestli jeho zabezpečení odpovídá Vašim požadavkům, bohužel, dnes už není zas takový problém podvrhnout za použití určitých algoritmů certifikát, který daná CA nevydala (ale podpis sedí)). Nebo jaké atributy má originální serverový certifikát (zda sedí EV atribut).
Ve finále máte kanál, který >věříte<, že je zabezpečený. A špatné zabezpečení je horší než žádné (protože tam si každý případnou nebezpečnost uvědomuje).
O nefunkčnosti klientské SSL autentizace ani nemluvím....
VViki -
x (neregistrovaný)stejne jako Vy verite tomu, ze Vam nikdo do pocitace bez Vaseho vedomi nenainstaloval svoji CA jako duveryhodnou a nedela MITM nekde dal
malokdo si pokazde overuje certificate chain, a to ze by si nekdo telefonicky overoval hash certikatu jsem jeste nevidel (a i kdyz urcite nekdo takovy existuje, tak to nebude ani promile lidi co https pouzivaji)
btw. povezte mi, jak podvrhnete cerfikat s CN ktery Vam CA nepodepsala? hratky s UTF8? na to uz prohlizece nenaleti... brute force hadani klicu? good luck... jediny co slo, byl bug v ssl v debianu, ale to uz dneska taky nepouzijete
ale jak uz tu nekdo psal, pokud se Vam tenhle zpusob zabezpecni ve firme nelibi, nikdo Vas nenuti to (obzvlaste k soukromym aktivitam) pouzivat. pokud firma takovou bezpecnosti politiku s vedomim rizik akceptuje, tak Vam do toho nic neni -
VViki (neregistrovaný)S tou důvěrou, to přeci není vůbec totéž - pokud se provádí kontrola až u mě, tak ji můžu prověřit.
Já si taky vždycky certifikát neověřuju. Ale ten zásadní rozdíl je v tom, že to můžu udělat, když to bude charakter komunikace vyžadovat. Tady to tu možnost zcela odebírá. A tím to zabezpečení degraduje na víru.
Co se týká podstrčení certifikátu - je to právě o těch algoritmech, o vytvoření kolizních certifikátů (tj. certifikátů, které budou mít stejnou hodnotu digestu).
Nejde o to, že by se mi to nelíbilo, mě to přijde zvrácený :-). A jak jsem psal - produktu, jehož tvůrci mají takový přístup k zabezpečení bych prostě nemohl důvěřovat (protože jak už jsem psal, je pouze jedna věc horší než žádné zabezpečení a to je špatné zabezpečení, které dává lidem pocit falešného bezpečí).
Ale já naprosto respektuju, že jiní lidé na to budou mít jiný názor (na druhou stranu, i když bude tisíc lidí vyfukovat cigaretový kouř do vody, zlato tím nevznikne ;-) ).
VViki -
bman (neregistrovaný)Berte to tak, že jsou tady technologie, které inspekci HTTPs provozu umožňují a záleží jen na dané firmě/organizaci jaká pravidla si určí v bezpečnostní politice.
Některé firmy to vůbec neřeší, některé ano.
A co druhý pohled na věc: Tímto řešením budete mít menší problémy, protože platnost a validnost certifikátů ověřuje/vynucuje HTTPs proxy a uživatel nemá možnost odklikat povolení podvrženého/neplatného certifikátu. Dva úhly pohledu/dva různé závěry a asi v každé organizaci bude jiný. -
Martin Kalenda (neregistrovaný)Chápu že to umí, ale nechápu jak to souvisí s tím že se to musí nastavit zrovna takto.
Mj, pokud je s tím zaměstnanec seznámen tak nemá co remcat, nepracovní věci má dělat doma. Produktivitu nelze měřit tím co klikal neklikal, tj nemá smysl číst co kdo dělá. Myslím že auditování takovéhoto provozu je tam pro ex-post dokazování. -
xpckar (neregistrovaný)Myslí se tím zavrženíhodná/odporná čuňárna typu:
Jedno šifrovaný spojení prohlížeče k proxy, a jiné od proxy na příslušnou adresu (dle IP cílovýho serveru), přičemž uživateli je pokoutně do prohlížeče třeba doménovou politikou podstrčena nějaká důvěryhodná CA, v rámci níž se generuje v reálu falešnej certifikát s cílovým URL (a vůbec s podvrženými parametry), přičemž některý prohlížeče jsou tak neschopný a hloupý, že o tom, že se jim tam objevila nová důvěryhodná CA, ani uživateli nedají vědět.
Neboli nejlepší by bylo v tomhle šmejd stavu kontrolovat vždy certifikát.
Tudíž ve firmě je rozhodně důležitá kontrola certifikátu, a v případě, že je CA nesprávná, v případě nemožnosti to změnit použít jedině jiný zařízení neboli jinej kanál. -
TNK (neregistrovaný)Je to tak, proxy se tvari jako server a tim padem klient se overuje proti ni (a ne proti serveru) takze vse vyapa ok a komunikace mezi serverem a proxy muze jet jen po http.
Mozna je i varianta kterou bych popsal Man-In-The-Middle kde se klienti pripoji k interni proxy a k ni si vyjednaji i SSL autentikaci a proxy pak sama navaze spojeni se SSL serverem (a tak se interne muze divat do toho co skrz ni projde, protoze interne do trafficu vidi).
Co me zarazi na tomto clanku je absolutni ignorace znamych firewallovych hracu predevsim svetove jednicky na trhu - Izraelske spolecnosti Check Point a druheho v poradi uspesnosti - Juniper. Zatimco jakesi podivne linuxove reseni je hned na prvnim miste
Ostatne jeste je pomerne zajimave delat jakoukoliv proxy na firewallu...ale proti gustu -
davro (neregistrovaný)Pokud je firma až tak paranoidní, tak nebude problém patřičné servery s https vyjmenovat a těm pak důvěřovat. Těžko vám bude banka nutit viry. Na další externí https věci prostě lidi vůbec nepouštět.
Tímto způsobem man in the middle si akorát můžete způsobit problémy, protože koncový uživatel nemůže ověřit správnost certifikátu místa, ke kterému se připojuje. -
davro (neregistrovaný)A je tam snad napsané, že se to dá nastavit jinak? K čemu by taková funkcionalita byla? Pokud mám servery ve své správě, tak si vstup od uživatele musím řádně ošetřit, pokud to neudělám, dopadnu blbě.
Není problém v tom, že zaměstnanec nedělá co má. Problém je třeba v tom, že administrátor má přístup k autentizačním údajům třeba do banky, což by mít v žádném případě neměl. -
Petr (neregistrovaný)Ale to že to nechápeš není problém technologie.
Představ si situaci, kdy firma chce auditovat, jaké informace tečou skrze její infrastrukturu - https spojení je potom potřebné do dosažení perimetru sítě, ale vnitřní prostředí považuje za bezpečné (a zároveň auditovatelné), takže terminuje HTTPS na perimetru a dovnitř pustí jen pure HTTP. A uživatel nic vědět nemusí.
Další scénář počítá naopak s tím, že zatímco integrita spojení je důležitá, tak případný útok na aplikační rovině může být kritický. A právě proto, že HTTPS se inspektovat nedá, tak si to musí někde otevřít.
A vzhledem k tomu, že serverový certifikát má pod kontrolou, tak není problém ho nahrát i na danou proxy (při komunikaci dovnitř, samořejmě).
Řešení je spousta, mají různé opodstatnění a často je to i naprosto nutný požadavek.
O tom že článek se věnuje segmentu malých a středních řešení nemluvím, jinak by tam asi musel zmínit právě Checkpoint, Juniper, Cisco ASA, případně jiné. -
xpckar (neregistrovaný)Je to podvod. Především zcela vynuceně by měli být uživatelé informováni, že použití SSL/TLS ve firmě se sleduje, aby se mohli podle toho zařídit (používat vlastní zařízení/PC/mobil). Často se to tak ovšem neděje, a firmy to dělají pokoutně uživatelům za zády.
U tvýho "uživatel nic vědět nemusí" se mi otevírá kudla v kapse. -
anonymníEhm, ze ty nechapes co je zabezpeceni je zjevne jen tvuj problem. Jakmile se neco takoveho objevi v ceste, tak to znamena, ze kdokoli muze nahlizet do komunikace (trebas admin) a zaroven ji taktez nalezite upravovat. Neni pak prakticky zadny problem zobrazit prevod na ucet parnera, ale v realu si zmenit cislo uctu na sve. Ostatne i proto pouziva kazda rozumna bankovni aplikace nezavisly kanal, takze ani v pripade ze dojde k naruseni bezpecnosti by nemelo dojit k pozmeneni dat.
Nehlede na to, ze existuje technologie SSL v HTTP => pro proxy se veskera komunikace tvari jako jakasi binarni http komunikace, v realu jde ale o ssl kanal.
A co se auditovani (aneb smirovani) uzivatelu tyce, oni se zamestnanci jednoho krasneho dne nastvou a zamestnavateli to daji pekne sezrat. Ono je to totiz (mimo jine) v rozporu se zakonem a kdo myslis ze na to dojede ? Ano, spravne admin, ktery to ma nastarosti. Byl by blazen kdyby ve firme neco takoveho implementujici hodlal pracovat dyl nez tech 5 minut do vypovedi.
Pokud nekdo chce vynaset firemni data, tak to stejne udela a nikdo mu v tom neni schopen zabranit, pokud k tem datum potrebuje mit pristup. -
anonymníPresne tak a nejen to, datove schranky, komunikace s partnery (take casto https) .... Je to naprosto totez jako kdyz si admin zapisuje hesla useru aby se na ne mohl prihlasit (celkem bezna praxe v mnoha firmach).
BTW: Pokud sef nedokaze zhodnotit a kontrolovat praci svych podrizenych jinak, nez jejich smirovanim, a zjistovanim jejich "nepracovnich" aktivit, tak si zaslouzi jedine a to vyhazov (variantne krach vlastni firmy). Pokud totiz nekomu zadavam nejaky ukol, je jen na mne abych zaroven pridelil odpovidajici cas.
Pokud to dotycny udela o vikendu a pak si bude v tydnu chatovat na libimseti, je mi to fuk. Pokud mam pocit ze ma malo prace, je to moje chyba, pokud ji ma moc, je to opet moje chyba. V obou pripadech to bude firmu stat penize, v prvnim na promrhanem case, ve druhem za jineho pracovnika, jeho zaskoleni ... .
Bohuzel v CR stale panuje uvazovani jak za sociku. Tudiz neni podstatne zda v praci pracujete, podstatne je si tam odsedet odpovidajici cas.
Navic to jeste podporuji dementni redaktori a idioti z auditorskych firem (za dlouhe penize za audity = opet smirovani lidi) informacemi, ze se 70% casu lidi flakaj na facebooku. Mozna ano, ale to neni jejich chyba, to je chyba jejich sefa, ktery jim nepridelil zadnou praci. -
anonymníZeby zakon o telokomunikacich a nezakony odposlech ? Ze zakona jste opravnen zaznamenavat informace nutne k technickemu zajisteni provozu telekomunikacniho zarizeni = to jsou napriklad nejake logy. Rozhodne nejste opravnen zasahovat do spojeni jako takoveho, natoz jej zaznamenavat, navic v pripade https dokonce prolamujete sifrovane spojeni, da se tedy dovodit, ze si protistrany nepreji byt odposlouchavany.
Zamestnanci muzete rikat co chcete, stejne porusite zakon + jako bonus vas trebas zazaluje protistrana (banka a dalsi na 100%), protoze prolamujete jejich zabezpeceni.
Jestli jste nekdy mel napriklad v ruce smlouvu na provoz karetniho bankovniho terminalu, tak presne takoveto aktivity jsou tam vyslovne zakazany pod milionovymi penalizacemi + samozrejme hradite veskere skody atd.
Napriklad co se tyce emailu, existuje dokonce nekolik rozsudku (vcetne nevyssiho soudu) ze email obsahujici identifikaci typu jmeno/prezdivka/... je soukromy bez ohledu na to, kdo jej provozuje. I pokud pak zamestnance upozornite a date mu mail pepa.voprsalek@firma.cz mate smulu, protoze nikdo zvenku neni schopen rozlisit zda jde o mail "firemni" nebo soukromy (trebas provozujete freemail ...). Takze az na nekoho vytahnete, ze si mailuje v pracovni dobe s kubikem z horni dolni a posila mu pozvanky napivo, prave ste si zadelal na 2roky v base natvrdo.
(Jo zam jednu "cerstve na materske", ktere se firma chtela podobne zbavit a soud bleskove prohrala)
ČLÁNKY DO MAILU