Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: czechsys 22. 05. 2020, 13:03:23
-
Ahoj,
nekdo z dns fundovanejsich - jak je to v soucasnosti s pohledem na existenci internich domen/ip adres ve verejnem dns?
Z hlediska ipv4 je to jednoduche, provozujeme interni servery, takze ve verejnem dns se to neobjevi. Pokud ale zacnu kombinovat s ipv6...
Problem nastava s ipv6. Protoze adresa muze byt pouzita jako verejna ci neverejna (blokace firewallem). Ano, muzu si urcit jednu /56 jako verejne pristupnou, druhou /56 jako privatni pouziti, ale drive nebo pozdeji narazim na to, ze privatni sluzba ma byt verejnou, takze mam dve moznosti - jen nastavit firewall, nebo presunout sluzbu na verejnou ip z /56. Coz s sebou zase obnasi ruzna rizika, ze server je najednou v ruznych zonach, v kterych byt nemel (napr. prime propojeni typu "dmz" s "intranet" siti). Taktez to znamena pripadny provoz jako u ipv4 - jedny authoritative pro verejne, druhe pro privatni domeny, vcetne toho, ze to musi resit i resolvery, na co se maji pripojovat.
Navic nase servery nebezi na bindu, takze view se nepouzivaji. Authoritative servery jiz neumoznuji blokovat interni domeny na zaklade ip adresy zdroje...
Nazory? Diky.
-
Pokud máte tu možnost, dával bych vše do veřejné DNS. Pak můžete třeba bez problémů vystavovat důvěryhodné certifikáty přes ACME (Let's Encrypt). Můžete zvážit filtrování a záznamy o privátních zařízeních používat jen v interní síti a nepublikovat je ven, ale připadá mi to jako zbytečná komplikace.
-
Na IPv6 není dobrý postup rozlišovat privátní / veřejné adresy. Všechny adresy jsou veřejné a o prostupy se musí starat firewall. Správa se dá částečně ulehčit pomocí stateful dhcpv6 - ale bacha, dhcpv6 je úplně něco jiného než dhcp pro ipv4. Pak si můžete nastavit do kterého rozsahu padají které počítače a na firewallu to odlišit. Prostou rekonfigurací dhcp pak dostanete počítač do jiné části prostoru. Když to propojíte i s DNS, pak už není vlastně žádný problém takové změny provádět.
-
Servery, co jsou určené jen pro vnitřek, tak máme na IPv6 ULA adresách (fc00::/7) a jsou zavedeny jen v interním DNS. Servery, co jsou dostupné z venku (a občas i zevnitř) nebo mají právo navazovat přímo spojení ven do Internetu, tak mají klasické IPv6 globální adresy a jsou identicky vedeny ve veřejném i interním DNS. U IPv4 to máme stejně. A samozřejmě je to v různých VLAN (DMZ), odděleno firewally.
I stanice uvnitř mají jen IPv6 ULA adresy (spojení ven je možná pouze skrz aplikační proxiny).
-
Pokud máte tu možnost, dával bych vše do veřejné DNS. Pak můžete třeba bez problémů vystavovat důvěryhodné certifikáty přes ACME (Let's Encrypt). Můžete zvážit filtrování a záznamy o privátních zařízeních používat jen v interní síti a nepublikovat je ven, ale připadá mi to jako zbytečná komplikace.
ACME bych do toho netahal, to ma svy problemy s nasazenim azaz. To filtrovani si predstavujete jak?
-
Servery, co jsou určené jen pro vnitřek, tak máme na IPv6 ULA adresách (fc00::/7) a jsou zavedeny jen v interním DNS. Servery, co jsou dostupné z venku (a občas i zevnitř) nebo mají právo navazovat přímo spojení ven do Internetu, tak mají klasické IPv6 globální adresy a jsou identicky vedeny ve veřejném i interním DNS. U IPv4 to máme stejně. A samozřejmě je to v různých VLAN (DMZ), odděleno firewally.
I stanice uvnitř mají jen IPv6 ULA adresy (spojení ven je možná pouze skrz aplikační proxiny).
No to je prave ono. Kvuli historii (bind s views) musim vest duplicitne jednu zonu v public i internim auth serveru. Kazdy asi tusi, jaky je to problem. Jak pak resite treba subdomeny?
priklad s ipv4:
server mel rfc1918 adresu s domenou host.sub.domain.tld. Nasmerovano na private auth. Problem solved
priklad s ipv6 (ipv4 hosti stale existuji):
server ma nyni ipv6 s host.sub.domain.tld
Pokud na resolveru nasmeruji sub.domain.tld na interni authoritative (protoze ipv4), tak se v kombinaci s ipv6 stane co?
Duplikace ipv6 adres pro tu sub.domaint.tld na public/private auth serveru... Navic u nas se zatim rozhodlo ULA nepouzivat - aby se nemuselo zase vsechno tahat pres nat/proxy.
Realne mi jde zhruba o tohle:
1] v public jsou rfc1918 ip4 -> je snadne ziskat ip/fqdn vsech ipv4 hostu v relativne kratkem case
2] v pripade ipv6 je 1] skoro nemozna, ale par info o nekterych siti se tim ziskat da
-
To filtrovani si predstavujete jak?
Filtrováním jsem myslel dvě různé zóny pro jednu doménu. Jenda se používá pro dotazy z venku, druhá pro dotazy zevnitř. Mohou to být třeba dva různé servery nebo Bind views. Ale osobně si myslím, že je to zbytečná práce na víc, potenciální zdroj chyb, a užitek prakticky žádný. Pokud se někdo venku dozví interní doménové jméno, může si ho přeložit na IP adresu. No a co?
-
Pokud se někdo venku dozví interní doménové jméno, může si ho přeložit na IP adresu. No a co?
A-ckove zaznamy, OK. Ale SRV mozu byt problem. Nikto nepotrebuje, aby mu ludia zvonku robili query na _ldap._tcp alebo _kerberos._udp a potom sustredovali svoju pozornost na tieto stroje.
-
A-ckove zaznamy, OK. Ale SRV mozu byt problem. Nikto nepotrebuje, aby mu ludia zvonku robili query na _ldap._tcp alebo _kerberos._udp a potom sustredovali svoju pozornost na tieto stroje.
Ty stroje musí být chráněné lépe než tím, že nikdo nepřečte jejich adresu z DNS.
-
A-ckove zaznamy, OK. Ale SRV mozu byt problem. Nikto nepotrebuje, aby mu ludia zvonku robili query na _ldap._tcp alebo _kerberos._udp a potom sustredovali svoju pozornost na tieto stroje.
Ty stroje musí být chráněné lépe než tím, že nikdo nepřečte jejich adresu z DNS.
Iste ze musia byt aj inac chranene, ale naco zbytocne davat utocnikom dieliky do skladacky?
-
Iste ze musia byt aj inac chranene, ale naco zbytocne davat utocnikom dieliky do skladacky?
Protože to není dílek do skládačky, ale něco mnohem menšího. A protože nedávat útočníkům tu informaci je zbytečně komplikované, vede to k problémům a chybám a nakonec to může vést k mnohem větším bezpečnostním dírám.
-
Add to dvoje DNS, jasný, když k tomu nemám vhodný automatizační nástorj, tak je to na palici mít dvě oddělené DNS. Navíc u některých věcí je problém, pokud mám ve veřejném DNS jeden stroj s veřejnou IP a v interním je s vnitřní. Někteří klienti, co migrují mezi vnitřkem a vnějškem, tak to blbě nesou (ne vždy zcela korektně flushují DNS cache). Takže u takových strjů máme vždy stejné veřejné IPv4/6 v obojím DNS.
K tomu dávat neveřejné IP (RFC1918 a spol) do veřejného DNS. Nepřehánět, snadno tak sami na sebe můžete dnes udělat atentát. Dneska řada ISP neprovozuje svoje rekurzivní DNS servery, využívá dodaných služeb někoho dalšího, kdo dodává služby DNS resolvingu, včetně filtrování, ochran před útoky a další bla bla bla (a tím nemyslím přesměrování DNS na 8.8.8.8/1.1.1.1). A pokud používají službu subjektu, který je schopen začít celou doménu dropovat proto, že v ní potkal pár 10.x.y.z, tak doména dokáže zmizet pro slušnou řádku přípojek (pokud využívají DNS od svého operátora). Výborná obdoba blacklistů pro SMTP a spol, s podobným důsledkem, zabalená do těch "nejlepších úmyslů". :-)
-
A pokud používají službu subjektu, který je schopen začít celou doménu dropovat proto, že v ní potkal pár 10.x.y.z, tak doména dokáže zmizet pro slušnou řádku přípojek (pokud využívají DNS od svého operátora).
Mohl byste být konkrétní, kdo něco takového dělá?
Vím, že ODVR CZ.NICu blokují odpovědi s IPv4 adresami z privátních rozsahů, ale týká se to snad jen těch konkrétních odpovědí. I tak mi to připadá za hranou toho, co by měl ODVR dělat (pokud to není speciální funkce, kterou si uživatel může „zapnout“). Google, Cloudfare ani IBM pokud vím IPv4 adresy z privátních rozsahů neřeší.
Mimochodem, pak se divíme, že lidé čím dál víc používají Google, Cloudflare nebo IBM, že se vymýšlejí „hlouposti“ jako DNS over HTTPS. Bodejť by ne, když někdo iniciativně rozbije fungování sítě, lidé si najdou cestičky, jak to obejít.
-
Jeste zvazuji neco jako dnsdist (dns balancer) https://dnsdist.org/reference/dnsnameset.html
Momentalne mam k dispozici konfiguraci, ktera podle src IP posila na rekurzor nebo auth server. Ja bych si predstavoval predrazeni pred auth server s timto prubehem:
a] definice internich domen a in-addr.arpa
b] pokud jde request na a]:
b1] jsi z povolenych src ip -> predam na auth server
b] nejsi z povolenych src ip -> deny/nxdomain
c] pokud jde request na cokoli z mimo a] -> predam na auth server
Chovalo by se to podobne jako ACL v rekurzoru. Zna kdyztak nekdo neco obdobneho?
-
Pozor na to, že když budete vkládat „mezi“ cokoli chytřejšího, co bude i samo odpovídat, rozbije vám to DNSSEC. I pokud ještě DNSSEC na doméně nemáte, nevymýšlel bych teď řešení, které v budoucnu zabrání jeho nasazení.
-
A pokud používají službu subjektu, který je schopen začít celou doménu dropovat proto, že v ní potkal pár 10.x.y.z, tak doména dokáže zmizet pro slušnou řádku přípojek (pokud využívají DNS od svého operátora).
Mohl byste být konkrétní, kdo něco takového dělá?
Z ISPíka kolega nevyrazil, koho konkrétně používá. Díval jsem se, že v Česku je vidět cca 3 až 5 firem, co tu nabízí takováto profi DNS řešení jako službu. A jak jsem pochopil, dostat se na u nich na DNS blacklist je ještě jednodušší, než na mail SPAM list.
Nejvíce je asi vidět Whalebone.
-
Z ISPíka kolega nevyrazil, koho konkrétně používá. Díval jsem se, že v Česku je vidět cca 3 až 5 firem, co tu nabízí takováto profi DNS řešení jako službu. A jak jsem pochopil, dostat se na u nich na DNS blacklist je ještě jednodušší, než na mail SPAM list.
Po pravdě by mne víc zajímal ten ISP. Že někdo nabízí hloupou službu, to je jeho věc. Ale že to někdo kupuje a kazí tím internetovou přípojku svým zákazníkům, to by měla být pořádná ostuda.
Nejvíce je asi vidět Whalebone.
Ježišmarjá, jen jsem tam vlezl, vyskočil na mne popup kde je mimo jiné tohle: „A přináší vám DNS dodatečný zdroj příjmu?“ To ještě navíc unášejí neexistující domény?
Před pár lety jsem si říkal, že by to chtělo vytvořit blacklist SMTP serverů, které používají nesmyslné antispamové ochrany, a e-maily jim vůbec nedoručovat, když o ně nestojí. Zdá se, že by to takový blacklist chtělo i pro DNS resolvery, kde by to navíc účinkovalo velice rychle.
-
Daný ISP je už historie, respektive pohlcen firmou Starnet a nahrazeno jejich službami. Ta je asi jedna z mála, co provozuje vlastní plné resolvery.
Jinak podobné služby používá hodně ISP. Těch, co si to řeší ve vlastní režii, tak ubejvá. Pár nejmenších to řeší redirectem na Google a spol. Ty větší přestává bavit se o svoje rekurzory starat, tak skočí na nějakou takovou nabídku.
Apropo, třeba u O2 tomu familiárně říkají "pračka DNS". Aspoň dle slov technika, s kterým jsme něco řešili (a dle jeho slov je to nasazeno jen na rezidentní zákazníky, ne na business linky).
Whalebone asi neexistující fomény neunáší, to jsem nepostřehl. Spíše tím blábolem chce naznačit, že když služba nevydělává, tka ji za malý bakšiš můžou nakoupit jinde, než se s ní dřít.
Ale tohle je už dost jinde od původního dotazu...