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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1091589469.525.290.camel@localhost>
From: frank at knobbe.us (Frank Knobbe)
Subject: FW: Question for DNS pros

On Tue, 2004-08-03 at 20:38, John Hall wrote:
> In general, most sites use local forwarding DNS servers that do the
> recursive lookups for all the clients at that site, so our probes
> measure the RTT from each datacenter to that forwarding DNS server
> and maintain that data so we can make intelligent decisions the next
> time a client from that site (via that local forwarder) makes a request.

Okay. I'm not sure how that would help since the server could just send
the reply. Actually, it could have sent several during the time it takes
to measure the round trip time. But this is not the place to discuss
3DNS merits.

What is strange, though, is the fact that the load-balancer sent those
packets without actually receiving a request. The dump I provided span
most of the night, filtered on that host, and there are no DNS queries
being sent to the load-balanced DNS server. Instead, it appears like the
load-balancer is just unsolicited probes. It is, however, possible that
these are responses to spoofed packets that the load-balanced server
received from someplace else.

But wouldn't that make 3DNS an amplifier in a DoS attack? I guess it
depends on how it is configured. Seems so that, when configured wrong
with an overly aggressive configuration, it will respond with a multiple
of probes packets to a single spoofed reply.

The problem goes like this. An attacker sends a single spoofed UDP
packet, spoofing the IP of his target, to a handful of 3DNS
load-balanced DNS servers. Each load-balancer will send a series of
probes to the target. If not usable for a denial-of-service attack (due
to low volume), then at least it can be misused to generate a cover of
suspicious traffic that the attack can use to hide his own little
reconnaissance packets in.

Don't get me wrong, I'm not complaining about 3DNS. I'm just questioning
whether it really is useful to produce a series of probes in response to
a potentially spoofed packet.

> That does look like a full set of 3-DNS probes.  We generally recommend
> that our customers only configure two probe methods.  Looks like this 
> guy has all of the probe methods configured.  Since your firewall doesn't
> respond at all, it's trying each method in turn.  The traffic does look
> like it's pretty low volume, so I guess your major concern is being
> woken up at 4am with IDS alerts 

Not really. It is generating about 300 annoying packets a day. The issue
is that it appears to be hard to distinguish this from a real attack (in
case of the UDP queries). I'm planning on writing signatures for the TCP
SYN scan to ignore these 3DNS probes. But the UDP queries for "." and
the reverse IP address are things that need to cause an alert since they
could be part of a human-driven recon/attack. I'm hesitant to turn a
blind eye on those...

> Currently, I don't know of any specific signature other than the ID
> field that would help identify our "." probes.  I'll ask around.

Please do. As mentioned earlier, a fixed IPID might work. But then
again, an intruder could use those values to do his dirty work, and (by
making the packets look identical to 3DNS probes) slip under a radar
screen.

Perhaps the only solution is to build a list of 3DNS IP addresses and
ignore these type alerts from those addresses.

Thought anyone? (If anyone is still following ... :)

Cheers,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040803/52c8d54c/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ