Windows Server DNS Amplification attacks

HI,

I have a server that was reported as being vulnerable to DNS amplification attacks. The problem is, after blocking all incoming traffic to 53 via Windows Firewall, my server is apparently still happily responding to anonymous nslookups.

How could this be the case? What else should I be looking for? I run as a web server with multiple websites and applications running, but not a DNS server. But isn't blocking Port 53 all that would be necessary?

Thanks

Bill



Can you run DNS test here post back results.
https://www.grc.com/dns/dns.htm



Can you run DNS test here post back results.
https://www.grc.com/dns/dns.htm



HI - I'm not sure what to post back here. This appears to be a results summary:
External Ping: replied (It might be better for the server to be less visible.)
External Query: ignored (This means the nameserver is more spoof resistant.)
DNSSEC Security: absent (This nameserver might need to be updated.)
Alphabetic Case: all lower (An improvement could be created by mixing case.)
Extra Anti-Spoofing: unknown (Unable to obtain server fingerprint.)

What else are you looking for in the results?

Bill



What did you blocked by firewall? TCP traffic? The DNS uses UDP packets for request/respond messages.

Also, if you are blocking the DNS traffic, your clients won't be able to benefit from this service from your server

In the DNS settings you can specify the scope of DNS for which domains to respond and for which addresses should make forwarding requests



Hi,

I blocked TCP and UDP port 53.

This is not a DNS server.

Frankly, if it causes a problem to have this port blocked, then I can deal with that, but right now, there is no evidence that my port blocking has accomplished anything.

Hence my posted original question. How on earth is my server still relaying DNS information?

Thanks

Bill



Without a DNS server running, I don't see how it could relay information.

What is the tool you're running and what does it say?

Share this

Related Posts

There was an error in this gadget