It seems like ancient history now, but in the early decades of the
Internet we had huge problem: Our email servers were too friendly.
In a nutshell, most email servers allowed anyone to connect to them and
send email to anyone else. You didn't have to be a user of that email
server, though sometimes you had to at least fake being a user.
An attacker could connect using the email server's email SMTP receiving port (TCP port 25) and send commands (using telnet, a script, or another program) that mimicked the internal commands used by all SMTP servers to exchange email. A hacker could forge an email, claim to be from someone legitimately hosted by the email server, and send any email to anyone else on the planet.
Spammers would look for these "open relay" servers and send hundreds of
millions of spam emails throughout the world. It took the world -- and
email server vendors -- about two decades to require that all
originating emails actually originate from verified, authenticated
users.
Yet after all these years, a similar open relay problem persists with
another foundational Internet technology: DNS. Attackers routinely use
weak or misconfigured DNS servers to send back invalid IP addresses to
querying clients -- or to send massive amounts of bogus traffic in DDoS attacks.
Exploiting DNS to launch DDoS attacks
DDoS and other attackers have been exploiting DNS for ages, but in the last few years, hackers have upped the ante.
These days the most massive DDoS attacks are often accomplished using
DNS "amplification" techniques. To explore some great background info
about how this works, check out US-CERT, the Internet Systems Consortium, and CloudFlare.
At last, DNS server vendors and protocol makers are responding in a
manner similar to the SMTP email vendors of yesteryear by implementing
more protections. These include better defaults and new defenses.
Unfortunately, DNS servers -- though they may seem to be working fine --
are easily neglected and left vulnerable without anyone except
attackers being the wiser.
Disabling open relay DNS servers
One of the best things any company can do is to limit to what and to whom their DNS server will respond. For internal DNS servers, make sure the only queries that your DNS responds to come from internal computers and other authorized DNS servers.Even your external, public-facing DNS servers should not respond to every request. If your DNS server is hosting *.example.com addresses, no one should ever ask it for a domain address outside that domain. If your DNS server will respond to all queries from whomever, especially for any domain, then you have an open relay DNS server, and that ain't good.
To ensure your DNS server isn't an open relay and is locked down as tight as it can be for legitimate operations, type in its IP address at any DNS open relay check service, including these:
DNS response rate limiting
One of the best defenses against allowing your DNS server be used in a DDoS attack is to implement response rate limiting (RRL).
RRL is primarily for authoritative DNS servers (those that are supposed
to respond for one or more domains) and allows the DNS admin to set
effective rate limits on DNS response traffic. Although not enabled by
default (it should be!), RRL is available in BIND 9.9 (and later) and is a part of Microsoft's forthcoming Windows Server 2016 DNS services.
If your DNS server does not yet support RRL, you can try to accomplish
the same effect using alternate methods, such as using firewall rate
filters or enabling other anti-DDoS services to complement your DNS.
Disabling upward referral responses
For most of DNS's history, when a nonrecursive authoritative DNS server
got a query for a domain name it was not authoritative for, the DNS
server would respond by redirecting the querying client to the top-level
domain DNS servers (often listed by name and IP address in a file
hosting "root hints"). It was the polite thing to do. "Hey, I don't know
the answer, but start your search here and you'll find the answer."
Well, it only takes one abuser to ruin the fun for everyone, and DNS
amplification attacks have simply made it poor practice to serve up the
root hints. BIND has long recommended disabling upward referrals. Microsoft plans to make disabling upward referrals a default in Windows Server 2016,
and you can disable it in previous versions of Windows server by
deleting the root hints file (c:\windows\system32\DNS\cache.dns).
Check for all DNS services
Run a scan for computers and devices accepting connections to TCP or UDP
port 53 to find and securely configure all computers and devices
running DNS services. Oftentimes you'll find appliances and network
devices (such as wireless routers) running unexpected DNS servers.
Don't leave the door open
The DNS protocol is doing remarkable well for something invented in
1983. It gets abused and updated, but overall it is still the main
plumbing that keeps the Internet humming along. But we can't get
complacent with the security of anything we maintain, including DNS.
Don't let your DNS servers mimic yesteryear's open relay email servers.
We can't take another decade to fix what needs to be fixed now.
Post a Comment