Commentary: To protect against Domain Name System poisoning, consider these strategies
Chances are your agency is in the middle of locking down all its Domain Name System servers. Security vulnerabilities discovered this summer have caused government agencies to rush to implement the appropriately named DNS Security Extensions (DNSSEC). But keep in mind that there are a range of DNS vulnerabilities that could threaten the government's business continuity.
So let's examine DNS and the security problems a bit more closely.
As you might know, the Internet DNS is the international system for translating domain names into numeric locations. It also provides the official hierarchical naming system for all connected networks.
Many descriptions of DNS start with the world's top-level domains, including .gov, .mil, .org, .com, .edu and more. But sometimes it's easier to comprehend DNS from the bottom up. Taking that view is also a good way to understand why a government DNS server that lacks the new — and now required — DNSSEC can be vulnerable to fraud or spoofing.
So let's start the journey from an end user's computer.
When people need to reach your government agency via the Internet, they probably type www.YourAgencyName.gov into their Web browsers. Their computers, in turn, must find a way to translate that name into a numeric IP address. That's how the Internet finds your server.
Most Internet service providers maintain at least one DNS server. In fact, a local DNS server connection is part of each computer's TCP/IP properties when it is set up for Internet connectivity. The ISP's local DNS server is usually the first place the Web surfer's computer goes to look for the address translation.
If you work in a big organization, you probably have a local DNS server right in your building.
Traditionally, the local DNS server first tries to use its cache of resource record information to answer queries. Because those types of servers remember previous lookups in a cache, they are sometimes called caching name servers or caching resolvers. If the end user is trying to connect to a popular domain name, chances are it's already in the local DNS server's memory. That is called a recursive query.
But if there is no local record for the requested domain name, the DNS server can query other DNS servers on the network and send an answer back to the client. That is called an iterative query.
Somewhere between a recursive query and an iterative query, things can be spoofed or "poisoned." An attacker can send fake DNS information in response to a query. This fools the local DNS server into accepting the wrong information for a domain name. This is called cache poisoning because the server remembers the incorrect information in its cache. It will continue to provide the wrong information in future lookups.
Think of the Internet DNS as a distributed database system. Top-level domains and subdomains have to maintain one or more authoritative DNS servers that store records about domain names and the names of devices within that domain.
The DNS server at the top of the domain serves as the root. It is the ultimate authority, with the latest domain name information updated daily or even more often.
An iterative DNS lookup might need to reach all the way back upstream to the authoritative DNS root when it looks up domain names.
The good news is that authoritative name servers at the top of the DNS pyramid are not vulnerable to cache-poisoning attacks unless those servers are configured as both authoritative and recursive name servers.
The bad news is that depending on how high up in the DNS food chain a cache is poisoned, the bad data can trickle down to many other servers as domain names are looked up.
DNSSEC was created to better protect local DNS servers. That's why the federal government is hustling to install the solution on all DNS servers. But there are other things that can be done.
To protect against DNS poisoning, consider the following strategies:
* The authoritative name server on a government network should never be configured to also serve as a recursive name server.
* Install the official DNSSEC on your DNS server. Those extensions add data-origin authentication and data-integrity assurances.
* Look for patches for your server that randomly select a source port for DNS queries. Cache poisoning is more difficult if the port is not known.
* If possible, set your local DNS servers to greatly reduce the number of recursive lookups they perform.
* Fixing the government's servers is one thing. But cache poisoning can occur elsewhere on the Internet. That means a government employee connecting to a government network from an external ISP (from home or while on the road) could be vulnerable to DNS issues when trying to reach a government domain. Thus, managers should educate employees in how to spot spoofed Web pages, and they should consult ISPs to make sure they are working to address DNS security issues.
For a quick test, go to recursive.iana.org and point the test server at your home domain. That will tell you if your DNS servers are configured in a risky way.
Source: www.gcn.com/online/vol1_no1/47490-1.html
Chances are your agency is in the middle of locking down all its Domain Name System servers. Security vulnerabilities discovered this summer have caused government agencies to rush to implement the appropriately named DNS Security Extensions (DNSSEC). But keep in mind that there are a range of DNS vulnerabilities that could threaten the government's business continuity.
So let's examine DNS and the security problems a bit more closely.
As you might know, the Internet DNS is the international system for translating domain names into numeric locations. It also provides the official hierarchical naming system for all connected networks.
Many descriptions of DNS start with the world's top-level domains, including .gov, .mil, .org, .com, .edu and more. But sometimes it's easier to comprehend DNS from the bottom up. Taking that view is also a good way to understand why a government DNS server that lacks the new — and now required — DNSSEC can be vulnerable to fraud or spoofing.
So let's start the journey from an end user's computer.
When people need to reach your government agency via the Internet, they probably type www.YourAgencyName.gov into their Web browsers. Their computers, in turn, must find a way to translate that name into a numeric IP address. That's how the Internet finds your server.
Most Internet service providers maintain at least one DNS server. In fact, a local DNS server connection is part of each computer's TCP/IP properties when it is set up for Internet connectivity. The ISP's local DNS server is usually the first place the Web surfer's computer goes to look for the address translation.
If you work in a big organization, you probably have a local DNS server right in your building.
Traditionally, the local DNS server first tries to use its cache of resource record information to answer queries. Because those types of servers remember previous lookups in a cache, they are sometimes called caching name servers or caching resolvers. If the end user is trying to connect to a popular domain name, chances are it's already in the local DNS server's memory. That is called a recursive query.
But if there is no local record for the requested domain name, the DNS server can query other DNS servers on the network and send an answer back to the client. That is called an iterative query.
Somewhere between a recursive query and an iterative query, things can be spoofed or "poisoned." An attacker can send fake DNS information in response to a query. This fools the local DNS server into accepting the wrong information for a domain name. This is called cache poisoning because the server remembers the incorrect information in its cache. It will continue to provide the wrong information in future lookups.
Think of the Internet DNS as a distributed database system. Top-level domains and subdomains have to maintain one or more authoritative DNS servers that store records about domain names and the names of devices within that domain.
The DNS server at the top of the domain serves as the root. It is the ultimate authority, with the latest domain name information updated daily or even more often.
An iterative DNS lookup might need to reach all the way back upstream to the authoritative DNS root when it looks up domain names.
The good news is that authoritative name servers at the top of the DNS pyramid are not vulnerable to cache-poisoning attacks unless those servers are configured as both authoritative and recursive name servers.
The bad news is that depending on how high up in the DNS food chain a cache is poisoned, the bad data can trickle down to many other servers as domain names are looked up.
DNSSEC was created to better protect local DNS servers. That's why the federal government is hustling to install the solution on all DNS servers. But there are other things that can be done.
To protect against DNS poisoning, consider the following strategies:
* The authoritative name server on a government network should never be configured to also serve as a recursive name server.
* Install the official DNSSEC on your DNS server. Those extensions add data-origin authentication and data-integrity assurances.
* Look for patches for your server that randomly select a source port for DNS queries. Cache poisoning is more difficult if the port is not known.
* If possible, set your local DNS servers to greatly reduce the number of recursive lookups they perform.
* Fixing the government's servers is one thing. But cache poisoning can occur elsewhere on the Internet. That means a government employee connecting to a government network from an external ISP (from home or while on the road) could be vulnerable to DNS issues when trying to reach a government domain. Thus, managers should educate employees in how to spot spoofed Web pages, and they should consult ISPs to make sure they are working to address DNS security issues.
For a quick test, go to recursive.iana.org and point the test server at your home domain. That will tell you if your DNS servers are configured in a risky way.
Source: www.gcn.com/online/vol1_no1/47490-1.html
Posts
Can anyone recommend the robust Endpoint Security tool for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: N-able N-central performance management
ReplyDelete? What is your best take in cost vs performance among those three? I need a good advice please... Thanks in advance!