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  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]
From: j.hall at (John Hall)
Subject: FW: Question for DNS pros

Frank Knobbe wrote:

>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.
Remember, we are only interested in RTT and reachability, so any response
to our probe, be it SYN/ACK, reply, or RST is useful to the 3-DNS.  The
reason we can't use the same IP ID for each packet is to be able to
distinguish the responses and tie them to the correct probe, so we get
accurate measurements.

>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.
It's possible the packets that solicited the traffic were spoofed, but
it's generally more likely that someone on your network browsed the site
in the last day or two and you just haven't yet been aged out of the list
of sites the 3-DNS is keeping track of.

>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.
Definitely not!  When your DNS server sends a query to 3-DNS, it's added
to a list of sites to keep metrics for.  The probes used to create those
metrics are rate limited to one overall attempt to gather data per hour
regardless of how many times you query the server.  A single data gathering
attempt will try each of its configured probe methods in turn to try and
get a response, so you should never see more than 6 - 20 packets per hour,
per group of 3-DNS's.

>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.
I don't think that could be a problem with 3-DNS.  Your time would
probably better be spent trying to ensure that no reconnassance attempts
return data that would be useful to an attacker.  I suspect that even
if every group of 3-DNS's in the world suddenly added you to their probe
lists, you wouldn't see a significant amount of traffic.  You'd probably
notice it, but it wouldn't compare with the total amount of other
unsolicited traffic you receive.

>Perhaps the only solution is to build a list of 3DNS IP addresses and
>ignore these type alerts from those addresses.
That may be the best solution, since while 3-DNS is selling well, the
total number of sites using 3-DNS that your site is browsing is likely
to be small.  If you're really watching your traffic that closely, then
you may still want to see these alerts anyway, since those 3-DNS probes
could come from a BIG-IP which is also configured to NAT traffic for an
entire network behind it.  You wouldn't be able to distinguish the 3-DNS
probes from the probes of a machine behind the BIG-IP.

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

John Hall              Test Manager - Switch Team             F5 Networks, Inc.

Powered by blists - more mailing lists