Super bezpecnost,fakt, zejmena z pohledu firmy.
Drive stacilo kontrolovat prochazejici provoz, z nejz jen 10% bylo sifrovano (pouze to, kde byla hesla ci formulare) , a i to slo on-fly desifrovat pomoci vygenerovani fake certifikatu na proxy. Samozrejme pokud na druhe strane byl server typu internetove bankovnictvi, a proxy to detekoval a overil, mohl komunikaci z desifrovani vyjmout.
Dnes, kdy je objem sifrovanych spojeni opacny, je toto uz diky advanced kontrole certifikatu v browserech uz temer nemozne, a zbyva tak v podstate jen sledovat DNS ci uvodni sestaveni https komunikace (zahlavi certifikatu), pokud chcete blokovat nechteny provoz z firemnich pocitacu.
OK, tak tedy zasifrujeme DNS i uvodni vymenu dat, a firma uz vubec nebude tusit, kam se jeji zamestnanci pripojuji. V dobe cloudu a CDN uz IP nema smysl resit, pridame jeste IPv6 s primou komunikaci endpointu bez NAT, pridame Win10 kde si kazdy enduser muze instalovat zavirovane aplikace z M$ store bez omezeni, a kde si takove aplikace muze system instalovat i bez vedomi uzivatele sam, a cela odpovednost za firemni bezpecnost skonci na kazdem jednom konkretnim uzivateli PC. Hura.
Ze tomu uzivatel nerozumi/nechce rozumet a Vy nechcete/nemuzete/nestihate ho skolit ? No tak jim kupte nejake chromebooky a firemni data dejte rovnou v plen do cloudu, vzdyt na tom uz vlastne nezalezi, muze to uz byt jen horsi.
Bravo.
Podle mě je cestou zachovat obě možnosti.
Zaměstnavatel má právo filtrovat provoz (filtrovat, nikoliv špehovat!). Je hodně pracovních pozic, kde je žádoucí vynutit, aby zaměstnanec nemohl nikam jinam, než mu zaměstnavatel umožní pro výkon práce.
Na druhou stranu, není vůbec nic proti ničemu, aby byl i zaměstnanec informován o tom, že provoz podléhá inspekci / filtrování.
No pokud to je opravdu potřeba, dej mu do pracovní smlouvy povinnost se připojovat jenom skrz firemní proxynu s firemním certifikátem. Porušíš - letíš, nazdar.
Btw, rád bych viděl, jak zabezpečíš inspekcí spojení / proxynou notebook při home office nebo noťas obchodníka, který se připojí při prezentování zákazníkovi...
No pokud to je opravdu potřeba, dej mu do pracovní smlouvy povinnost se připojovat jenom skrz firemní proxynu s firemním certifikátem. Porušíš - letíš, nazdar.
To je velmi nešťastné řešení. Uživatel pak nevidí certifikát serveru a nemá možnost posoudit jeho důvěryhodnost. Takže namísto toho, aby certifikát (nějakou formou) viděl uživatel, bude ho vyhodnocovat proxy na základě nějakých automatických pravidel. (V praxi se povolí vše, že).
Hele, Madloki chce osobně převzít od uživatelů odpovědnost za jejich chování, tak ať si to užije, každý nový certifikát osobně prověří a přidá na whitelist. :D
Nebo ať si to prostě nastaví ve firmě tak, že každý s přístupem k PC dostane 1x ročně povinný školení na cyber security. Takový ty základy - phishing, certifikáty, podpisy, makra v Excelu, interní dokumenty na uloz.to atd. A jednou za čas, když se objeví nějaká kampaň nebo zranitelnost, prokazatelně rozešle mailem info o hrozbě. Zabere to míň času a v případě průšvihu ukáže protokol o školení a nazdar, může za to proškolený uživatel a o tomhle nebezpeční prokazatelně věděl.
To je přesně stejně chytré řešení jako nekupovat domovní dveře a místo nich dát na dům kameru a výňatek z trestního zákonu ohledně tr. činu krádeže.
Školení je prima, lidi pak vědí, co mají a nemají dělat, takže se tím sníží pravděpodobnost, že z blbosti nebo nepozornosti kliknou na něco co nemaj. Jenže ta šance se nesníží k nule, nesnížila by se na nulu ani v případě, že by za kliknutí na špatný odkaz byla kulka do týla. A když je těch zaměstnanců s přístupem k sdílenému prostředku několik desítek, tak pak už se ta šance zvyšuje k jistotě.
A přístup "no co, tak 200 lidí den nepracovalo, navíc teď máme na krku UOOU, ale máme koho za to vyhodit" - no comment.
Hele, takže pokud něco nefunguje na 100%, tak nemá cenu to dělat? To jako že pokud brzdy na autě dokážou zastavit auto jenom s pravděpodobností 99,9999%, tak raděj budeš mít auto úplně bez brzd?
Navíc si uvědom, že to, co ty lidi naučíš, se jim pak hodí i doma, nebudou to úplní tukani. Když vidíš ty doporučení, třeba "při stahování software si hlídej, aby tam byl zelený zámek" a "měň si co půl roku všechna hesla", no to je jak kdyby laikům radil blackhat.
Někteří lidi by se i chovali zodpovědněj, ale musí vědět jak na to. Co myslíš, že o bezpečnosti na netu učili ve škole někoho, komu je dneska 50+? Internet se sem dostal v době, kdy už byla valná většina z nich po vysoké a dneska to potřebují k práci, takže z 90% samouci, kterým někdo jenom v rychlosti ukázal funkce jejich CMSka, M$ opic a nazdar. Pak se po průšvihu zeptáš, proč se to stalo a týpek ti řekne "A jak jsem to měl, sakra, vědět?"
A pokud bys to nevěděl, tak zaměstnavatel má povinnost prokazatelně seznámit zaměstnance s riziky. Pokud je pro firmu riziko, že po rozkliknutí mailu bude 200 lidí stát, je třeba zaměstnancům vysvětlit, jak takový mail poznat.
A když to nastane, tak IT preventivně defenestrovat za to, že nerozdělí firmu do několika LAN tak, aby na sebe neviděla celá firma nepřímo a účtárna nemohla sestřelit výrobu nebo nákupčí nesmazal nedopatřením účetnictví. To je podstatnější, než sedět u firewallu, srkat kafe a špiclovat.
Navíc si uvědom, že to, co ty lidi naučíš, se jim pak hodí i doma, nebudou to úplní tukani.
Tukani ne, ono to je ve skutečnosti ještě daleko horší...
> Neukládejte soubory na Plochu!
>> A proooč??!! Tam to mám po ruce!
> Nikdo se v tom nevyzná, nepatří to tam a po vašem odchodu fakt nemá nikdo náladu ten hnůj kydat a hledat pracovní dokumenty. Nikdo to po sobě neuklízí, hromadí se tam bordel a zpomaluje to přihlašování a odhlašování uživatele, protože ta složka je přesměrovaná na server a synchronizuje se.
O rok později:
>> Já mám hrooooozně pomalý přihlašování do Windows!!! S tim se nedá pracovat, já chci novej počítač!
> To bude asi proto, že máš na Ploše 150 GB sraček, z čehož jsou cca 0,0000001% pracovní věci a zbytek tvoří filmy z ulož.to, sračky z Fejsbůůůku a fotky a videa z mobilu (dovolená s manžou, chlastanice s kámoškama, svatební cesta, mimísek se poblinkal, přebalujeme mimíska, návštěva tchýně ...)
>> A to jako vadí jooo?!?!
> Mně ne, já nehekám že přihlášení trvá čtvrt hodiny.
Reálně opravdu nedá. Tedy pokud tě nebaví tisíckrát odpovídat na dotaz, proč nejde uložit soubor. A i v tom případě, že ty dementy úspěšně nějakým zázrakem vyignoruješ, tak jediným výsledkem je, že se bordel přestěhuje o úroveň výš, tedy přímo do %UserProfile%
. Bordel stejný, najdeš stejné houno a jako bonus to není ani na serveru a tudíž se to nezálohuje, takže ve finále o ty pracovní věci přijdeš.
Ale zajímavý je, že ty duté mozkovny si svoje krávoviny s mimískem, manžou, kámoškama apod. samozřejmě pečlivě tříděj do adresářů, aby to našly. Zato donutit je dávat pracovní věci na síťovej disk P: (Péééé jako Pracovní, ty Pindo) do příslušné složky, to je nadlidský úkol.
Hotovým požehnáním v tomto směru bylo GDPR, s jehož platností veškerý obsah ploch přes noc zmizel (přesunuto na dočasný disk na serveru za účelem roztřídění a smazání všeho nepotřebného). Pohled na ty ksichty, když se vrátily po víkendu do práce, byl opravdu k nezaplacení.
> Mě zmizela plocháááááááá, mám to rozbitý, pomoooooooooc, všechny soubory sou pryč!!!
>> Nic není rozbitý, plochy jsem smazal, protože soubory obsahovaly mraky soukromých věcí a osobních údajů, které nesmíme podle GDPR zpracovávat.
> Ale já tam mám i pracovní věcíííí, vraťte to zpátky!
>> Pracovní věci tam nemaj co dělat (viz směrnice), a žádnou zálohu nemám, protože GDPR a osobní údaje.
> A co mám teď děláááát? To to mám jako předělávat celý znova?
>> No, asi jo... :-DDD
O 4 měsíce později vidím, že se na Ploše opět začínají hromadit mraky hoven. Je to marný, marný a marný...
Tak to už asi jenom šikanovat uživatele. Vždycky prvního o půlnoci přesun všeho, co nemá příponu lnk, na jiný disk. S tím, že za měsíc se to přepíše novým obsahem ploch.
A obnovovat jenom na písemnou žádost mailem se schválením vedoucího. Ať taky někdo další vidí, co tam mají za bordel. Tím se obnoví jenom pracovní věci a příště si na to dají bacha.
To by hned ubylo mimísků a koťátek a prémií :D
2Lol Phirae: Prihlasovani 1/4 hodiny? Tak to ses jeste v klidu ... dneska ... 55minut (shodou okolnosti sem to celkem presne stopnul) ... a duvod ... samozrejme doslova zajebana plocha bambiliardou sracek. A pritom se jim pravidelne troubi, ze U jako Uzivatelsky disk a S jako Sdileny disk.
Bonus k temhle srackam je to, ze pri tom na usera porad vyskakuje, ze se cosi kdesi nepodarilo synchronizovat ... protoze ti c..ci z M$ proste nedokazdou profil mountnout po siti.
"Haló, je tam IT? Mám strašně pomalej kompl."
"Co přesně je pomalýho?"
"Přihlášení do widlí, asi 20 minut"
"Moment, mrknu se... Aha, už to vidím, velký uživatelský profil. Trochu to promažu. Raděj si zazálohujte věci na U: a P:"
Druhý den:
"Pomóooc, zmizela plocháááá... přišla jsem o práci za půl rokůůů..."
No a buďto bude po bordelu na ploše, nebo si příště nebude stěžovat.
No a buďto bude po bordelu na ploše, nebo si příště nebude stěžovat.
Vzhledem k tomu, že už dávno je v doporučení řešit plochu jako redirected folder (případně s offline synchronizací), tak plocha načítání profilu nezpomaluje. To platilo tak před deseti lety, možná už je to i déle.
Admin by neměl nikdy buzerovat lidi, ale měl by umět dát řešení. Obzvlášť taková prkotina, jako je plocha a uživatelský profil se řeší centrálně a tak, aby uživatel nemusel nic řešit.
Rozumné řešení pro SSL inspekci (vhodné pro firemní nasazení) umí zachovat důvěryhodnost certifikátu. Používají se dvě CA, jedné klienti důvěřují, druhé ne. Navíc se certifikáty vystavují jako zrcadlo originálu, uživatel tedy má možnost posoudit "důvěryhodnost" certifikátu který nebyl vystaven veřejně důvěryhodnou CA. Většina uživatelů stejně důvěřuje výchozímu seznamu, tak v tom není zas až takový rozdíl.
Admin pak udržuje seznam důvěryhodných CA na proxy. Navíc pro kritické klienty může zabránit přístupu na server který se důvěryhodným certifikátem neprokáže. Nechávat posouzení důvěryhodnosti na uživateli není dle mého názoru ta úplně nejlepší varianta. Byla by to zajímavá statistika, kolik uživatelů varování prohlížeče o nedůvěryhodnosti zastaví ....
Ne že bych už neviděl MITM řešení při jehož průchodu se všechny certifikáty "zdůvěryhodnily", ale něco takového si nikdo rozumný do sítě nepustí.
Ne že bych už neviděl MITM řešení při jehož průchodu se všechny certifikáty "zdůvěryhodnily", ale něco takového si nikdo rozumný do sítě nepustí.
Já se obávám, že je to spíš otázka peněz. Dnes se dá pomocí SNI poměrně levně filtrovat (proxy přeruší spojení, když požadavek nevyhovuje filtru) a nevyžaduje to žádný deploy certifikačních autorit apod. Ve výsledku bude přínos diskutabilní a v mnoha situacích se jednoduché řešení prodraží na složité; to mi přijde škoda. Podle mě by bohatě stačilo, aby prohlížeč filtrování v cestě hlásil.
spousta bezpečnostních průserů je také kvůli bezmezné snaze zaměstnavatelů zasahovat a koukat do komunikace zaměstnanců. Vlastní CA, filtrovaný provoz podle klíčových slov a bouchání se do hrudi, jaké mám zabezpečení. Tohle je iluze.
Samotná metadata provozu mi pořád dávají poměrně dost informací. Antiviry se umí dnes koukat již přímo do prohlížečů a pracovat s nimi, ostatní služby v OS mohu mít pod kontrolou aplikačním firewallem a to pořád za stavu, kdy nešahám do dat, která odejdou z počítače.
Nelze udělat bezpečnou komunikaci a zároveň někomu povolit, aby se do ní koukal.
Ne.
MiTM je útok, kdy se útoční postaví do cesty (in the middle). Odesílatel si myslí, že komunikuje s příjemcem. Ve skutečnosti komunikuje s prostředníkem. (Příjemce si naopak myslí, že odesílatelem je prostřední, ale ve skutečnosti jsou data určená pro původního odesílatele).
Šmírování a MiTM je něco jiného.
Ne, MiTM (Man In The Middle) je kdokoliv, kdo zasahuje do komunikace někde na přenosové trase. Do zasahování se přitom počítá odposlechnutí, přerušení nebo modifikování komunikace.
Řetězec je [stroj zaměstnace]-[síť zaměstnavatele]-[síť ISP]-[...] - z tohohle pohledu je zaměstnavatel "in the middle".
Pokud dojde k odmítnutí přístupu na stránku nebo přesměrování DNS dotazu na vlastní stránku s varováním, už je tam i to pozměnění komunikace. Technicky se to nijak neliší od filtru útočníka, který request na konkrétní stránku pošle na phishingový server.
"To běžně nebývá zahrnováno do pojmu MITM."
Definuj "běžně". V mým světě se běžně jako ochrana proti MiTM používá šifrování, přitom pokud odposlech není problém, stačí elektronický podpis - ztrátu komunikace, její změnu i podvržení pak jednoduše zaznamenáš.
Navíc "útok" obecně znamená jakýkoliv neautorizovaný zásah do komunikace, tj. ztrátu zprávy, podvržení zprávy, pozměnění zprávy nebo přečtení a zneužití dat ze zprávy. Nevím, proč jeden prvek z množiny vyřadit jenom proto, že pro jeho provedení má účastník fyzický přístup k médiu.
A navíc v trestním zákoníku konkrétně "read only" MiTM odměňováno podle §182 odst. 1 až dvouletou meditací v chládku o tom, že se to nedělá. Už jenom proto jsou snahy některých expertů se šmírováním komunikace zaměstnanců o hubu. A ISPík to má s bonusem, 1-5 let (odst. 5). Už jenom proto je snaha za každou cenu šmírovat zaměstnance a zákazníky hodně za hranou a mělo by se hledat lepší řešení, než lámání šifer.
Definuj "běžně".
https://en.wikipedia.org/wiki/Man-in-the-middle_attack: In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other.
Petr M.: Implikace není ekvivalence. Šifrování lze použít jako ochranu proti MITM, což ale neznamená, že vše, čemu se bráníme šifrováním, je MITM. To samé platí i pro útok, tj. když MITM je útok, neznamená to, že každý útok je MITM. V trestním zákoníku se „MITM“ ani český ekvivalent nikde nevyskytuje – opět platí, že to, že MITM je trestný podle § 182 TZ, neznamená, že vše trestné podle § 182 je MITM.
Aplikacne firewally budu mat presne so zasifrovanym SNI problem - uz uvidia iba IP adresu, co im bude presne na dve veci, ked na danej IP adrese moze byt hafo sluzieb. So zasifrovanym DNS, kde si resolving robi kazda aplikacia, uz ani nebudu moct cachovat DNS odpovede pre kazdy proces extra a orientovat sa podla toho, ake zaznamy aplikacia resolvuje. Tu uz pomoze iba blokovanie well-known DNS-over-TLS a DNS-over-HTTPS serverov a donutit ist aplikacie cez systemovy resolver (ako to ostatne robil macOS pre vsetky aplikacie s klasickym DNS cez port 53).
Donedavna bolo mozne pouzivat domain fronting: do SNI sa dal iny host, ktory bol na tej istej IP adrese ako cielovy host, a az v HTTP poziadavku bol realny cielovy host. Amazon a Google to po kritike zatrhli. Zasifrovany SNI nas vracia spat.