Permitting recursion can allow spammers to steal name server resources
Hi Dave,
Sorry this post is so long but I wanted to make sure testing and how to
fix the problem was spelled out exactly so people are more likely to fix
their servers.
Credits
Many thanks to William Stearns and Tanya Baccam for helping to pull
together this information.
_Executive Summary_
The default configuration of many domain name servers (DNS) can leave
you vulnerable to cache spoofing attacks as well as allow spammers to
steal resources from your servers. To protect against these attacks, it
is strongly recommended that any name server exposed to the Internet be
configured to act non-recursively for all but trusted networks.
_Vulnerable Software_
Bind (at default settings)
Microsoft DNS (at default settings, but less so than Bind)
Probably many others
_Background_
There are three primary factors that attribute to the spammers ability
to steal your DNS resources:
1) Exposed name server configured to act recursively
2) DNS susceptibility to cache poisoning attacks
3) Poor validation by domain name registrars
First, a recursive name server is described to be a name server that is
willing to do the work in answering a DNS query. If the name server does
not have the answer to the query in cache, a recursive name server will
go out to the Internet and find an answer. A non-recursive name server
will only answer queries based on the information in its cache. If the
server does not know the answer to the question being asked, the source
is redirected to another server, or an error code is returned.
For example, most people configure their internal name servers to act
recursively so they will lookup DNS information for the local user base.
The root name servers however are configured to act non-recursively.
They don't answer questions about specific hosts, but rather re-direct
you to the server that can answer the query
Second, DNS cache poisoning attacks are not a new problem. Excellent
papers have been written on these attacks over the years. Some good
examples are:
"Addressing Weaknesses in the Domain Name Protocol" by Christoph Schuba
http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf
"Using the Domain Name System for system Break-ins" by Stephen M. Bellovin
ftp://ftp.research.att.com/dist/smb/dnshack.ps
"DNS Cache Poisoning - The Next Generation" by by Joe Stewart, GCIH
http://www.securityfocus.com/guest/17905
Additionally, there are a large number of tools out on the Internet that
permit an attacker to perform a variety of DNS attacks. One of the more
popular is ADMIDpack available at
http://www.securiteinfo.com/
Rather than re-invent the wheel by describing cache poisoning and how it
is done, we'll refer readers that require that information to the above
references. Instead, we will focus on what appears to be a new trend
with spammers, how it can impact your network, and what you can do to
protect yourself.
Finally, the fact that domain name registries perform extremely poor
validation of the information associated with a given domain name is
also well know. A good article on the subject can be found here:
http://news.com.com/2100-1025_3-5071523.html
_The Problem_
Just about everyone hates receiving spam and it is not uncommon for
people to lash out at the source of these messages. Spammers know this,
which is why they go to such great lengths to hide their tracks.
Spammers that set up legitimate domains frequently find themselves to be
the recipient of Denial of Service (DoS) attacks, or discover that
their Internet connectivity is quickly terminated by their upstream ISP.
One of the stealthy tricks spammers have developed is to find
mis-configured mail servers that will permit them to relay their spam
messages (this is a well known technique). If the mail server gets
attacked or blocked by the Internet community, the spammer simply moves
on to another open mail relay. Of course the legitimate owner of the
mail server is not so lucky.
In an escalation of arms, it appears that some people also take action
against the spammer's name servers as well. The thought process is that
if the Internet community can take out the spammer's DNS (note we are
not advocating this practice, just describing it), click though links in
their spam messages as well as Web bugs and the like may no longer
function. This can severely hinder the spammers ability to figure out
which messages were actually received, as well as the amount of interest
generated by the message. Unfortunately, spammers have found a way
around this problem in a similar fashion to the open SMTP relay method
described above. Instead of targeting mis-configured mail relays
however, they target mis-configured name servers.
Here's how it works. The spammer registers a domain name using name
servers that are under their control. Note that we found no consistency
in the amount of time that spammers use when registering a domain name.
It could be anywhere from a year to 10 years. Also, we found no
consistency with the registrar authority being used. The spammers we
tracked used a range of authorities.
Next the spammer seeks out name servers on the Internet that have been
mis-configured to act recursively for anyone. Unfortunately, this
appears to be a fairly easy task as testing we performed showed that an
overwhelming majority of the exposed name servers on the Internet act
recursively.
After that, the spammer populates the recursive name server with host
information regarding their spam domain. We prefer not to go into a
whole lot of detail as to how this is done, as we prefer not to train
script kiddie spammers on how to leverage this attack. Suffice to say
that once the spammer is finished, the target server contains cached
information about the spam domain. The amount of time this information
will be cached varies depending on the time to live (TTL) values used by
the spammer.
Next the spammer goes back to their registry authority and changes their
authoritative name servers to be the recursive name servers they
populated in the last step. Since it appears that registry authorities
no longer validate if a customer has permission to use the name server
they specify (note that this used to be done way back when domain names
were free), the record is quickly updated and users on the Internet are
directed to this populated name server when querying information about
the spammer's domain. The spammer is now free to push out their spam and
if the Internet community decides to attack, the name server being
attacked actually belongs to someone else.
There is a limiting factor in all of this. Most name server software
allows you to specify a maximum amount of time that the server will
cache information. In other words, if the spammer attempts to set a TTL
cache value of 90 days, the name server doing the caching may quietly
truncate the TTL value to a lower setting.
For example, the maximum TTL cache time with Microsoft DNS is set
through the MaxCacheTtl registry key value. The default value is one
day. This gives a very small window of time that the spammer could use
to populate the name server, change their registry information, send out
their spam, and expect replies to come back. This makes Microsoft DNS
far less susceptible to this attack (by default) than other name servers.
Bind limits this cache time though the max-cache-ttl parameter. The
default setting is seven days. Given that most registry authorities make
changes in 24 hours or less, this is still ample time to push out spam
messages and see who replies.
Please note that the root cause of the problem is not how long the
information is being cached. The real problem is that the server is
acting recursively by default. The above information has been included
in order to help identify the magnitude of the problem with different
name server software packages. Longer caching is actually preferred as
it helps to improve performance.
_How to fix the problem_
Fixing the problem varies depending on whether you are running Bind,
Microsoft DNS, or some other software. Regardless of what you are
running, testing to see if you are vulnerable is a consistent process.
Run the following command from a remote UNIX or Windows system. You want
to run this from a system that *should not* have recursive access to
your exposed name servers. DO NOT try this from an internal host first,
as it will skew your results. Good choices are an external shell
account, your home system, or possibly have a trusted friend do the
testing for you.
Here is the command to run:
nslookup bogus.spam-free-zone.com <IP address of the server to test>
If the command returns similar to the following:
Non-authoritative answer:
*** Can't find bogus.spam-free-zone.com: No answer
You name server is configured properly. Pass directly to "GO" and
collect $200. :-)
If however you get back an answer similar to:
Name: bogus.spam-free-zone.com
Address: 172.29.217.137
your name server is improperly configured to act recursively for
everyone on the Internet, and needs to be changed.
_Fixing the problem with Bind_
Changing Bind so that it will not act recursively for all hosts on the
Internet is a relatively simple process. Edit the /etc/named.conf file
to add in the "allow-recursion" parameter similar to the following:
options {
directory "/var/named";
allow-recursion {localnets; };
};
Note that you may already have additional options defined, which is just
fine. The important thing is to add in the allow-recursion line as
shown. The above command tells Bind to only act recursively for systems
that are part of the same logical subnet as the Bind server. This way if
there is a local SMTP or HTTP server than needs to do name resolution,
this functionality will continue to work. All other subnets however will
be blocked from doing recursive queries. Users on the Internet will only
be permitted to look up information you are authoritative for (like your
Web server's IP address, your MX record, etc.). This will protect you
from the current round of spammers stealing name server resources.
If you need to have the Bind server act recursively for multiple
subnets, simply specify them in CIDR format, separated by commas. For
example:
allow-recursion {172.16.1.1, 10.0.0.0/8, 192.168.1.0/24;};
_Fixing the problem with Microsoft DNS_
Unfortunately, Microsoft DNS is not quite as configurable as Bind when
it comes to tweaking recursion. Your options are to either enable or
disable recursion; you cannot make exceptions for certain subnets like
we could with Bind using the allow-recursion parameter.
This can cause problems if there is a local SMTP, HTTP, etc. server that
relies on the Microsoft DNS server to perform recursive queries.
Disabling recursion will break this required functionality. If you are
in this situation, you may need to do one or more of the following
additional steps along with disabling recursion on your exposed
Microsoft DNS server:
1) Re-configure these systems to direct recursive queries though some
other name server, such as your upstream ISP
2) Run a local DNS process on each of these systems but do not make
TCP/53 and UDP/53 directly accessible from the Internet to these systems.
3) Replace the server with a Bind server and use the allow-recursion
parameter.
To disable recursion on a Microsoft DNS server from the command line,
run the following command while having Administrator level access to
the system:
dnscmd <server name> /config /NoRecursion 1
If you prefer to use the GUI interface, open Administrative Tools and
then DNS, and click on the following:
Properties--> Advanced --> Server Options --> Disable recursion --> OK
_Verifying that recursion is now disabled_
If you believe you have recursion properly disabled, you can test it
from an outside host in a similar fashion to the testing we performed
earlier:
nslookup bogus1.spam-free-zone.com <IP address of the server to test>
The IP address of this host is 172.29.217.138. Again, if you get a
failed lookup, the test is successful and your DNS server is safe from
recursive attacks. You can verify that recursion is working properly by
running the same command from an internal host. If the command returns
the above IP address, the name server is functioning properly.
_Additional testing_
If you would like to verify that a domain's name server is acting as a
proper authoritative name server, rather than serving up cached
information only, the host command works quite nicely:
$host -C spam-free-zone.com
Nameserver host2.spam-free-zone.net:
spam-free-zone.com SOA host2.spam-free-zone.net.
postmaster.spam-free-zone.net. 200309091 28800 900 1209600 86400
Nameserver dns1.chrisbrenton.org:
spam-free-zone.com SOA host2.spam-free-zone.net.
postmaster.spam-free-zone.net. 200309091 28800 900 1209600 86400
A server that is suppose to be authoritative for a domain, but is only
serving up the information via cache would return no information.
You can configure Sendmail to reject SMTP messages when the name servers
for the domain are supposed to be authoritative, but are actually
serving up information from cache. Simply edit your sendmail.mc file and
comment out (add dnl to the beginning of the line) the
"accept_unresolvable_domains" option, similar to the following:
dnl FEATURE(`accept_unresolvable_domains')dnl
Then just rebuild a new sendmail.cf file, restart Sendmail, and you are
cooking with gas. Rejected e-mails will get logged with the following
error code:
reject=451 4.1.8 Domain of sender address mail@xxxxxxxxxxxxxxxxxxxxx
does not resolve)
In our testing this tweak resulted in zero legitimate e-mails getting
dropped, but your mileage may vary. We are unable to come up with a
legitimate reason as to why someone would configure their domain this
way on purpose, and in fact it's in violation of the RFCs. It's possible
however that someone you communicate with has incorrectly configured
their domain this way, so watch your logs to see if you start rejecting
legitimate e-mails.