Last week’s blog article discussed some of the security issues surrounding DNS servers. This article wraps up the topic by offering some tips on securing your server. The good news is most of these problems have been solved and you can take steps to secure your name server and your zone data. Although there is no panacea (see Why the DNS is broken, in plain language), taking these steps will reduce the pool of problem name servers on the Internet.
1. Stay up to date
Make sure your name servers are running the latest version available. Many of the cache poisoning attacks have been fixed in later versions of DNS software. For example, recent versions of ISC BIND added relevancy checks for information in DNS replies, randomized source ports, etc.
2. DNS security
DNS Security Extensions (DNSSEC) adds the ability to ensure authentication and integrity of DNS records through the use of signed DNS zones. With DNSSEC, each record in a zone is signed (and the absence of a record is detectable) and a chain of trust from the root name servers to the zone is used to authenticate the replies as coming from an authorized name server. DNSSEC prevents your domain from being spoofed to DNSSEC-aware resolvers, eliminating cache poisoning attacks. The two draw backs to DNSSEC are that it adds some maintenance overhead for updating zones and keeping the signatures up to date; and not all top level domains (TLDs) are providing for the DNSSEC chain of trust. The second issue has been addressed using other techniques such as DNSSEC Look-aside Validation. A good getting started guide is available: DNSSEC in 6 minutes
3. Turn off public recursive querying
Turning off public recursive querying will not only make you a good net citizen by taking you out of the pool of possible amplification attack servers, it will also close off the theft of service problem described above. To accomplish this, simply add access control over which IPs can query your server. First, you will went to limit general queries to only those IPs which should be able to use you server for DNS resolution (internal network, customers, etc). If using ISC BIND, this can be done in your named.conf’s options section:
options
{
...
allow-query
{
trusted;
};
allow-query-cache
{
trusted;
};
allow-recursion
{
trusted;
};
...
}
acl "trusted"
{
localhost;
192.168.0.0/16; // Internal IPv4
3ffe:470:1f01:642::/64; // Internal IPv6
130.215.24.0/24; // DMZ
};
This will limit the machines allowed to query your name server for any information to those listed in the “trusted” ACL. Second, you will want to open up queries for the zones which your name server publicly publishes:
zone "example.com"
{
...
allow-query
{
any;
};
...
};
This allows queries to the example.com zone from any host on the Internet.
Once these restrictions are in place, test on both a non-trusted machine and a trusted machine. The trusted machine should give an accurate response. The non-trusted machine should get a response indicating that the query was refused and recursion was not available:
> dig A google.com @your-name-server.example.com
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27272
...
;; WARNING: recursion requested but not available
...
4. Turn off AXFR
Finally, to prevent information leakage, you should limit zone transfers to only those machines which provide secondary service to your zones. To accomplish this, add ACLs to turn off zone transfers and then turn them on for each individual zone. For example, with ISC BIND:
options
{
...
allow-transfer
{
none;
};
...
};
zone "example.com"
{
...
allow-transfer
{
10.210.100.1;
3ffe:470:1f01:642::1;
};
...
};
This turns off all zone transfers for all zones served by your name server and then allows example.com to only be transfered by IPv4 address 10.210.100.1 and IPv6 address 3ffe:470:1f01:642::1.
Thursday, June 11, 2009
Sunday, June 7, 2009
Why is the Snort IDS still alive and thriving?
No one wants to simply "detect" intrusions. Everyone, quite rationally, wants to prevent intrusions. Leading up to 2003, IDS vendors claimed ever greater capabilities to detect intrusions, with supposedly lower false positive rates. Customers naturally asked the question, "If you can detect it, why can't you prevent it?" Companies selling so-called "intrusion prevention systems" answered "We can!" and dealt a body blow to the IDS market.
The undeniable fact of the matter, however, is that preventing a network-based intrusion requires detecting it. No one has built, or ever will build, a network-based (or host-based, or anything-else-based) system that performs 100% accurate detection, so that means 100% prevention is also impossible. What should you do with events that are not regarded with 100% confidence as being malicious? If you block them, you could deny legitimate business traffic. The sensible alternative is to alert on them and let a human analyst investigate the situation. Hence, we have returned to seeing IDS as a useful tool. IPS, incidentally, is quickly becoming another feature on the network firewall.
The undeniable fact of the matter, however, is that preventing a network-based intrusion requires detecting it. No one has built, or ever will build, a network-based (or host-based, or anything-else-based) system that performs 100% accurate detection, so that means 100% prevention is also impossible. What should you do with events that are not regarded with 100% confidence as being malicious? If you block them, you could deny legitimate business traffic. The sensible alternative is to alert on them and let a human analyst investigate the situation. Hence, we have returned to seeing IDS as a useful tool. IPS, incidentally, is quickly becoming another feature on the network firewall.
Thursday, June 4, 2009
WEB MANAGEMENT Internet Information Services (IIS) sees big changes in Windows Server 2008
Over the years, Internet Information Services (IIS) -- Microsoft's flagship Web server product -- has received a lot of flak for being hacked and compromised. With the release of Windows Server 2008, however, Microsoft had the opportunity to move past those stereotypes and do something really great – and this time, the company came through. In fact, Microsoft and the IIS team went above and beyond what I had expected by completely redesigning and overhauling IIS's core functionality and design.
What's new with IIS?
Microsoft has taken the core functionality of IIS and broken it down into modules. You can take any one of these modules and break them down further by plugging, unplugging or extending them, or even ripping the code out and not using them at all.
In other words, you can turn any module in IIS on or off whenever you want. For example, if you don't use basic authentication in your websites, you can simply remove the code. Furthermore, if your application does not take advantage of common gateway interfaces (CGI), just remove that specific component.
Now when you deploy a brand new Web server, you can choose what components you want and only run those components. This not only allows you to further secure IIS but it also provides a huge performance boost as IIS will run faster than ever before.
Another area that I am impressed with is ASP.NET integration. Currently, ASP.NET sits on top of IIS and compliments it very well. In version 7.0, IIS and ASP.NET are completely integrated. Included in this integration is the entire .NET framework, ADO.NET and the next version of Microsoft's Web services platform, called Indigo.
Ease of use with IIS
So how does all this help you? Well, administrators now have one configuration point for all components as opposed to two or more, which should make life a lot easier on those using IIS.
What's new with IIS?
Microsoft has taken the core functionality of IIS and broken it down into modules. You can take any one of these modules and break them down further by plugging, unplugging or extending them, or even ripping the code out and not using them at all.
In other words, you can turn any module in IIS on or off whenever you want. For example, if you don't use basic authentication in your websites, you can simply remove the code. Furthermore, if your application does not take advantage of common gateway interfaces (CGI), just remove that specific component.
Now when you deploy a brand new Web server, you can choose what components you want and only run those components. This not only allows you to further secure IIS but it also provides a huge performance boost as IIS will run faster than ever before.
Another area that I am impressed with is ASP.NET integration. Currently, ASP.NET sits on top of IIS and compliments it very well. In version 7.0, IIS and ASP.NET are completely integrated. Included in this integration is the entire .NET framework, ADO.NET and the next version of Microsoft's Web services platform, called Indigo.
Ease of use with IIS
So how does all this help you? Well, administrators now have one configuration point for all components as opposed to two or more, which should make life a lot easier on those using IIS.
Wednesday, June 3, 2009
Securing DNS Servers - Part 1
Without a doubt, the most critical infrastructure component on the Internet is DNS. Every other service, including e-mail, depends on it. Yet, surprisingly enough, a large percentage of DNS servers have yet to be secured. In this first of a two part posting, I’ll describe some of the issues surrounding DNS servers. Next week’s post will include steps you can take to secure your servers.
Outside of the usual implementation specific security bugs, there are four main reasons to improve the security of your Internet facing name servers:
1. Spoofing
Over time various methodologies of spoofing DNS results have surfaced using a technique called cache poisoning. This takes advantage of the DNS server’s desire to cache answers for future use in order to cut down on network traffic and reply latency. Initially this was done by providing poisoned data in the additional information returned with a legitimate reply. Lately, these attacks have tried to take advantage of weaknesses in the DNS protocol to poison the DNS server. To read more about cache poisoning and the techniques involved, I recommend the Illustrated Guide to the Kaminsky DNS Vulnerability.
2. Denial of service attacks
A popular method of performing a denial of service attack is by attacking name servers. If a user can’t translate www.google.com to an IP address, they can’t reach the Google web site. A popular technique to knock off a target server is a DNS amplification attack, in which an attacker uses a set of DNS servers which are configured to respond to all recursive queries (regardless of source). In the attack, a relative small query is broadcast with a spoofed sender IP address belonging to the intended victim. Those recursive servers then reply to the victim with a much larger (amplified) response packet. By employing enough recursive servers, the victim, and at times, the recursive servers themselves, are flooded with DNS packets to be processed. For more information on this type of attack, refer to the DNS Amplification Attacks paper by Randal Vaughn and Gadi Evron.
3. Information leakage
For the most part, DNS operates by answering specific questions with specific replies. However, to support synchronizing redundant secondary servers, most DNS servers also allow for a domain’s entire zone to be transferred to the secondary server. However, unless specifically protected, zone transfers are open to any host requesting the information. Typically, a zone file contains all of the publicly available hosts for your site and can be a wealth of information for an attacker.
4. Theft of service
As mentioned in the denial of service attacks section, name servers can be configured to answer recursive queries for any host on the Internet. Even if not used maliciously in attacks, this allows anyone to use your name server for handling DNS client resolution. This is much like promiscuous relaying in e-mail that was common back before spammers arrived on the scene. While it is nice to offer your services to the Internet at large, this can often lead to abuse and the burden of responsibility for the actions of others.
Next week, we will look at steps you can take to protect your servers. In the mean time, your homework assignment is to prepare by determining which hosts should be allowed to use your name server for recursive name resolution (i.e., as a DNS client), and, secondly, for each zone you publish on the Internet, which hosts should be allowed to perform a transfer of the zone (i.e., who are the secondaries for the domain).
Outside of the usual implementation specific security bugs, there are four main reasons to improve the security of your Internet facing name servers:
1. Spoofing
Over time various methodologies of spoofing DNS results have surfaced using a technique called cache poisoning. This takes advantage of the DNS server’s desire to cache answers for future use in order to cut down on network traffic and reply latency. Initially this was done by providing poisoned data in the additional information returned with a legitimate reply. Lately, these attacks have tried to take advantage of weaknesses in the DNS protocol to poison the DNS server. To read more about cache poisoning and the techniques involved, I recommend the Illustrated Guide to the Kaminsky DNS Vulnerability.
2. Denial of service attacks
A popular method of performing a denial of service attack is by attacking name servers. If a user can’t translate www.google.com to an IP address, they can’t reach the Google web site. A popular technique to knock off a target server is a DNS amplification attack, in which an attacker uses a set of DNS servers which are configured to respond to all recursive queries (regardless of source). In the attack, a relative small query is broadcast with a spoofed sender IP address belonging to the intended victim. Those recursive servers then reply to the victim with a much larger (amplified) response packet. By employing enough recursive servers, the victim, and at times, the recursive servers themselves, are flooded with DNS packets to be processed. For more information on this type of attack, refer to the DNS Amplification Attacks paper by Randal Vaughn and Gadi Evron.
3. Information leakage
For the most part, DNS operates by answering specific questions with specific replies. However, to support synchronizing redundant secondary servers, most DNS servers also allow for a domain’s entire zone to be transferred to the secondary server. However, unless specifically protected, zone transfers are open to any host requesting the information. Typically, a zone file contains all of the publicly available hosts for your site and can be a wealth of information for an attacker.
4. Theft of service
As mentioned in the denial of service attacks section, name servers can be configured to answer recursive queries for any host on the Internet. Even if not used maliciously in attacks, this allows anyone to use your name server for handling DNS client resolution. This is much like promiscuous relaying in e-mail that was common back before spammers arrived on the scene. While it is nice to offer your services to the Internet at large, this can often lead to abuse and the burden of responsibility for the actions of others.
Next week, we will look at steps you can take to protect your servers. In the mean time, your homework assignment is to prepare by determining which hosts should be allowed to use your name server for recursive name resolution (i.e., as a DNS client), and, secondly, for each zone you publish on the Internet, which hosts should be allowed to perform a transfer of the zone (i.e., who are the secondaries for the domain).
Subscribe to:
Posts (Atom)