A Defensible Network Architecture is an information architecture that is:
1. Monitored. The easiest and cheapest way to begin developing DNA on an existing enterprise is to deploy Network Security Monitoring sensors capturing session data (at an absolute minimum), full content data (if you can get it), and statistical data. If you can access other data sources, like firewall/router/IPS/DNS/proxy/whatever logs, begin working that angle too. Save the tougher data types (those that require reconfiguring assets and buying mammoth databases) until much later. This needs to be a quick win with the data in the hands of a small, centralized group. You should always start by monitoring first, as Bruce Schneier proclaimed so well in 2001.
2. Inventoried. This means knowing what you host on your network. If you've started monitoring you can acquire a lot of this information passively. This is new to DNA 2.0 because I assumed it would be already done previously. Fat chance!
3. Controlled. Now that you know how your network is operating and what is on it, you can start implementing network-based controls. Take this anyway you wish -- ingress filtering, egress filtering, network admission control, network access control, proxy connections, and so on. The idea is you transition from an "anything goes" network to one where the activity is authorized in advance, if possible. This step marks the first time where stakeholders might start complaining.
4. Claimed. Now you are really going to reach out and touch a stakeholder. Claimed means identifying asset owners and developing policies, procedures, and plans for the operation of that asset. Feel free to swap this item with the previous. In my experience it is usually easier to start introducing control before making people take ownership of systems. This step is a prerequisite for performing incident response. We can detect intrusions in the first step. We can only work with an asset owner to respond when we know who owns the asset and how we can contain and recover it.
5. Minimized. This step is the first to directly impact the configuration and posture of assets. Here we work with stakeholders to reduce the attack surface of their network devices. You can apply this idea to clients, servers, applications, network links, and so on. By reducing attack surface area you improve your ability to perform all of the other steps, but you can't really implement minimization until you know who owns what.
6. Assessed. This is a vulnerability assessment process to identify weaknesses in assets. You could easily place this step before minimization. Some might argue that it pays to begin with an assessment, but the first question is going to be: "What do we assess?" I think it might be easier to start disabling unnecessary services first, but you may not know what's running on the machines without assessing them. Also consider performing an adversary simulation to test your overall security operations. Assessment is the step where you decide if what you've done so far is making any difference.
7. Current. Current means keeping your assets configured and patched such that they can resist known attacks by addressing known vulnerabilities. It's easy to disable functionality no one needs. However, upgrades can sometimes break applications. That's why this step is last. It's the final piece in DNA 2.0.
Tuesday, June 23, 2009
Monday, June 22, 2009
虚拟化大战升温 专家提出四项预测
还记得20年前的Unix大战吗?当Unix大战在1980年代中期开始的时候，哪一种操作系统将统领计算机领域进入21世纪似乎是非常明确的。总的来说，加州大学伯克利分校支持BSD。AT&T支持SystemV。
现在，BSD偶尔还在管理一些应用。但是，你最后一次听说有人使用System V是在什么时候?
事实上，在本10年，随着x86虚拟化应用加快增长，操作系统已经不太重要了，更重要的是虚拟化环境：管理程序和其它东西。随着虚拟化领域继续发展到一个重要的阶段，虚拟化显然已经成为本10年相当于当年的Unix大战的战场，特别是在最近几个月。
当然，这两场大战有一些关键的区别(例如，环境能够共存和本身就没有合作意图)。但是，惊人的相似之处是这两场大战都代表了基础的计算基础设施架构的式样的转变。
ToutVirtual网站“合适的虚拟世界”博客栏目主编SchorschiDecker最近在一篇题为 “Retrospective,What is NewisOld?(回顾：所谓新东西是旧的吗?)”的博客中提供了一些有关虚拟化环境未来的观点和预测。这个文章值得一读。下面是他对当前重要环境的一 些观点：
Xen将不会幸存下来，并不是因为它不好，而是因为市场份额决定一切。思杰没有占有低端虚拟化市场。现在，随着其它竞争者的成熟，思杰等公司都面临严重的威胁。Xen不是免费的，也没有KVM和Hyper-V那样便宜，至少没有人们希望的那样便宜。
Hyper-V还要努力奋斗两年，因为它还很软弱。作为免费的软件，到目前为止只能让你接受它。微软将使Hyper-V取得成功，就像微软在分布式服务器市场打败Novell一样，IT行业的经理们没有胆量或者缺乏胆量不选择微软。
关于VMware，Decker称，VMware的价格也不便宜。我的这个观点在VMware最近召开的会议上得到了加强。那次会议对于 VMware的功能和价格进行了热烈的讨论。老实说，VMware是专业的，非常清楚的情况是VMware不听我们的意见。VMware已经出现5、6年 时间了并且在继续增加功能，没有参照规模和范围其企业增强现有的功能。Decker在博客中没有提到甲骨文，尽管甲骨文一再把自己定位于虚拟化厂商。今年 4月中旬，甲骨文披露了收购Sun微系统公司的计划。甲骨文上个星期宣布它计划收购VirtualIron。甚至在此之前甲骨文就把自己当成了主要的虚拟 化厂商。然而，现在把甲骨文当作这个角色还为时过早。
ServerWatch网站执行编辑Amy Newman对于虚拟化大战提出了如下预测：
思杰将把Xen定位于以客户端为重点。其技术创新的大部分是目前发现的那些技术创新。思杰可能与微软进行更深入的合作。
Hyper-V将出现在大多数企业，但是，将专门用于大多数中小企业环境。Hyper-V也许不是免费的，但是，它是 WindowsServer2008的一部分，也可能仍以某种形式作为以后的操作系统的一部分。企业最终将需要升级，最初的观点是使用已经有的功能是很容 易和便宜的，特别是如果微软的合作伙伴围绕Hyper-V建立一个生态系统的话。这种事情现在似乎已经在做。
甲骨文和VMware将争夺财富500强企业市场，基础设施工具将成为关键的差异化因素。这两家公司将把重点放在愿意为自己需要的资源付费的那个市场。只要这种产品实际上能够提供它许诺的功能，这些企业就愿意付费。
如果我们以Unix大战为榜样，就可以做出第四个预测：并非每一个主要的参与者现在都出现了。对于Unix大战影响最大的可能是Linux的出 现。Linux是在1991年的一个研究生学校的项目中诞生的并且1990年代中期开始快速增长。Linux最终成熟到能够在计算密集型环境中替代 Unix的程度。
然而，Linux并不是真正的Unix。也就是说，虚拟化的“杀手应用程序”也许同我们现在所知道的虚拟化环境是不同的东西。
现在，BSD偶尔还在管理一些应用。但是，你最后一次听说有人使用System V是在什么时候?
事实上，在本10年，随着x86虚拟化应用加快增长，操作系统已经不太重要了，更重要的是虚拟化环境：管理程序和其它东西。随着虚拟化领域继续发展到一个重要的阶段，虚拟化显然已经成为本10年相当于当年的Unix大战的战场，特别是在最近几个月。
当然，这两场大战有一些关键的区别(例如，环境能够共存和本身就没有合作意图)。但是，惊人的相似之处是这两场大战都代表了基础的计算基础设施架构的式样的转变。
ToutVirtual网站“合适的虚拟世界”博客栏目主编SchorschiDecker最近在一篇题为 “Retrospective,What is NewisOld?(回顾：所谓新东西是旧的吗?)”的博客中提供了一些有关虚拟化环境未来的观点和预测。这个文章值得一读。下面是他对当前重要环境的一 些观点：
Xen将不会幸存下来，并不是因为它不好，而是因为市场份额决定一切。思杰没有占有低端虚拟化市场。现在，随着其它竞争者的成熟，思杰等公司都面临严重的威胁。Xen不是免费的，也没有KVM和Hyper-V那样便宜，至少没有人们希望的那样便宜。
Hyper-V还要努力奋斗两年，因为它还很软弱。作为免费的软件，到目前为止只能让你接受它。微软将使Hyper-V取得成功，就像微软在分布式服务器市场打败Novell一样，IT行业的经理们没有胆量或者缺乏胆量不选择微软。
关于VMware，Decker称，VMware的价格也不便宜。我的这个观点在VMware最近召开的会议上得到了加强。那次会议对于 VMware的功能和价格进行了热烈的讨论。老实说，VMware是专业的，非常清楚的情况是VMware不听我们的意见。VMware已经出现5、6年 时间了并且在继续增加功能，没有参照规模和范围其企业增强现有的功能。Decker在博客中没有提到甲骨文，尽管甲骨文一再把自己定位于虚拟化厂商。今年 4月中旬，甲骨文披露了收购Sun微系统公司的计划。甲骨文上个星期宣布它计划收购VirtualIron。甚至在此之前甲骨文就把自己当成了主要的虚拟 化厂商。然而，现在把甲骨文当作这个角色还为时过早。
ServerWatch网站执行编辑Amy Newman对于虚拟化大战提出了如下预测：
思杰将把Xen定位于以客户端为重点。其技术创新的大部分是目前发现的那些技术创新。思杰可能与微软进行更深入的合作。
Hyper-V将出现在大多数企业，但是，将专门用于大多数中小企业环境。Hyper-V也许不是免费的，但是，它是 WindowsServer2008的一部分，也可能仍以某种形式作为以后的操作系统的一部分。企业最终将需要升级，最初的观点是使用已经有的功能是很容 易和便宜的，特别是如果微软的合作伙伴围绕Hyper-V建立一个生态系统的话。这种事情现在似乎已经在做。
甲骨文和VMware将争夺财富500强企业市场，基础设施工具将成为关键的差异化因素。这两家公司将把重点放在愿意为自己需要的资源付费的那个市场。只要这种产品实际上能够提供它许诺的功能，这些企业就愿意付费。
如果我们以Unix大战为榜样，就可以做出第四个预测：并非每一个主要的参与者现在都出现了。对于Unix大战影响最大的可能是Linux的出 现。Linux是在1991年的一个研究生学校的项目中诞生的并且1990年代中期开始快速增长。Linux最终成熟到能够在计算密集型环境中替代 Unix的程度。
然而，Linux并不是真正的Unix。也就是说，虚拟化的“杀手应用程序”也许同我们现在所知道的虚拟化环境是不同的东西。
Monday, June 15, 2009
Secure alternative to telnet
Telnet is a protocol allowing you to connect to a remote system and run programs and commands on that system. It is very old and still very much in use today.
Unfortunately, Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, hub or gateway located on the network between the two hosts where Telnet is being used can intercept the packets passing by and obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Wireshark.
On the other hand, a program called ssh exists that can replace both telnet and ftp in a secure, encrypted way.
Ssh stands for Secure Shell. It will encrypt each connection with a random key, so that it is impossible or at least very hard for a third party to decrypt the connection and find the password, or spy on you.
Use putty (Here) if you are on windows or use "ssh" command (example shown below) from Linux/UNIX box to connect to the remote server.
# ssh 192.168.0.2
The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
RSA key fingerprint is 2b:91:9b:c1:a7:57:91:dc:93:b3:04:50:c0:b9:bd:ba.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.2' (RSA) to the list of known hosts.
Password:
Unfortunately, Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, hub or gateway located on the network between the two hosts where Telnet is being used can intercept the packets passing by and obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Wireshark.
On the other hand, a program called ssh exists that can replace both telnet and ftp in a secure, encrypted way.
Ssh stands for Secure Shell. It will encrypt each connection with a random key, so that it is impossible or at least very hard for a third party to decrypt the connection and find the password, or spy on you.
Use putty (Here) if you are on windows or use "ssh" command (example shown below) from Linux/UNIX box to connect to the remote server.
# ssh 192.168.0.2
The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
RSA key fingerprint is 2b:91:9b:c1:a7:57:91:dc:93:b3:04:50:c0:b9:bd:ba.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.2' (RSA) to the list of known hosts.
Password:
Thursday, June 11, 2009
Securing DNS Servers - Part 2
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.
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.
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)