Resolving domen z NS gransy.com po pondelnim hacku
Jan 'yanek' Bortl
yanek na yanek.cz
Úterý Září 22 01:20:10 CEST 2020
[zkousim preposlat znovu, neb se mail neobjevil ani po hodine v archivu]
Dobry vecer,
cely patek, cele dnesni odpoledne a ted vecer se v tom snazim zorientovat.
Nefunguje ani posledni verze bind9 9.17.5 dnes rucne a defaultne
zkompilovana. Unbound funguje. Knot-resolver udajne taky - to jsem neoveroval.
Napsal jsem si na to kratky script, kde se to vetsinou projevi i bez loadu
(bokem bez provozu od zakazniku je to obtizne navoditelne):
#!/bin/bash
IP=<ip_bindu>
DOMAIN=tiscali.cz
for i in `seq 1 50`; do
echo -n "$i: "
dig neexistujici$i.$DOMAIN @$IP | grep status
done
Pokud bude psat aspon jednou SERVFAIL, tak je tam problem (pripadne zvetsit
cislo 50 na vic, ale je to videt uz na prvnich dotazech).
Hloupe na tom je, ze neco zpusobi otraveni cache bindu a ten zacne odpovidat
SERVFAIL i na veci, ktere pred par vterinama jeste vedel. To se mi tedy dari
nasimulovat jen s netrivialnim zakaznickym provozem.
Nicmene k veci: patral jsem s hodne velkym debug levelem v bindu a zjistil
nasledujici... pokazde zustanu u tech servfailu trcet na takoveto hlasce:
21-Sep-2020 21:16:37.608 client @0x7f685c000c88 10.136.0.2#52073
(imap50.tiscali.cz): query failed (malformed OPT option) for
imap50.tiscali.cz/IN/A at query.c:6929
Tedy stejne co je videt i u vas. Ale dvakrat moudry z toho nejsem. Na
odpovedi ze serveru nevidim nic moc spatne. Mam z toho spis dojem, ze je tam
nejaka krpa v bindu jako takovem, ktera se projevuje v kombinaci s Gransy -
proc netusim.
Jen takovy vystrel do tmy behem psani tohoto emailu: mam dojem, ze problem
(uz jenom) delaji domeny pouzivajici DNSSEC s obstaroznim NSEC misto NSEC3
(nadruhou stranu napriklad o2.cz, ctu.cz funguji, ty jsou ale jinde). U
tiscali.cz a vami uvedene domeny unimagnet.cz i workhouse.cz vyse uvdeny
test vzdy selze (na cerstve pustenem bindu). U ostatnich domenach co maji
NSEC3 se mi to navodit dnes uz nepovedlo. V sobotu to jeste slo videt, ze je
to rozbite, ale to bylo nejspis zpusobene rozbityma NS na domene gransy.com,
pricemz dva z nich odpovidali REFUSED. To se jim nejspis uz povedlo vyresit
neb to dnes uz nevidim.
Jeste jsem nasel CVE-2016-2848 ktere resi rozbite OPT, mozna nejake voditko
dale.
Nejaky napad nekoho zkuseneho? Dovolil jsem si dat do kopie Ondreje Sureho,
treba bude umet ukazat prstem co je spatne at uz v Bindu nebo u Gransy.
Bavil jsem se v patek s Gransy a na svuj DNS frontend pouzivaji sve
"caching" reseni, takze muze byt problem i tam - nadruhou stranu s nahodnymi
SERVFAIL domenami se potkavam relativne casto napric celym internetem, kdy
vetsinou pomaha prave flush cache. Nicmene to nebylo doposud tak uplne
vyrazne caste, aby me to dostatecne trklo to nejak aktivne resit.
Dne 21. 09. 20 v 7:57 Adam Pribyl napsal(a):
> Zjistil jsem ze kdyz flushnu cache (rndc flush) tak to vetsinou chvili
> jde, nicmene prvni preklad adresy trva treba 2s.
> Prijde mi jako kdyz se pak nacachuje nejaka chyba a ta pak prevlada.
>
> Tady je nejaky timeline, kde pisi ze vcera gransy.com nejak posilovali,
> protoze s tim stale maji problemy, ale u nas to teda stale spis nejde nez
> jde:
>
> https://wladass.cz/subreg-hacknut-timeline/
>
>
> On Sun, 20 Sep 2020, Zdeněk Janiš wrote:
>
>> Máme KNOT Resolver a zdá se to OK:
>>
>> $ dig -t A www.unimagnet.cz @192.168.100.100
>>
>> ; <<>> DiG 9.16.6-Debian <<>> -t A www.unimagnet.cz @192.168.100.100
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45631
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;www.unimagnet.cz. IN A
>>
>> ;; ANSWER SECTION:
>> www.unimagnet.cz. 540 IN CNAME ingress.wpj.cloud.
>> ingress.wpj.cloud. 0 IN A 81.91.91.88
>> ingress.wpj.cloud. 0 IN A 81.91.91.89
>>
>> ;; Query time: 0 msec
>> ;; SERVER: 192.168.100.100#53(192.168.100.100)
>> ;; WHEN: Ne zář 20 22:47:54 CEST 2020
>> ;; MSG SIZE rcvd: 108
>>
>> Dne 20. 09. 20 v 9:59 Adam Pribyl napsal(a):
>>> Od te doby co v pondeli hackli subreg.cz/gransy.com nam nefunguje
>>> resolving domen, ktere jdou pres NS gransy.com. Zkousel jsem bind 9.8 a
>>> bind 9.11 (oboji debian) a proste resolving konci na servfail. Primy
>>> dotaz pres dig jde.
>>>
>>> Napr.
>>>
>>> dig www.unimagnet.cz @ns.gransy.com
>>>
>>> ale prostrednictvim naseho bindu ne. Pokud zvysim trace log v bindu pise
>>> to napr.
>>>
>>> rpz QNAME rewrite www.workhouse.cz via www.workhouse.cz stop on
>>> unrecognized qresult in rpz_rewrite()failed: : malformed OPT option
>>>
>>> DNS format error
>>>
>>> apod. Pouzivame DNSSEC, ale vypnuti nic nezmenilo.
>>>
>>> I googli DNS obcas vyhodi timeout na domenach z NS gransy.com.
>>>
>>> Pozoruje nekdo neco podobneho? (Samozrejme pokud provozujete svuj
>>> rekurzivni resolver.)
>>>
>>> Diky
>>>
>>> Adam Pribyl
>>
>> --
>> Zdeněk Janiš
>>
>
>
--
Jan 'yanek' Bortl <yanek [at] yanek. cz>
http://yanek.cz/
-----------------------------------------------------------------
"Maybe one day you will learn that your way is not the only way."
Opher [StarGate: The Nox]
Další informace o konferenci Linux