Resolving domen z NS gransy.com po pondelnim hacku
Jan 'yanek' Bortl
yanek na yanek.cz
Středa Září 23 15:41:28 CEST 2020
V Gransy vypnuli cookies a od te doby nevidim problemy kam az me oko dohledne.
Ono se zda, ze v ramci rekonstrukce systemu nasadili asi rovnou novejsi
verzi neceho (jen se domnivam, ale neco takoveho naznacovali). Jak tak na to
koukam, to asi nebyl dobry napad :-)
Jen by me skutecne zajimalo jestli to, ze to nechutnalo bindu je jeho bug,
nebo je bug ve vsech ostatnich resolverech, kterym to nevadilo... A jakou to
ma souvislost s temi NSEC zaznamy.
Dne 22. 09. 20 v 8:32 Adam Pribyl napsal(a):
> Diky, jsem rad, ze v tom nejsme sami, zajimalo by me kolik lidi s tim
> travy hodiny casu stejne bez vysledku...
>
> Je mozne, ze to je nejaky problem v bindu, nicmene pred hacknutim
> gransy.com s tim problemy nebyly, resp. nic co by bylo za bezneho provozu
> problem, takze to je nejaka "konjunktura" s tim, co tam ted uplacali.
>
> Ja nasel napr. tyto stare chyby se stejnymi priznaky:
> https://bugzilla.redhat.com/show_bug.cgi?id=1281484
> https://bugzilla.redhat.com/show_bug.cgi?id=807540
>
> minimalne ten prilozen patch v gitu bindu ale je.
>
> Ve zdrojacich bindu je jen
> "malformed OPT option", /*%< 113 DNS_R_OPTERR */
>
> pokud koukam po
> "stop on unrecognized qresult in rpz_rewrite"
>
> Jedine co z toho vykoukam je ze to v tento funkci propadne do nejake
> defaultni case.. komentar k funkci je
>
> "Look for response policy zone QNAME, NSIP, and NSDNAME rewriting."
> co to znamena netusim, popis te chyby zadny aby clovek aspon tusil kam
> smerovat.
>
>
> Adam Pribyl
>
>
> On Tue, 22 Sep 2020, Jan 'yanek' Bortl wrote:
>
>> [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