Resolving domen z NS gransy.com po pondelnim hacku

Adam Pribyl pribyl na lowlevel.cz
Středa Září 23 15:48:06 CEST 2020 

Diky za info, taky jsem si vsiml ze dnes uz to jde bez problemu.

On Wed, 23 Sep 2020, Jan 'yanek' Bortl wrote:

> 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]
>
>
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux
>

Další informace o konferenci Linux