Fórum Root.cz
Hlavní témata => Server => Téma založeno: pavel pavel 08. 04. 2016, 09:21:39
-
Mame zakladni bezpecnost a filtrovani kategorii URL na DNS serveru. Uzivateli se pri prekladu URL s malwarem ci zakazanou kategorii URL prelozi IP web sereveru s informaci o zakazu pristupu. Nyni by jsem potreboval dat uzivatelum moznost vytvaret si na dalsim DNS serveru vlastni black/list white list domen z webove aplikace. Tzn, pokud ma konkretni uzivatel=IP adresa v black listu konkretni domenu tak mu resolvne konkretni IP adresu webserveru kde je stranka se zakazem pristupu.
Kdyz ve white listu tak mu resolvne spravnou IP. Konfigurace white/black listu bude v databazi , ale predpokladam, ze by jsme dokazali menit konfiguiracni soubory DNS serveru.
Mate nekdo zkusenost s konfiguraci DNS z databaze ci uzitim black/white listu? Jaky DNS server by jste na tuto extremi konfiguraci dlasiho DNS serveru doporucily? Zatim uvazujem nad Knot resolverem a klasickym bind.
-
Mám zkušenost, že občas nějaký web používá HTTPS. Třeba Google, Seznam, banky – a těch webů je čím dál víc, a teď zrovna jsme v období, kdy se na HTTPS masivně přechází (tlačí na to autoři prohlížečů, Let's Encrypt umožňuje získat certifikát zdarma). Na jakémkoli webu s HTTPS ten váš únos spojení přes HTTPS nebude fungovat, protože místo informace o zákazu zobrazí prohlížeč chybu certifikátu.
Takže doporučuji opustit tohle neperspektivní řešení, dokud máte čas a webů s malwarem na HTTPS ještě není mnoho.
-
Dekuji za odpoved. jednou z vyhod reseni bezpecnosti na urovni DNS serveru je ze neni limitovano HTTPS protokolem. Preklad URL na IP kde filtrovani probiha je jeste pred zahajenim provozu HTTPS. Takze zminenou komplikaci HTTPS nase reseni na rozdil od jinych neni dotceno. :-)
-
Jak to, že není? Jak zařídíte, aby mi https://www.google.com ukázalo webovou stránku s informací o blokování a ne chybu certifikátu? Máte u klientů injektovanou vlastní CA kvůli man-in-the-middle útoku?
-
Preklad URL na IP kde filtrovani probiha je jeste pred zahajenim provozu HTTPS. Takze zminenou komplikaci HTTPS nase reseni na rozdil od jinych neni dotceno. :-)
No tak já nevím, četl jsi po sobě původní dotaz? Konkrétně:
"tak mu resolvne konkretni IP adresu webserveru kde je stranka se zakazem pristupu"
-
Na DNS server prijde pozadavek napr na sex.com. Protoze sex.com patri do zakazane kategori , DNS server resolvne misto IP adresy web serveru sex.com IP adresu naseho web serveru kde je jen hlaska sem nemas pristup. Uzivatel se na zakazany URL nedostane at jiz se mu v pripade HTTP zobrazi stranka webu rovnou ci potvrdi chybu certifikatu v pripade HTTPS -coz by samozrejme ale nemel :-) Ale oproti ostanim resenim kontroly HTTPS na aplikacni urovni jez musi de/kryptovat mi toto reseni prijde zlate.
-
Na DNS server prijde pozadavek napr na sex.com. Protoze sex.com patri do zakazane kategori , DNS server resolvne misto IP adresy web serveru sex.com IP adresu naseho web serveru kde je jen hlaska sem nemas pristup. Uzivatel se na zakazany URL nedostane at jiz se mu v pripade HTTP zobrazi stranka webu rovnou ci potvrdi chybu certifikatu v pripade HTTPS -coz by samozrejme ale nemel :-) Ale oproti ostanim resenim kontroly HTTPS na aplikacni urovni jez musi de/kryptovat mi toto reseni prijde zlate.
Já myslím, že stačí nasadit cokoliv, co šéfstvo schválí a kdo chce mít normální internet, ať si nastaví nerozbité DNS servery. Nevidím důvod nad přihlouplou buzerativní technikou trávit víc času než je nezbytně nutné.
-
Uzivatel se na zakazany URL nedostane
Ano, to je jediné, na čem se shodneme.
potvrdi chybu certifikatu v pripade HTTPS -coz by samozrejme ale nemel
Což by neměl, ale proč by ho to IT oddělení nemohlo naučit, že. Správně by uživatel neměl v takovém případě odkliknout certifikát, ale měl by místo toho kontaktovat IT oddělení s tím, že došlo k bezpečnostnímu incidentu a někdo se pokusil zaútočit na jeho prohlížeč. Jestli to chcete neustále řešit…
Navíc v případě, že doména používá DNSSEC, uživatel nezíská vůbec žádnou DNS odpověď.
Ale oproti ostanim resenim kontroly HTTPS na aplikacni urovni jez musi de/kryptovat mi toto reseni prijde zlate.
Pokud je vaším cílem to, aby uživatelé kašlali na bezpečnost, pak jistě. V opačném případě je problém už v tom „řešení kontroly HTTPS“, protože to žádné řešení není.
-
Bohuzel jsme se zatim ani nepriblizily tematu: Mate nekdo zkusenost s konfiguraci DNS z databaze ci uzitim black/white listu? Jaky DNS server by jste na tuto extremi konfiguraci dlasiho DNS serveru doporucily? Zatim uvazujem nad Knot resolverem a klasickym bind.
Navrzeneho reseni je i z pohledu edukace uzivatelu korektni - chyba certifikatu proste tam nelez at jiz je duvod jakkykoliv. Muzeme rici uzivatelum aby neignorovali chybu certifikatu a ze stranky s chybou certifikatu odesly. Ale at nase doporuceni budou ignorovat ci nikoliv na stranku na ktereou by se z objektivniho duvodu nemeli dostat se nedostanou, coz je cilem. Proste chyba certifikatu je spatne at je duvod jakkykoliv.
-
Bohuzel jsme se zatim ani nepriblizily tematu: Mate nekdo zkusenost s konfiguraci DNS z databaze ci uzitim black/white listu? Jaky DNS server by jste na tuto extremi konfiguraci dlasiho DNS serveru doporucily? Zatim uvazujem nad Knot resolverem a klasickym bind.
Zbytečně komplikovaný monstra; dnsmasq to umí, unbound to umí taky.
-
Jaky DNS server by jste na tuto extremi konfiguraci dlasiho DNS serveru doporucily? Zatim uvazujem nad Knot resolverem a klasickym bind.
Co je na tom extrémního? A proč chcete používat dva DNS servery? Použijte libovolný DNS resolver – Knot DNS Resolver, Unbound, Dnsmasq…
Navrzeneho reseni je i z pohledu edukace uzivatelu korektni - chyba certifikatu proste tam nelez at jiz je duvod jakkykoliv. Muzeme rici uzivatelum aby neignorovali chybu certifikatu a ze stranky s chybou certifikatu odesly. Ale at nase doporuceni budou ignorovat ci nikoliv na stranku na ktereou by se z objektivniho duvodu nemeli dostat se nedostanou, coz je cilem. Proste chyba certifikatu je spatne at je duvod jakkykoliv.
To ale vycházíte z mylného předpokladu, že uživatel nemá co dělat, a tak jen tak zadává do prohlížeče adresy – a když se na nějakou nedostane, zkusí jinou. Jenže ve skutečnosti uživatel jde na tu stránku s nějakým cílem, který odejitím kvůli chybnému certifikátu není splněn. Takže uživatel se bude pokoušet tam stejně dostat, případně bude zjišťovat, kde je problém.