<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
rypnem si...<br>
zareagoval na tento problem aj M$ .. :D<br>
<br>
kedze sa chystame preinstalovat jeden GW-NAT-FIREWALL-MAIL-PROXY
server...<br>
tak by som sa pri tejto prilezitosti rad opytal na nazor, ci mam pouzit
BIND alebo radcej DJBDNS<br>
<br>
...............................<br>
<br>
Matus UHLAR - fantomas  wrote / napísal(a):
<blockquote cite="mid:20080801132756.GA20464@fantomas.sk" type="cite">
  <blockquote type="cite">
    <pre wrap="">Matus UHLAR - fantomas, 15.7.2008 14:07:
    </pre>
    <blockquote type="cite">
      <pre wrap="">3. Problem spociva v tom, ze DNS dotazy sa vacsinou posielaju UDP paketmi so
16-bitovym ID cislom, co dava dost malo kombinacii. Problem je mozne
zmiernit tym, ze dotazy budu chodit z co najvacsieho mnozstva roznych UDP
portov, takze utocnik bude musiet hadat aj spravny port.

...
Objavitel problemu Dan Kaminsky chce zverejnit podrobnejsie informacie na
BlackHat konferencii 7-8 Augusta, skuste doupgradovat dovtedy.
<a class="moz-txt-link-freetext" href="http://news.cnet.com/8301-10789_3-9985815-57.html?hhTest=1">http://news.cnet.com/8301-10789_3-9985815-57.html?hhTest=1</a>
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
On 15.07.08 16:18, Tibor Pittich wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Na tento problém upozorňoval ešte v minulom storočí Paul Vixie vo svojej
prezentácii na Usenix-e v roku 1995:
<a class="moz-txt-link-freetext" href="http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt">http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt</a>

Okrem iného aj Daniel J. Bernstein na svojej stránke popisuje tento
problém: <a class="moz-txt-link-freetext" href="http://cr.yp.to/djbdns/forgery.html">http://cr.yp.to/djbdns/forgery.html</a>
pričom djbdns používa odzačiatku randomizáciu zdrojových portov.

Dan Kaminsky problém neobjavil, len oživil starý problém tým, že zrejme
našiel efektívnejší spôsob ako vykonať "forgery".
Za doterajších okolností bola potrebná pomerne veľká hrubá sila,
zaujímavé hodnoty sú uvedené v štúdii
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05">http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Presne tak. Mimochodom vynorili sa este dva problemy:

1. odhad toho, co vlastne objavil Kaminsky, bol zverejneny, vzapati
stiahnuty ale medzitym skopirovany inam. Odhad bol spravny.
Dalsi objaveny  problem spociva v tom, ze paket s odpovedou moze obsahovat
additional section, t.j. nejake udaje navyse (casto napriklad IP
nameserverov spomenutych v authrity section), ktorym ak server uveri, ma
smolu. Nastastie novsie verzie DNS serverov si davaj upozor.

2. niektore NAT firewally, ktore sa nesnazia zachovat zdrojovy port, pouziju
pri preklade adresy rovnaky alebo odhanutelny port. Takze ak ste za NATom,
overte si ci NAT server nerusi vsetky vyhody patchnuteho resolvera.

3. Co som minule nenapisal - v pripade ze ma niekto DNS server poskytujuci
rekurziu verejne, moze ho hocikto poziadat aby si zistil nejake meno a
vzapati podrvhnut odpoved. Vypnite si rekurziu, budte sebci a poskytujte ju
len sebe - inac ohrozujete sami seba.

  </pre>
</blockquote>
<br>
</body>
</html>