Je to jen zakuklené fízlování a velkobratrství. Proti malwaru je asi třeba bojovat
přiměřenějšími a účinnějšími prostředky. Verbovat na takovou odpornost
studenty a stavět si na tom kariéru je ubohé, trapné a směšné (Cisco to dělá
samozřejmě hlavně na "kšeft").
Odstrašující analogie: v jedné nezávislé centrální instituci před několika lety
útvar bezpečnosti IT zavedl fízlování HTTPS-provozu tak "chytře", že začal
spolu s cezením na FW podvrhovat na MS-OS do browseru jakýsi univerzální
interní certifikát, tj. stal se z toho man-in-the-middle (samozřejmě za tuto
"vymoženost" platí spoustu peněz dodavateli a samolibě to nazývají "bezpečným browsingem").
... a pak si nekde , kde maji tuhle HTTPS inspekci, zkuste vlezt treba do bankovnictvi a delat treba neco na svem uctu - vse je videt a bezpecne to tedy neni. Nastesti si to uplne vsechny stranky nenechaji libit a tak to nefunguje a musi se bud dat vyjimka a nebo to nepojede... na druhou stranu treba bez toho fizlovani HTTPS provozu je mozne treba propasovat EXE s virem do interni site a pak to antivejr zachyti az pomerne pozde, kdyz uz ten trojak / vir sedi na disku a hodla se rozkliknout... a ted babo rad, co je spravnejsi a co uz je fizlovani
Dobrý den, děkuji za Váš komentář. Náš cíl je však přesně opačný oproti tomu, co popisujete a před čím varujete.
Podle mého názoru, je náš způsob potenciální cestou, jak se vyhnout (plošnému) nasazování "proxy / man-in-the-middle" řešení nebo metodám "certificate pinning", které umožňují dešifrovat komunikaci.
My nic dešifrovat nechceme. Naopak chceme, aby detekční algoritmy nepotřebovaly ani SNI/doménové jméno.
Jinými slovy, naším cílem je vyvíjet detekční nástroje, které nenarušují soukromí uživatelů včetně nás samotných (narozdíl od způsobu, který jste popsal).
To, co je popsané v článku, není MitM.
Jinak to, co popisujete, dodavatelé řešení (Cisco a podobní) údajně prezentují jako obvyklou praxi. Mně to připadá postavené na hlavu a jenom čekám, kdy se toho chytí podsvětí a začne toho pořádně zneužívat. Protože to, že nemůžete kontrolovat certifikát protistrany, je podle mne tak podstatné snížení bezpečnosti… Mimochodem to svědčí o tom, že podsvětí ani zdaleka nevyužívá potenciál phishingu a zatím cílí jenom na uživatele, kteří neváhají zadávat přihlašovací údaje k bankovnictví do stránky, která vypadá úplně jinak, než bankovnictví jejich banky, a není ani česky. Představte si, až někdo (konečně) vyrobí phishing, který bude směrovat na doménu mojebanka.eu, kde bude přesná kopie mojebanka.cz. A lidé za těmito MitM „firewally“ uvidí na mojebanka.eu certifikát, který bude mít úplně stejné atributy, jako certifikát na mojebanka.cz – protože oba dva budou falešné certifikáty vyrobené tím „firewallem“.
Pokud má někdo potřebu čmuchat v šifrované komunikaci, ať si komunikaci vyvede v prohlížeči tam, kde se komunikace dešifruje. Jistě by nebyl problém na to udělat nějaké rozhraní, kam by se tenhle bezpečnostní software napojil. Ale zvykat lidi, že MitM je normální – jak to asi může dopadnout jinak, než že pak naletí na MitM, který ovšem nebude mít na svědomí hodný útočník ale zlý útočník?
Naprosto souhlasím.
Mj. kvůli těmto důvodům se soustředíme primárně na pasivní monitorování bez jakéhokoliv aktivního zásahu do komunikace.
Zároveň samozřejmě nerozporuji důležitost bezpečnostní analýzy na úrovni koncových zařízení (antivir, bezpečnostní rozšíření SW, SELinux apod), ale to už se jedná o problematiku mimo oblast našeho zájmu a výzkumu v současné době.
Osobně si myslím, že bezpečnostní analýza na koncových zařízeních by měla být základ, to nejdůležitější. Analýza síťové komunikace by spíš měla fungovat jenom jako upozornění, že se možná děje něco neobvyklého. To spoléhání na to, že si nebezpečný kód uživatel stáhne po síti, a že bude schovaný jenom TLS šifrováním, mi připadá dost krátkozraké. Uživatel může škodlivý kód přinést na flash disku. Když ty zakážeme, dostane ho do PC třeba přes kameru a QR kód. V instalaci softwaru se vracíme někam snad o třicet let zpět, spousta instalačních návodů je něco ve smyslu curl … | sh
– jestli ten kód bude na serveru zašifrován unikátním klíčem a po stažení zase dešifrován, málokdo si toho všimne, ale síťový antivir v tom nic nenajde. Nebo mne vždycky fascinuje, když poštovní server zablokuje přílohu s koncovkou .cer
, ale když certifikát zazipujete, ani není potřeba ho zaheslovat, a antivir na poštovním serveru je spokojen a pustí to dál. Ale proti útočníkovi, který neumí zazipovat soubor, je uživatel perfektně chráněn…
Takže doufám, že bezpečnostní analýza síťové komunikace půjde tou cestou, kterou jdete vy, a ochrana stanic se bude dělat na stanicích a ne jen na jedné z mnoha přístupových cest.
analyzovat metadata, paterny síťové aktivity a vzdálených IP adres, spojovat to s auditními záznamy přístupu k firemním zdrojům. Lze vybudovat relativně levně.
Por malou společnost mi dobře dnes vychází pořídit server, nasadit na to elastic a jeho SIEM, jde to zajistit rychle. Případně si SIEM systémy pronajmout (např. Azure sentinel je možné spojit s interní ifrastrukturou a není to tak drahé).
Jsem rát za všudepřítomné TLS, osobně nechci koukat na dešifrovaný obsah a nést odpovědnost za to, že někomu vidím pod ruce, že data z logů jsou citlivé údaje a tak s nimi musím zacházet.
Jsem rát za všudepřítomné TLS, osobně nechci koukat na dešifrovaný obsah a nést odpovědnost za to, že někomu vidím pod ruce, že data z logů jsou citlivé údaje a tak s nimi musím zacházet.
Mně připadá, že si lidé hlavně neuvědomují, že tímhle provozovatel firewallu přebírá zodpovědnost za to, že koncový uživatel komunikuje se správným serverem. Pošle někdo z firemního účtu na základě phishingu peníze skrze falešné bankovnictví na špatný účet? Není to jeho vina, protože neměl jak si zkontrolovat, zda komunikuje skutečně s bankou. Případná výjimka pro web banky na tom nic nemění, pokud neexistuje seznam domén, které mají tu výjimku.
proto se nastavuji vyjimky na bankovnictvi nebo medical care
Když ty výjimky nejsou nikde uvedené, je to k ničemu. Jdete na web, tam je podvržený firemní certifikát – a jak poznáte, že tam zrovna být neměl, že tam měl být originální certifikát banky? I kdyby ten seznam existoval – bude to proti němu opravdu někdo kontrolovat?
a jak poznám s jakými doménami mám správně komunikovat? Kde to banky uvádí?
Era/Poštovní spořitelna již měnila adresy asi 4x, s upozornění pouze na dané stránce, změnu nedala vědět jiným prostředkem než na nové adrese.
KB a jejich mojebanka.cz, dnes již nepoužívaná a přesměruje na mojebanka.kb.cz, změnu opět nedali vědět jinak než informací zanořenou v haldě textu při změně podmínek. Dostupné až na nové adrese, stará prostě přesměrovala.
Takhle bych mohl chvilku pokračovat s dalšími bankami nebo státními institucemi. Dopředu není jasné na které doméně ten který sídlí a časem se to mění.
No, moc neverim, ze to jde levne. Kdo to nakonfiguruje? Kdo to bude administrovat, analyzovat? Kdo to propoji s firemnimi auditnimi zdrojy (pokud vubec existuji)?
Ja treba provozuji elastiflow, ale ze bych z toho byl schopny vycist vic, nez kolik dat proteklo mezi kterymi body vcetne protokolu, to zatim ne. Identifikuje mi SIEM torrenty? Jak se zachova SIEM, pokud treba vyvojari nasadi novou aplikaci?
Chtelo by to nejaky clanek na takove tema.
tak záleží co znamená levně. Mluvím o cca 100 MD práce pokud to je na zelené louce. Poté správa, údržba, vyhodnocování a implementace nových aplikací znamená cca 20 MD / týden. Pro někoho pořád dost drahé, pro někoho levné a někdo to raději koupí jako službu.
Na torrenty a lepší informace ohledně metadat síťového provozu dlouhodobě používám v menších řešeních zeek na branách, pak vím i o těch torrentech.
Máš ale pravdu, že to je takové dost krkolomné a zatím v počátcích, znamená to dost práce a hotové řešení jsou cenově vysoko.
Otázka zní spíš: proč má firma uživatelům umožňovat skrze firemní privátní zabezpečenou síť realizovat soukromou komunikaci. Troufnu si říct, že právě díky tomuto "free režimu" se do mnoha firem dostane malware/ransomware.... podobně jako že se díky BYOD režimu zcela běžně vyzrazují přístupové údaje k firemním datům.
asi by to šlo vyřešit nařízením, že uživatel nesmí dopustit spuštění malware na jeho stanici, že?
Bezpečná infrastruktura musí být vybudovaná tak, aby odolala jakémukoliv spuštění kódu na počítači nebo navštívení webu. Mohu sice omezit, které stránky lze navštívit, ale ničemu tím nezabráním, stejně napadená může být jedna z povolených stránek.
Z profesní zkušenosti mohu říct, že opravdu napadené stanice nejsou kvůli soukromým aktivitám, ale spíše kvůli těm firemním (odkazy v emailu, vyhledávání informací/dodavatelů/zboží atd.).
Pokud jsou firemní data schovaná pouze za přístupovými údaji a ty stačí odcizit, je něco hodně špatně. Naopak BYOD z mého pohledu bezpečnost zvyšují, protože se vynucuje, aby o osobní zařízení zaměstnanců byly pod kontrolou, aktualizované a průniky do nich se sledovaly. Je těžké oddělit soukromý život zaměstnance od toho pracovního, je těžké zabránit, aby uživatel nemohl nijak propojit firemní zařízení se soukromým a zajistit tak napadení i firemního (klasicky přinesení pracovního notebooku domů na napadenou domácí síť).
Mohu sice omezit, které stránky lze navštívit, ale ničemu tím nezabráním, stejně napadená může být jedna z povolených stránek.
Někdy se stane, že kliknu (v prohlížeči Opera) na odkaz ve vyhledávači (Google) a hned mě varuje antivir (ESET), že zabránil spuštění nějakého trojana (nevím jméno). Nezkoumal jsem podrobnosti, představuji si, že ten pokus o spuštění trojana proběhne pomocí JavaScriptu. A přitom spousta webových stránek potřebuje k zobrazení obsahu JavaScript. Takže co s tím? Zakázat JavaScript? Odebrat Javě některá zbytečná práva? Spoléhat na antivir? Na žádné odkazy neklikat? Možná s tím JavaScript nemá nic společného a spouští se to úplně jinak, neznám podrobnosti.
ESET tohle řeší jen podle adres, které si pravidelně stahuje. Java a javascript jsou úplně jiné věci, mají jen společnou část slova, tak na to pozor.
Nejen javascript je nebezpečný, stejně tak nebezpečný může být jakýkoliv obrázek, video či funkce prohlížeče vyvolaná přes jeho api.
Nejlepší je odebrat práva celému prohlížeči, bohužel jejich vývoj jde opačným směrem, nabalovat funkce a práva, nikoliv odebírat (viz přístup na kameru, mikrofon, usb, sítě atd., nic z toho před pár lety ještě nešlo).
Docela se těším na dobu, že render webové stránky bude moci probíhat v izolovaném prostředí někde na serveru a klient uvidí jen výsledek. Do té doby to je boj s větrnými mlýny a v enterprise prostředí se bohužel výrazně omezují možnosti, co může dělat SW na daném počítači vč. pravidelné kontroly integrity při startu systému, to jde ale vše bohužel proti uživatelské přívětivosti.
Docela se těším na dobu, že render webové stránky bude moci probíhat v izolovaném prostředí někde na serveru a klient uvidí jen výsledek.
Mám dojem, že takhle to mělo být na začátku a od toho byly serverové skripty (např. PHP). Jenže pak se zjistilo, že je potřeba provádět nějaké operace u klienta (třeba předvyplňování a kontrolu údajů) a to lze jedině spouštěním dalších skriptů u klienta. A nakonec se z "obyčejného" hypertextu stal přehrávač videa, her, animovaných reklam, šmírovač schopností prohlížeče klienta... a obávám se, že cesta zpátky není.
Docela se těším na dobu, že render webové stránky bude moci probíhat v izolovaném prostředí někde na serveru a klient uvidí jen výsledek.
To je vývoj ve spirále – neustále se logika přenáší mezi klientským zařízením a serverem, ke kterému přistupuje jen hloupí terminál. Ale nemyslím si, že by se v nejbližší době přesunulo renderování stránek na server – tam je důležitá interaktivita, musíte být schopen reagovat už v řádu desítek milisekund. Fyzika je nemilosrdná, síťový roundtrip je omezený rychlostí světla – takže aby to bylo možné,musel byste ten serverový render dělat někde blízko uživateli, pravděpodobně v síti ISP, u firem by to pak mohlo být přímo na firemním serveru. Z hlediska bezpečnosti by to ale nebyl žádný krok vpřed – je jedno, jestli ten kód Facebooku spustíte na firemní pracovní stanici nebo firemním serveru.
on ten render může běžet i ve virtuálu na dané stanici, není potřeba nutně běhat kolem světa. Cíl je jednoduchý, výrazně omezit kam všude může mít přístup proces a co vše může dělat, tak abych to mohl nezávisle spravovat.
Chrome nedávno implementoval Site Isolation, což znamenalo značné úsilí, ale je to tak na půl cestě, pořád jsou jisté útoky možné i prakticky, není snadné autorizovat toho, kdo volá daný render a může se stát, že si rozkazuješ cizí stránce, reuse zdrojů jako cookies nebo samotných procesů a jejich pamětí je opět problém.
Mít možnost dělat render na firemní serveru přináší obrovské zvýšení bezpečností tím, že ten server mám pod kontrolou, může běžet v diskless modu, mohu výrazně omezit zdroje a cíle, které nebezpečný kód může použít. Nic z toho není možné snadno dělat na stanici.
Než aby běžel ve virtuálu, je podle mne z hlediska výkonu lepší, aby běžel přímo na stanici v sandboxu. A to už je prakticky současný stav. Zejména proto, že prohlížeč potřebuje mít přístup k akcelerované grafice, k audiu, k USB, k GPS atd. – dostat to všechno do virtuálního počítače může být oříšek.
Jediná věc, kterou by dávalo smysl řešit nad prohlížečem, je přístup k souborům. A k tomu není potřeba virtuální počítač, na to už operační systém má prostředky.
Pokud by renderovací server běžel v diskless módu, musí mu souborový systém zase poskytnout ta stanice, která by render využívala. A jsme tam, kde jsme teď.
JavaScript není Java. To „spuštění trojana“ pravděpodobně bylo jen spuštění nějakého JavaScriptového kódu, který by třeba těžil kryptoměny. Pokud by ten JavaScriptový kód spouštěl nějakou binárku ve vašem počítači, je to obrovská bezpečnostní díra prohlížeče. A pokud by vám to dělal opakovaně, je na čase vyměnit prohlížeč.
To „spuštění trojana“ pravděpodobně bylo jen spuštění nějakého JavaScriptového kódu, který by třeba těžil kryptoměny. Pokud by ten JavaScriptový kód spouštěl nějakou binárku ve vašem počítači, je to obrovská bezpečnostní díra prohlížeče.
Jestli se mi to stane příště, poznamenám si to. Zajímalo by mě, jestli se něco takového stává v prohlížečích s JavaScriptem pod Linuxem.
Zajímalo by mě, jestli se něco takového stává v prohlížečích s JavaScriptem pod Linuxem.
Myslím, že to bude především marketingová aktivita antiviru – musí předvést, že něco dělá, jinak byste si ho nekoupil.
JavaScript běží v sandboxu a je vlastně docela dobře oddělen od systému už jenom tím, že má přístup jenom k API, které mu prohlížeč vystaví. Aby mohl JavaScript škodit přímo ve vašem počítači, musí být chyba v tom API nebo přímo v interpretu JavaScriptu. Pokud by to měla být chyba umožňující spuštění libovolného nativního kódu, musela by to být dost specifická chyba. Přirovnal bych to k remote code execution pro rootem v linuxovém jádru – a děje se to zhruba stejně často, tj. velmi výjimečně. Na takovéhle chyby pravděpodobně antivir nestihne zareagovat, rychleji zareaguje tvůrce prohlížeče a doručí vám aktualizaci.
Druhá varianta neohrožuje přímo vaši bezpečnost, „jenom“ bude žrát váš výpočetní výkon a internetové pásmo. To je kód, který poběží stále v prohlížeči, nebude sahat na vaše data, ale spočítá něco pro útočníka – třeba bude těžit bitcoiny, hledat mimozemšťany nebo hledat léky.
To, před čím bude antivir asi varovat nejčastěji, jsou odkazy na weby, které buď cílí na několik let opravené chyby (třeba v parseru obrázků), případně se vás tam pokusí donutit něco stáhnout a spustit. Jsou to tedy věci, které by vám nijak neuškodily, pokud máte aktualizovaný prohlížeč a nespustíte všechno, co se spustit dá. No ale proč by za to antivir nemohl sbírat body, jak vás perfektně chrání, že…
nejspis stranka nabizela stazeni nejakeho souboru.
I to je možné. Měla tam být jen informace jak vyřešit nějakou triviální věc ve Windows (asi návnada). Jestli to nebezpečí antivir přecenil, aby zdůvodnil svou existenci, to nedokážu posoudit.
K tématu rizik na webu např. tento 11 let starý článek:
https://www.lupa.cz/clanky/bezpecnostni-rizika-novych-webovych-technologii/
Tak za prve, cela saskarna s sifrovanim info, ktera vubec netreba sifrovat, pada na vrub google - jeho bussiness stoji na cilene reklame. Tam chce mit monopol.
Z pohledu uzivatele, tomu je jedno, kdo mu do webovych stranek vklada bordel (a kdo ho monitoruje scripty, kdyz o tom nevi).
Z pohledu inzerenta, zaplati tomu, kdo reklamu zobrazi uzivateli, a zobrazi ji cilene.
Tezko nekoho popotahovat za to, ze jednoduchym DNS nebo http rewrite trikem svym zakaznikum na IP konektivite doruci reklamy nekoho jineho, nebo je tise nahradi uplne (treba obrazkem 1x1 pixel)
To zalovat nelze, ale ksefty to kazi. A tak se musi vse sifrovat (vcetne DNS), protahovat DoH, zlikvidovat SNI (zasifrovat) a vubec vymyslet idiocie typu Letsencrypt.
Nekdo mi ziska pristup na webserver, a vygeneruje si certifikatu kolik chce. Jaky to ma smysl ? Co takovy certifikat prokazuje ?
Potreba desifrace v ramci firem je enormni. Zakazat vse krom webu, web desifrovat. Pak bude opet mozno blokovat a vyrezavat reklamy jinak, nez na strane pofidernich extensions v browserech. Narky ohledne homebankingu jsou nesmyslne. Desifrace se da on-fly vypnout (tcp tunel misto desifrace) presne a cilene tam, kde ji nechcete - podle IP, podle hostname, podle kategorie URL (dle reputacni sluzby nebo vlastni), podle user-agenta, podle detekce typu provozu (streaming), a to v kombinaci s identifikaci lokalniho uzivatele (ip, username), nebo i nacitanim z online API od duveryhodneho partnera (MS takhle pres API live publikuje IP jednotlivych svych cloud sluzeb).
Stavajici technologie proxy to podporuji , takze desifrovat vse, co desifrovat lze. Vetsina internetoveho provozu totiz bohuzel opravdu zmigrovala z tcp o vrstvu vys do https, vcetne utocniku, zatimco klienti mnohdy zustali bez ochrany (i pred ochranou a smirovacimi javascripty, coz ovsem Google maximalne vyhovuje)
Tak za prve, cela saskarna s sifrovanim info, ktera vubec netreba sifrovat
Zřejmě myslíte TLS. Jenže TLS nezajišťuje jenom šifrování, ale také integritu dat. A integritu dat je potřeba zajistit u všech přenášených dat. Pokud by pro vás nějaká data byla tak nezajímavá, že nevadí, když je někdo cestou změní, nepotřebujete ta data vůbec.
Z pohledu uzivatele, tomu je jedno, kdo mu do webovych stranek vklada bordel
Není to jedno. Třeba u banky se dá předpokládat, že skripty na těžbu kryptoměn do internetového bankovnictví dávat nebude.
Co takovy certifikat prokazuje ?
Že má dotyčný přístup na server. Není to mnoho, ale pro spoustu webů to stačí.
Potreba desifrace v ramci firem je enormni.
Já bych to nenazýval „potřeba“. Prostě se to dělá takhle špatně, i když mnozí vědí, že je to špatně.
Desifrace se da on-fly vypnout
Což ale vůbec neřeší ten problém. Problém je, že se neustále snažíte vychovávat uživatele, že mají být ostražití a kontrolovat, zda opravdu komunikují s tím, s kým si myslí, že komunikují – a vzápětí jim řeknete, že komunikovat s někým jiným, než s kým chtěli, je vlastně úplně normální, a někdo to ověřil za ně.
MS takhle pres API live publikuje IP jednotlivych svych cloud sluzeb
To byla původní idea Microsoftu – že se nikdo nebude připojovat do celosvětového otevřeného internetu, ale do celosvětové privátní sítě Microsoftu MSN. Naštěstí Microsoft nebyl úspěšný. A většina lidí je ráda, většina lidí nechce, aby se internet redukoval na síť, kterou se mohou klienti připojit k velké čtyřce.
(i pred ochranou a smirovacimi javascripty, coz ovsem Google maximalne vyhovuje
Protože šmírovat mohou jenom ti správní, třeba firemní IT.