On 03/16/2000 at 11:08:39 AST, "Brian Steele" <[EMAIL PROTECTED]>
wrote:
> This is a followup to a message I sent yesterday concerning a sysadmin
> reporting that our DNS server (NT4/SP6a/MS-DNS) was flooding his DNS
server
> (Ultrix?/BIND8) with queries. An example of his log file is given below:
>
> Mar 15 12:03:15 surfdns1 named[1817]: host name
> "210\.212\.235\.95.hhss.edu.gd" IN (response from [205.214.207.99])
is
> invalid - proceeding anyway
>
> I cross-posted the message two both lists, as there could've been some
> security issues involved that the "firewall guys" might be aware of (the
> sysadmin's log file showed numerous entries like the one above, the only
> difference between the entries being the IP address being incremented by
> one
> for each entry).
>
> Well, I used LAN Explorer (purchased from Sunbelt Software some time ago
-
> thanks Stu!) to capture all of the packets seen by our DNS server, and
> basically this is what is going on.
>
> There are TWO client systems at the root of all the problems here. The
> modus
> operandi of both clients is as follows:
>
> 1. Client sends a request originating from port 137 to my DNS,
> requesting the resolution of the name
> "nnn.nnn.nnn.nnn.hhss.edu.gd",
> where "nnn.nnn.nnn.nnn" is an IP address.
>
> 2. My DNS, being the authorative server for the edu.gd
> domain, responds to the client with a name error.
>
> 3. A request then originates from the BIND8 DNS, requesting
> the resolution of the name name given in (1).
>
> 4. My DNS responds to the BIND8 DNS, with a name
> error.
>
> 5. The process repeats itself, with the only difference being that
> the IP address nnn.nnn.nnn.nnn is incremented by one.
>
>
> Presently, the range being queried by one client is 213.131.24.nnn, and
the
> other 205.68.216.nnn. The modus operandi suggests that the clients are
> using both my DNS and the BIND8 DNS for lookups - when my DNS returns a
> name
> error, the clients then switch to querying the BIND8 DNS for resolution
of
> the same name, and the BIND8 DNS then turns and queries mine, as my DNS
is
> authorative for the domain in question. In other words, it's NOT my DNS
> flooding his with queries, but vice-versa!
>
> Any ideas on what software the clients could be running to generate these
> strange queries from port 137? What could be the point behind all of
these
> queries? Is this really a security issue, or am I just panicking :-).
>
> Finally, while checking the data, I came across ANOTHER client sending
> requests to my server and following a very similar modus operandi. The
> only
> difference between this client and the two clients above is that
> "hhss.edu.gd" is not being apended to the name for which resolution is
> being
> requested. The IP address range being queried here is 135.121.10.nnn. My
> DNS then forwards the request to one of the InterNIC root servers, which
> then returns a name error, which my DNS then returns to the client.
>
> In all cases, the client's IP address does NOT reside in the range being
> queried.
My guess. Two machines (the clients) are attempting crude dns-based scans
of the 213.131.24.0 and 205.68.216.0 networks. These nets appear to belong
to the following, respectively:
role: SINP MSU Network Operations Centre
address: SINP MSU NOC
address: Skobeltsyn Institute of Nuclear Physics
address: Moscow State University
address: 119899 Moscow
address: Russia
DOD Network Information Center (JMCIS-BLOCK)
Space and Naval Warfare Systems
Washington, DC 20363-5100
The "normal" way this is done is to try a zone transfer from the
authoritative servers. That is usually blocked by the servers (unless the
client is an official secondary). The crude way it is done is to do PTR
lookups for every address in the network. That's what seems to be
happening here, except that both clients have a bug. The first is making
qt=A or qt=ANY (I'm guessing) requests for the addresses followed by the
hhss.edu.gd name. That isn't going to work. The second is making the same
type of requests for just the address. And that won't work either.
The way this "should" be done is to make qt=PTR requests for the
in-addr.arpa version of the name - e.g., 1.24.131.213.in-addr.arpa. Then
you do this for every name in the network and you end up with a map of
every name and address in the net that has reverse dns.
Given the apparent owners of these networks, I would consider contacting
the FBI. Based on the extreme crudeness and errors in this probing, it's
probably just some kids, but who knows?
Tony Rall
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
