IMHO, myslim, ze to moc fungovat nebude. Plno mlawaru jde na pevne IPcka, a pak je DNS subsytem vynechany. Muze to pomoct pro filtraci "nevhodneho" obsahu na webu, ale vice se ocekavat neda. A i toto je s otaznikem, protoze neni uvedeno, jakou metodou se zjistuji "nevhodne" domeny. Taky to uz nerozlisuje, jestli neco zavadneho se stahuje ze server na kterem je z 99.9% validni obsah. Prikladem muze byt ulozeny
malware na nejakem ulozisti. System umi blokovat bud cele uloziste, nebo pustit vse, rozhodne neumi blokovat jednotlive web stranky.
Honza
Tyhle projekty uz na mne zacinaji pusobit jako projekty EU - osmsetpadesatapata cyklostezka, tisicctyristadvacatesedme lanove centrum, petsetdevadesatetreti datove centrum...
Tesim se, az v Brne vymysli neco skutecne inovativniho jako to byvalo pred mnoha lety.
Ono taky většina těhle projektů je nějak dotovaná, buď žijí v nějakém univerzitním inkubátoru placeném z našich daní, nebo jedou přímo EU dotace a tak to jsou dost často takové nové objevy již objeveného v novém marktingovém přebalu.
Cílem totiž není ani tak udělat produkt a vydělat peníze jako v souladu s žádostí vyčerpat grant.
Poznámka o hardcoded IP adresách v malwaru je relevantní a použití hardcoded adres samozřejmě znemožní detekci na úrovni DNS překladu.
Při návrhu služby jsme ale vzali v potaz několik fází životního cyklu malwaru (exploitace, stažení těla malwaru, komunikace s c&c serverem) a pro malware může být fatální přerušení kterékoliv z nich, čímž se pravděpodobnost zapojení DNS výrazně zvyšuje.
Ruku v ruce s tím jdou studie, které potvrzují nárůst využití doménových jmen oproti hardcoded IP (bohužel se mi nepodařilo dohledat konkrétní čísla, která by to dokládala jasněji). Důvody tvůrců malwaru jsou zřejmé, mít větší možnost s vlastní infrastrukturou pohybovat a udržet tak své dílo déle naživu.
https://www.damballa.com/identifying-parking-ip-infrastructure-understanding-malware-evolution-and-the-implications-on-data-modeling/
http://anubis.seclab.tuwien.ac.at/papers/squeeze_acsac11.pdf
Do využití doménových jmen tlačí tvůrce malwaru i aktuální trend endpoint bezpečnostních řešení a sandboxů, které při vyhodnocování chování potenciálního malwaru sledují i to, zda se proces připojuje na konkrétní IP, aniž by si ji předem přeložil skrze DNS.
Robert Šefr
https://whalebone.io/
DNSSEC i HPKP (nebo i samostatné https) vnímáme jako velmi důležité bezpečnostní mechanismy, které nechceme obcházet a generovat tak zranitelnosti v ověřování autenticity a integrity (např. tak, že bychom někomu nutili přidání důvěry naší certifikační autority) na úkor našeho řešení.
Oba zmíněné protokoly jsou pro nás důležité ve chvíli, kdy chceme uživateli zobrazit varování a některý z protokolů je využit. Varování o závadné doméně bude z pohledu uživatele výjimečná situace a bude závislé na konfiguraci služby pro danou síť. Za takových okolností nebude možné zobrazit srozumitelné varování (ale administrátor může být na situaci upozorněn).
Rád bych ještě zmínil, že se jedná o situaci, kdy uživatel přistupuje na závadnou doménu z browseru přímo. Pokud Whalebone zablokuje načtení závadného iframu, nedovolí komunikaci podvrženému skriptu nebo zablokuje komunikaci s c&c serverem, tak uživatel rozdíl pravděpodobně ani nezaznamená.
Robert Šefr
https://whalebone.io/
No právě. Uživatel bude chtít jít na https://www.napadenyweb.cz. DNS s tímhle udělátkem vrátí IP stroje, kde mu to má říct, že je tam malware. Prohlížeč se tedy spojí přes HTTPS na počítač na tom IP, ale ten podepsaný certifikát pro www.napadenyweb.cz mít nebude.
Leda by tohle řešení obsahovalo i CA, jejíž certifikát by si člověk musel nainstalovat.
Ako start dobre, ale ako tu uz bolo zmienene na DNS sa neda toho moc odfiltrovat.
BTW aj toto sa vyvija v Brne - https://www.wandera.com/
nebude, https certifikáty jsou převážně vázány pouze na doménu, na ip se běžně nepoužívají a ani to ani často žádoucí.
Bude to mít ale problém s DNSSec, nedával jsem ale dostatečný pozor a teď nevím, jestli vrací jinou IP adresu, což by mělo právě problém s DNSSec validací nebo vrací, že záznam je nenalezen.
Podle obrazku v clanku to vypada, ze presmeruji odpoved na jine IP, kde se zobrazi napr. varovani. Takze DNSSEC asi bude taktez problem. Ale treba to bude vyreseno, pokud cilova domena pouziva DNSSEC, vrati se v odpovedi neexistujici zaznam.
Certifikat by tomu vadit asi nemel (v nejhorsim napise prohlizec, ze je certifikat serveru invalid...). DNS dotazy se resi jeste pred navazanim HTTP ci HTTPS spojeni. Melo by to asi fungovat tak, ze klient posle DNS dotaz (do toho Whalebone) na adresu, kam se chce klient pripojit. A pokud (Whalebone) bude mit v databazi (ze to domenove jmeno je malware sit), tak vrati v odpovedi klientovi IP adresu serveru, kde se na jakykoliv HTTP request rekne, ze je to malware sit. Nic slozityho bych za tim nehledal. Alespon z toho clanku to tak zni. Tohle zvladne bezny antivirak, teda ten toho zvladne mnohem vice, tohle je jen jednoduche k nasazeni.