Privátní adresy ve veřejném DNS, knot-resolver a apple.com

[pcmonkey]

Ahoj všem,

chtěl bych se podělit o jednu nepříjemnou zkušenost z počátku tohoto týdne. Zřejmě v souvislosti s novym iOS release upravil Apple DNS tak, ze v NS záznamy ess.apple.com směřují na privátní adresy dle RFC1918. Stalo se tak 16.9. cca v 1:20.

dig -4  +trace ns ess.apple.com.

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -4 +trace ns ess.apple.com.

---cut ---
ess.apple.com.          43200   IN      NS      a.ns.apple.com.
ess.apple.com.          43200   IN      NS      b.ns.apple.com.
ess.apple.com.          43200   IN      NS      c.ns.apple.com.
ess.apple.com.          43200   IN      NS      d.ns.apple.com.
ess.apple.com.          43200   IN      NS      usmsc2-extxfr-001.dns.apple.com.
ess.apple.com.          43200   IN      NS      mressext-axfrdnsvip.mr.if.apple.com.
ess.apple.com.          43200   IN      NS      pvessext-axfrdnsvip.pv.if.apple.com.
ess.apple.com.          43200   IN      NS      stessext-axfrdnsvip.st.if.apple.com.
;; Received 499 bytes from 204.19.119.1#53(c.ns.apple.com) in 8 ms

;; communications error to 10.52.192.140#53: timed out
;; communications error to 10.52.192.140#53: timed out
;; communications error to 10.52.192.140#53: timed out
ess.apple.com.          43200   IN      NS      a.ns.apple.com.
ess.apple.com.          43200   IN      NS      b.ns.apple.com.
ess.apple.com.          43200   IN      NS      c.ns.apple.com.
ess.apple.com.          43200   IN      NS      d.ns.apple.com.
ess.apple.com.          43200   IN      NS      usmsc2-extxfr-001.dns.apple.com.
ess.apple.com.          43200   IN      NS      mressext-axfrdnsvip.mr.if.apple.com.
ess.apple.com.          43200   IN      NS      pvessext-axfrdnsvip.pv.if.apple.com.
ess.apple.com.          43200   IN      NS      stessext-axfrdnsvip.st.if.apple.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 499 bytes from 204.19.119.1#53(c.ns.apple.com) in 8 ms

;; communications error to 10.52.200.235#53: timed out
ess.apple.com.          300     IN      NS      a.ns.apple.com.
ess.apple.com.          300     IN      NS      b.ns.apple.com.
ess.apple.com.          300     IN      NS      c.ns.apple.com.
ess.apple.com.          300     IN      NS      d.ns.apple.com.
;; Received 137 bytes from 17.253.207.1#53(b.ns.apple.com) in 8 ms



Ty tři poslední NS pro ess.apple.com jsou na privátních adresách. Smutné...

Pokud používáte knot-resolver a máte zapnutý dns rebinding protection - modules.load('rebinding < iterate'), knot-resolver, přestoze vlatní výsledek rezoluce nevede na privátní adresu, posílá REFUSED (rcode 5).

Pokud máte vytíženější DNS resolvery, vede to k masivní amplifikaci provozu. Apple klienti to pak zkoušejí stále dokola. Unbound toto zresolví.

A.

[Reklama]

[Filip Jirsák]

Podle mne to doporučení, že by ve veřejném DNS neměly být záznamy vedoucí na IP adresy z privátních rozsahů, neodpovídá dnešní realitě. To mělo smysl v době, kdy se ty IP adresy používaly opravdu pro privátní sítě. Ale dnes se masivně používají pro sítě, které by chtěly být v internetu, ale není pro ně dostatek IPv4 adres, takže se to flikuje NATem. Do toho se používá DNSSEC, je tlak na používání důvěryhodných certifikátů – což je vše v pořádku. A to omezení se holt do tohoto světa nehodí.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

A ty jako pingneš 10.52.192.140? Kdo pingne,ať hodí routerem.
Tak to jejich dns nepoužívej 

[pcmonkey]

Podle mne to doporučení, že by ve veřejném DNS neměly být záznamy vedoucí na IP adresy z privátních rozsahů, neodpovídá dnešní realitě. To mělo smysl v době, kdy se ty IP adresy používaly opravdu pro privátní sítě. Ale dnes se masivně používají pro sítě, které by chtěly být v internetu, ale není pro ně dostatek IPv4 adres, takže se to flikuje NATem. Do toho se používá DNSSEC, je tlak na používání důvěryhodných certifikátů – což je vše v pořádku. A to omezení se holt do tohoto světa nehodí.

S tím nemohu souhlasit. Vede to jen k potížím, nežádoucímu provozu v sítích a pod. Navíc, v tomto případě nechápu, čeho tím chteli docílit. Je to zcela nefunkční věc a DNS to rozbíjí.

[skrivy]

My třeba používáme interní adresy ve veřejném DNS cíleně:
 - Servery často máme dual-stackové a tak jsou alespoň po IPv6 stejně dostupné.
 - Experimenty prohlížečů s DOH a dalšími novinkami nám zvedly množství problémů uživatelů s nedostupností služeb.
 - [souvisejicí] Všechny http služby už stejně jedou na https a chceme tam validní SSL certifikát

Interní DNS jsme tedy kompletně zlikvidovali, používáme jen veřejné domény a zmizela nám další věc, která v infrastruktuře může dělat problémy. Ono to vytvořilo jiné, ale o tom zas jindy.

Jako bonus tím snižujeme možnost sledování aktivity uživatelů a uživatelé ať si používají DNS resolvery jaké chtějí.

[Reklama]

[Filip Jirsák]

Vede to jen k potížím, nežádoucímu provozu v sítích a pod.

K potížím vede filtrace. Pak máte zařízení, které přechází mezi internetem a vnitřní sítí, na internetu si nakešuje, že daný DNS záznam neexistuje, pak se to zařízení dostane do vnitřní sítě a musí se čekat, než ten negativní záznam v DNS cache přestane platit. I v té vnitřní síti jste závislý na tom, že se DNS překládá přes interní DNS resolvery v té síti, že se to nepřekládá třeba přes DoH. Přičemž ta vnitřní síť nemusí být nutně nějaká interní firemní síť. Může to být veřejná WiFi ve vlaku, na konferenci, ve škole…

Pokud se IPv4 adresy z privátních rozsahů používají místo veřejných IP adres, nezbývá, než se tomu přizpůsobit i v DNS.

Navíc, v tomto případě nechápu, čeho tím chteli docílit. Je to zcela nefunkční věc a DNS to rozbíjí.

Tomu také nerozumím, spíš mi to připadá jako chyba.

[pcmonkey]

K potížím vede filtrace. Pak máte zařízení, které přechází mezi internetem a vnitřní sítí, na internetu si nakešuje, že daný DNS záznam neexistuje, pak se to zařízení dostane do vnitřní sítě a musí se čekat, než ten negativní záznam v DNS cache přestane platit. I v té vnitřní síti jste závislý na tom, že se DNS překládá přes interní DNS resolvery v té síti, že se to nepřekládá třeba přes DoH. Přičemž ta vnitřní síť nemusí být nutně nějaká interní firemní síť. Může to být veřejná WiFi ve vlaku, na konferenci, ve škole…

Pokud se IPv4 adresy z privátních rozsahů používají místo veřejných IP adres, nezbývá, než se tomu přizpůsobit i v DNS.

Nerozumím, jak použití privátní IP v DNS ten problém vyřeší. Pokud takové zařízení přejde do veřejné sítě a bude mít nakešovánu privátní IP, bude mít stejný problém. A navíc bude generovat provoz, který se zahodí.

Navíc, v tomto případě nechápu, čeho tím chteli docílit. Je to zcela nefunkční věc a DNS to rozbíjí.

Tomu také nerozumím, spíš mi to připadá jako chyba.
[/quote]
Snad.

[Filip Jirsák]

Nerozumím, jak použití privátní IP v DNS ten problém vyřeší. Pokud takové zařízení přejde do veřejné sítě a bude mít nakešovánu privátní IP, bude mít stejný problém. A navíc bude generovat provoz, který se zahodí.

Problém to vyřeší jednoduše. Když bude zařízení v interní síti, dostane se na daný server, bez ohledu na to, jestli má nakešované DNS informace z doby, kdy bylo na veřejné síti, používá DoH, používá čtyři jedničky, osmičky nebo devítky nebo cokoli jiného.

Když bude zařízení mimo interní síť, na ten interní server se stejně nedostane, a je to problém nedostatku IPv4 adres. Privátní adresy v DNS to nijak nezhorší.

Ke generování provozu, který se zahodí – ten jeden paket pokoušející se navázat TCP/IP spojení (případně dva nebo tři, když klient nedostane REJECT a zkusí to znovu) snad síť nepoloží…

[_Jenda]

Navíc, v tomto případě nechápu, čeho tím chteli docílit.

Je to naznačené v prvním příspěvku: DNS rebinding attack.

Uživatel má ve vnitřní síti za NATem a firewallem děravou ledničku s IP adresou 192.168.0.10, nebo na localhostu spuštěnou službu, která přijímá obecné příkazy komukoli kdo se připojí. Uživatel si myslí, že to nevadí, protože do vnitřní sítě se mu nikdo nedostane, a na počítači je sám, takže se mu na localhost nemá kdo připojovat.

Uživatel vleze na evil.com. evil.com|91.213.160.188 s TTL=10 stáhne javascript. Tento javascript se nemůže přímo připojit na 192.168.0.10 ani 127.0.0.1 protože nějaká same origin policy nebo co. Může se ale připojit na evil.com. Ale evil.com má malé TTL a DNS server, který za 10 sekund vrátí jako IP 192.168.0.10 nebo 127.0.0.1. Prohlížeč si myslí že se tam tedy může připojit a javascript se připojí k děravé ledničce a komunikuje s ní.

Díky websockets a různým speciálním hlavičkám dokonce ten exploit nemusí ani běžet po HTTP, ale může emulovat jiné protokoly. Tady je třeba RCE v OpenOCD, které objevil kamarád.

[Filip Jirsák]

Navíc, v tomto případě nechápu, čeho tím chteli docílit.

Je to naznačené v prvním příspěvku: DNS rebinding attack.

Ta otázka byla na to, čeho chce Apple docílit tím, že mezi jmennými servery uvádí

• mressext-axfrdnsvip.mr.if.apple.com
• pvessext-axfrdnsvip.pv.if.apple.com
• stessext-axfrdnsvip.st.if.apple.com

které se překládají na IPv4 adresy z privátního rozsahu 10.0.0.0/8.

[Vantomas]

Já tam ty neveřejný NS záznamy nevidím. To možná Applu leaklo něco interního do public DNS. I podle těch jmen to vypadá, že je to něco z nějaké vnitřní infrastruktury.

Kód: [Vybrat]

vantomas@tomovo-macbook:~$ dig ns ess.apple.com

; <<>> DiG 9.10.6 <<>> ns ess.apple.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49870
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ess.apple.com. IN NS

;; ANSWER SECTION:
ess.apple.com. 176 IN NS d.ns.apple.com.
ess.apple.com. 176 IN NS a.ns.apple.com.
ess.apple.com. 176 IN NS b.ns.apple.com.
ess.apple.com. 176 IN NS c.ns.apple.com.

;; Query time: 19 msec
;; SERVER: 10.88.1.2#53(10.88.1.2)
;; WHEN: Fri Sep 20 22:05:03 CEST 2024
;; MSG SIZE  rcvd: 109



Kód: [Vybrat]

vantomas@tomovo-macbook:~$ dig ns ess.apple.com @8.8.8.8

; <<>> DiG 9.10.6 <<>> ns ess.apple.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46940
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ess.apple.com. IN NS

;; ANSWER SECTION:
ess.apple.com. 300 IN NS d.ns.apple.com.
ess.apple.com. 300 IN NS a.ns.apple.com.
ess.apple.com. 300 IN NS c.ns.apple.com.
ess.apple.com. 300 IN NS b.ns.apple.com.

;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 20 22:05:07 CEST 2024
;; MSG SIZE  rcvd: 109


Kód: [Vybrat]

vantomas@tomovo-macbook:~$ dig ns ess.apple.com @1.1.1.1

; <<>> DiG 9.10.6 <<>> ns ess.apple.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20563
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ess.apple.com. IN NS

;; ANSWER SECTION:
ess.apple.com. 300 IN NS a.ns.apple.com.
ess.apple.com. 300 IN NS b.ns.apple.com.
ess.apple.com. 300 IN NS c.ns.apple.com.
ess.apple.com. 300 IN NS d.ns.apple.com.

;; Query time: 13 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Sep 20 22:05:10 CEST 2024
;; MSG SIZE  rcvd: 109



[Filip Jirsák]

Já už je tam také nevidím. Ale když jsem psal předchozí komentář, ještě tam byly. Nejspíš to tedy opravdu byla chyba.

[pcmonkey]

Já už je tam také nevidím. Ale když jsem psal předchozí komentář, ještě tam byly. Nejspíš to tedy opravdu byla chyba.

Ozval se mi hostmaster z apple.com a potvrdil opravu.