lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: jcoombs at PivX.com (Jason Coombs PivX Solutions)
Subject: Question for DNS pros

Interesting discussion. There should be more DNS validation performed in the real world. We know what we're putting into DNS with respect to the domains we control, but the only time we find out about bad responses coming out at network endpoints is when we see the bad data ourselves or end users have problems. A MITM who poisons or hijacks DNS is going to ensure that the end user doesn't have problems that would cause them to complain to tech support or a webmaster, which makes it even more important to proactively detect DNS tampering.

I wrote a couple articles on this subject not long ago. See:

Forensic Data Validation and Integrity Logging

http://www.ddj.com/documents/s=9207/win1069286014914/

Sincerely,

Jason Coombs
Jcoombs@...X.com

-----Original Message-----
From: Paul Schmehl <pauls@...allas.edu>
Date: Fri, 23 Jul 2004 17:11:10 
To:full-disclosure@...ts.netsys.com
Subject: Re: [Full-Disclosure] Question for DNS pros

--On Friday, July 23, 2004 09:50:44 PM +0200 Oliver@...yhat.de wrote:
>
> hm... you could also try reverse lookups for all existing ip-adresses in
> the world :)
>
Well, no, because that wouldn't solve the problem.

A host on our network is being queried quite regularly on udp/53 by other 
hosts. A review of the packets reveals that these other hosts believe that 
our host is a dns server.  (AAMOF the IP address isn't even in use at the 
present time.)

Now, if you do a reverse lookup for that IP, *our* DNS servers, which are 
authoritative for our network will tell you what the hostname is.  But that 
isn't what I want to know.  Obviously, a simple dig -x IP will tell me that.

What I want to know is *why* do these "foreign" hosts think an IP on my 
network is serving DNS when there's not even a host at that address.

I can think of two possibilities:

1) At some time in the past, a host *was* serving DNS at that address and 
some "foreign" hosts have cached the address.
2) Someone somewhere has registered a domain and used our IP address for 
one of their "nameservers" in the registration.

(If anyone can think of other explanations, please let me know.)

Now how is a reverse lookup going to help you with that?  It would be 
trivial to write a perl script that did reverse lookups for every IP on the 
Internet and wrote the responses to a comma delimited file, but the 
resulting file would be useless to solve the problem that I'm trying to 
solve.

And for those who were thinking "just do a tcpdump", here's what *that* 
looks like - no domain info there -

17:01:44.646943 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  48072 NS? . 
(17)
17:01:45.386919 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  48073 NS? . 
(17)
17:01:46.153402 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  48074 NS? . 
(17)
17:01:47.657898 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  1084 PTR? 
63.37.110.129.in-addr.arpa. (44)
17:01:48.399150 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  1085 PTR? 
63.37.110.129.in-addr.arpa. (44)
17:01:49.144398 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  1086 PTR? 
63.37.110.129.in-addr.arpa. (44)

The best suggestion yet has been to set up a name server at that address 
with verbose logging.  That's probably what I will do next week.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ