君，已阅读到文档的结尾了呢~~
GMAD Graph-based Malware Activity Detection by DNS traffic analysis
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
GMAD Graph-based Malware Activity Detection by DNS traffic analysis
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='http://www.docin.com/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口博客访问： 390939
博文数量： 325
博客积分： 4065
博客等级： 上校
技术积分： 3112
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 系统运维
最新版本的BIND 9.6用做DNS服务器，有一个allow-query选项，如果没有设，则默认只允许与DNS服务器同一段的地址进行DNS查询，其它的统统拒绝，在OPTION小节里加上一句:allow-query {0.0.0.0/0;};重启bind，OK!
阅读(3550) | 评论(1) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
很好的, 收藏了
推荐一个博客，提供很多免费软件编程电子书下载：
http://free-ebooks.appspot.com
请登录后评论。更多精彩内容,请访问云邮科技官方网站：现在位置： &
邮件服务器dns query fail怎么办?
作者： ⁄ 时间：日 ⁄ 分类：
对于邮件服务器,如果出现dns query fail,很多人可能感到头疼,其实,这个我们网管经常碰到的问题,对于这样的问题,其实解决的方案也是有多个的,下面给大家介绍几个常用的方法:
1: 自建DNS服务器
自建DNS服务器是一个常用的简单的方法,将邮件服务器的首选DNS设置为内网的DNS,然后在内网的DNS上建立对方的域名,把查询到的IP设置进去,设置就可以.这样邮件服务器就会发送到指定的IP
2: 修改HOSTS文件
这个也是一个简单的方便,假如域名是xxx.com,对应的MX解释到了mail.xxx.com,那么你可以查询下mail.xxx.com的IP,然后在HOSTS文件中写入即可
3: 设置MX缓存文件
有些软件,比如WINWEBMAIL等是有域名缓存文件的,这样的话,可以修改该文件让他们走指定的IP
4: POSTFIX的处理方法
POSTFIX可以使用transport来处理，也可以使用relayhost处理，我可以使用其它方式。在main.cf中加入:transport_maps = hash:/etc/postfix/transport
然后在transport编辑文件,写入下面的格式:
example.com & smtp:[xxx.xxx.xxx.xxx]
这样也可以搞定,方法总是很多的,就看你怎么用了!Block Malicious FQDNs, Suspicious Clients and Queries Using Windows DNS Server Policies
| LinkedIn
Following are some examples on how policies can be used to create filters. First we will see how to block certain queries using DNS policies&
Block queries for a domain
One of the widespread requirements from the DNS administrators is the ability to block name resolution for certain domains identified to be malicious or domains that do not comply with the usage guidelines of the organization. This can be achieved using Policies.
The following cmdlet will disallow any queries with domain suffix contosomalicious.com.&
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE&-FQDN "EQ,*.contosomalicious.com" -PassThru &
Note that this policy has not been created on any zone. Such policies are the Server Level Policies and are first to be matched when a query is incident on the DNS server.&
Block queries from a subnet
Another scenario is when a certain subnet has been found to be infected by some malware and is trying to contact malicious sites using DNS server. Using DNS policies now the administrators can block such subnets from using DNS server for any name resolution.&
Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet 172.0.33.0/24 -PassThru
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -Action IGNORE -ClientSubnet& "EQ,MaliciousSubnet06" -PassThru
&The subnet criteria can be used with the FQDN criteria in the first example to block& queries for certain malicious domains from infected subnets
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -Action IGNORE -ClientSubnet& "EQ,MaliciousSubnet06" –FQDN “EQ,*.contosomalicious.com” -PassThru&
Block a type of query
The DNS administrators may need to block name resolution for certain type of queries on their servers. One such example is the ‘ANY’ query which has been many times abused to created amplification attacks.
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyQType"&-Action IGNORE -QType "EQ,ANY" -PassThru
&Just the way DNS policies can be used to block queries based on certain criteria, they can also be used to white list certain domains or subnets. In case of white lists, the DNS server will process only those queries and ignore everything elseLooking for more of the latest headlines on LinkedIn?DNS Security
May the source be with you, but remember the KISS-)
DNS Security
No matter how secure and robust your web, mail and other servers are, compromised
and/or corrupted DNS systems can prevent customers and legitimate users from ever
reaching them.&
RFC2541, NSA, CERT and Center for Internet Security (CIS) are good documents
and administrators are expected to be familiar with those guidelines.
NSA have Microsoft DNS security guide ()
and much of the material is relevant to Unix DNS security. See also
- http://www.cert.org/archive/pdf/dns.pdf
CIS have benchmark for bind 9.3.1
The original DNS design was focused on availability not security and included
no authentication. Still DNS is used as key component of security infrastructure
as usually firewall rules operate with DNS names, not actual IP addresses. Because
of the lack of understanding of the critical role of DNS in the security infrastructure,
companies often neglect to manage and configure DNS properly. “It is clear that
a stunning number of companies have serious DNS configuration problems which can
lead to failure at any time.” states Cricket Liu the author of the Reilly
unfortunately widely known that DNS health on a global scale is poor. Anyone
doing business on the Internet needs to take DNS outages seriously.”
There are four major points of attack: cache spoofing, traffic diversion, distributed
denial-of-service (DDoS) attacks on the top-level domain servers themselves, and
buffer overflow attacks. See for example
Add to this attacks on underling OS. Such attacks
puts critical enterprise infrastructure, such as web presence and e-mail traffic,
at risk. Therefore adequate attention needs to be paid to securing DNS servers and
the OS on which they are running. Generally the OS should be secured on the level
typical of bastion host and have internal firewall enabled.
Approximately 80% of DNS servers run on bind. That means that might make sense
to stay away from the crowd. While abandonment of bind might be unwise, the first
line of defense is to use platform different from x86, OS different from Linux (Solaris,
AIX or OpenBSD) and compile BIND using the compiler different from gcc (for example
using Studio 11 on Solaris).& You can also buy a DNS appliance, but this is a mixed blessing.&
Solaris X86 can be run under Oracle VM, as Oracle servers are way too expensive for the purpose.
On 2001's ICANN security meeting Patrick Thibodeau
“Some of the vulnerabilities potentially affecting the domain name system
include its heavy reliance on Berkeley Internet Name Domain (BIND) software, which
is freely distributed by the Internet Software Consortium.”
In the summer of 1997, Eugene Kashpureff demonstrated vulnerability of DNS quite
convincingly by performing (as a protest against the InterNIC's monopoly over the
top-level domain names) the mother of all DNS hacks -- the redirection of all of
the traffic destined to the InterNIC to his own Alternic.net service (see
). More commonly, a DNS system that is not properly
hardened/configured and tells the world quite a lot, including staff than you do
not want them to know. This can simplify the creation of attacks on other elements
of IS infrastructure.
DNS vulnerabilities often make it to the very top of the list of most critical
security vulnerabilities, but that does not mean that understanding of DNS servers
security improves after this :-). See the SANS Institute paper:& &How To Eliminate
The Ten Most Critical Internet Security Threats: The Experts’ Consensus.& 12 July,
2000. Version 1.25. URL:
( 23 July, 2000).
DNS, like many of the older protocols, was developed at a time when the Internet
was a research network and was meant to provide a simple and unlimited way to provide
information about what computers you have to anyone else. Obviously the Internet
has changed, and changes to BIND 9 have improved our ability to lock down DNS.
Among important DNS security practices are:
If your organization has an intranet, you should provide separate views
of DNS to your internal users and your external customers.
Restrict zone transfers
Limit who can make queries
Harden the OS on which DNS server reside to the level of bastion host
Use internal firewall to block all unused ports to prevent exploitation
of remote vulnerabilities (for example RPC vulnerabilities, although generally
RPC services should not run on DNS server).
In firewalled environment you need to split DNS servers into internal and external.
Simplest DNS checks can be done using &dig& (Domain Information Groper). For
instance, the command
dig -t txt -c chaos VERSION.BIND@yoursite.org
will query for the version of BIND running on your DNS name server. You can block
this capability using in named.conf:
&&& version &0.1&;
But there are a lot of subtle things that you may miss in manual checks, so using
hardening tools are desirable. They do not guarantee anything as your understanding
of the DNS infrastructure cannot be matched by the tools but they can pinpoint some
blunders and inconsistencies and they are much more diligent that -).
Protecting DNS has several dimensions.
Since DNS security is one of the most complicated topics in DNS
and you can definitely can go too far getting zero or negative return on investment,
it is critical to understand first what you want to secure -- or rather what threat
level you want to secure against. This will be very different, if you run a large
corporation DNS server vs running a modest in-house DNS serving a couple of low
volume web sites.& Security is always a blend of real threat and paranoia --
but remember just because you are naturally paranoid does not mean that they are
not after you...& Some security measures like running bind in chrooted
environment and split DNS solutions are actually universal.& Solaris Zones
are even better solution. Other like blocking zones transfers make more sense to
external DNS.
If DNS is installed on Windows 2000 it should be compliant with
NSA guidelines
. This document contins a lot of useful information about
security Unix based DNS servers too.
Zone transfers pose a significant risk for organizations running DNS. While there
are legitimate and necessary reasons for why zone transfers occur, an attacker may
request a zone transfer from any domain name server or secondary name server on
the Internet. The reason attackers do this is to gather intimate details of an organization’s
internal network, and use this information for further reconnaissance or as a launch
pad for an attack.&& So set of IP from which zone transfers are accepted should be
restricted.
The attacker’s job is made even easier by the existence of legitimate websites
that host DNS tools that ease reconnaissance.
The risk that zone transfers pose may be reduced by incorporating a split-DNS
architecture. Split-DNS uses a public DNS domain server for publicly reachable services
within the DMZ, and a private DNS domain server for the private internal network. The public
DNS server, and usually public www and mail servers, are the only servers defined
in the public DNS server’s database. While the internal DNS server contains all
the private server and workstation information for the internal network in its DNS
databases.
If internal users are allowed to access the Internet, the firewall should allow
the internal DNS server to query the Internet. All DNS queries from the Internet
should use the external DNS server. Outbound DNS queries from the external DNS server
should also be permitted.
BIND version 8.1 (and higher) uses the “allow-query” directive,
which is also set in /etc/named.boot, to impose access list controls on IP address
The BIND tar file includes the tool “DIG” (Domain Information Groper), which
may be used to debug DNS servers and test security by generating queries that run
against the server. For instance, the command “dig -t txt -c chaos VERSION.BIND
@yourcompany.com” will query for the version of BIND running on the DNS
name server. BIND also comes with an older tool called “nslookup&. This is useful
for doing inverse IP address to host-name DNS queries. For instance, the command
“nslookup 10.5.4.3” will actually perform a regular DNS query on the
domain name 3.4.5.10.in-addr.arpa (the IP address is reversed).
Stateful firewall should enforce packet filtering for the UDP/TCP port 53 (DNS).
By doing so, IP packets bound for UDP port 53 from the Internet are limited to authorized
replies from queries made from the internal network. If such a packet was not replying
to a request from the internal DNS server, the firewall would deny it. The firewall
should also deny IP packets bound for TCP port 53 on the internal DNS server to
prevent unauthorized zone transfers. This is redundant if access control has been
established using BIND, but it establishes “defense in depth”.
Dr. Nikolai Bezroukov
Top Visited
Your browser does not support iframes.
( , Nov 17, 2012 )
( , Jul 15, 2008 )
( , May 15, 2008 )
( , May 19, 2005 )
by Paul Roberts
( , Apr 08, 2005
( , Mar 07, 2005 )
( , Feb 11, 2005 )
( , Jan 8, 2003 )
( , Jan 3, 2003 )
[Nov 17, 2012]
Jake Montgomery discovered that Bind incorrectly handled certain specific
combinations of RDATA. A remote attacker could use this flaw to cause Bind to
crash, resulting in a denial of service.
[Jul 15, 2008] :
Posted by kdawson on Tuesday July 15, @08:07AM
from the be-afraid-be-very-afraid-then-get-patching dept.
syncro writes &The recent massive, multi-vendor DNS patch advisory related
to , discovered by Dan Kaminsky, has made headline news.
However, the secretive preparation prior to the July 8th announcement and hype
around a promised full disclosure of the flaw by Dan on August 7 at the Black
Hat conference has generated a fair amount of backlash and skepticism among
hackers and the security research community. In a post on CircleID,
to these allegations. The
conclusion: 'Please do the following. First, take the advisory seriously - we're
not just a bunch of n00b alarmists, if we tell you your DNS house is on fire,
and we hand you a fire hose, take it. Second, take Secure DNS seriously, even
though there are intractable problems in its business and governance model -
deploy it locally and push on your vendors for the tools and services you need.
Third, stop complaining, we've all got a lot of work to do by August 7 and it's
a little silly to spend any time arguing when we need to be patching.'&
[May 15, 2008]
A server problem at the U.S. National Security Agency has knocked the secretive
intelligence agency off the Internet. The nsa.gov Web site was unresponsive
at 7 a.m. Pacific time Thursday and continued to be
throughout the morning for Internet users.
The Web site was unreachable because of a
with the NSA's DNS (Domain Name System) servers, said Danny McPherson,
chief research officer with Arbor Networks. DNS servers are used to translate
things like the Web addresses typed into machine-readable Internet Protocol
addresses that computers use to find each other on the Internet.
The agency's two authoritative DNS servers were unreachable Thursday morning,
McPherson said.
Because this DNS information is sometimes cached by Internet service providers,
the NSA would still be temporarily reachable by some users, but unless the problem
is fixed, NSA servers will be knocked completely off-line. That means that e-mail
sent to the agency will not be delivered, and in some cases, e-mail being sent
by the NSA would not get through.
&We are aware of the situation and our techs are working on it,& a NSA spokeswoman
said at 9:45 a.m. PT. She declined to identify herself.
A similar DNS problem knocked Youtube.com off-line in early May.
There are three possible reasons the DNS server was knocked off-line, McPherson
said. &It's either an internal routing problem of some sort on their side or
they've messed up some firewall or ACL [access control list] policy,& he said.
&Or they've taken their servers off-line because something happened.&
That &something else& could be a technical glitch or a hacking incident,
McPherson said.
In fact, the NSA has made some basic security mistakes with its DNS servers,
according to McPherson.
The NSA should have hosted its two authoritative DNS servers on different
machines, so that if a technical glitch knocked one of the servers off-line,
the other would still be reachable.
Compounding problems is the fact that the DNS servers are hosted
on a machine that is also being used as a Web server for the NSA's National
Computer Security Center.
&Say there was some Apache or Windows vulnerability and hackers controlled
that server, they would now own the DNS server for nsa.gov,& he said. &That
really surprised me. I wouldn't think that these guys would do something like
The NSA is responsible for analysis of foreign communications, but it is
also charged with helping protect the U.S. government against cyber attacks,
so the outage is an embarrassment for the agency.
&I am certain that someone's going to send an e-mail at some point that's
not going to get through,& McPherson said. &If it's related to national security
and it's not getting through, then as a U.S. citizen, that concerns me.&
(Anders Lotsson with Computer Sweden contributed to this report.)
[May 19, 2005]
Blue Security Kicked While It's Down
Hours after anti-spam company Blue Security
, the spammers whose attack caused the company to wave the white
flag have escalated their assault, knocking Blue Security's farewell message
and thousands more Web sites offline.
Just before midnight ET, Blue Security posted a notice on its home page that
it was bowing out of the anti-spam business due to concerted attacks against
its Web site that took millions of other sites and blogs with it. Within minutes
of that online posting, bluesecurity.com went down and remains inaccessible
at the time of this writing.
According to information obtained by Security Fix, the reason
is that the attackers were hellbent on taking down Blue Security's site again,
but had trouble because the company had signed up with
, which specializes
in protecting Web sites from && (DDoS) attacks.
These massive assaults harness the power of thousands of hacked PCs to swamp
sites with so much bogus traffic that they can no longer accommodate legitimate
visitors. Prolexic built its business catering to the sites most frequently
targeted by DDoS extortion attacks -- chiefly, online gambling and betting houses.
But the company also serves thousands of other businesses, including banks,
insurance companies and online payment processors.
For the past nine hours, however, most of Prolexic's customers have been
knocked offline by an attack that flanked its defenses. Turns out the attackers
decided not to attack Prolexic, but rather
, its main provider
of domain name system (DNS) services. (DNS is what helps direct Internet traffic
to its destination by translating human-readable domain names like &www.example.com&
into numeric Internet addresses that are easier for computers to understand.)
UltraDNS is the authoritative DNS provider for all Web sites ending in &.org&
and &.uk,& and also markets its && service designed to help sites defend against another, increasingly
common type of DDoS -- one that targets weaknesses inherent in the DNS system.
(Incidentally, UltraDNS was recently acquired by Neustar, which in turn is responsible
for handling all &.biz& domain registrations, and for overseeing the nation's
authoritative directory of telephone numbers.)
In this case, at least, it does not appear that the DNS Shield service worked
as advertised. Earlier today, I spoke with Prolexic founder Barrett
G. Lyon, who told me the attack on UltraDNS had knocked about 80 percent
of his company's clients offline, or roughly 2,000 or so Web businesses. Most
of those businesses also remain offline as of this writing.
According to Lyon, the unknown attackers hit a key portion of UltraDNS's
network with a flood of spoofed DNS requests at a rate of around 4 to 5 gigabits
per second, which is enough traffic to make just about any Web site on the Internet
fall over (many Internet routers can handle only a few hundred megabits of traffic
before they start to fail). But this was no normal DDoS attack-- it was a kind
of DDoS on the DNS system that security experts say has become alarmingly more
common over the past six to eight months.
or &reflected DNS attacks,& these kinds of DDoS
assaults increase the traffic hurled at a victim by orders of magnitude. In
a nutshell, the attackers find a whole bunch of poorly configured DNS servers
and use them to create and send spoofed DNS requests from systems they control
to the DNS servers they want to cripple. Because the DNS requests appear to
be coming from other trusted DNS servers, the target servers have trouble distinguishing
regular, legitimate DNS lookups from ones sent by the attackers. Sustained for
long enough, the attack eventually overloads the victim's DNS servers with queries
and knocks them out of commission.
To put the raw power of DNS amplification into perspective, consider the
For anyone unfamiliar with this company,
sells a rather pricey
service that lets deep-pocketed companies like FedEx, Microsoft and Xerox mirror
their Web site content at thousands of different online servers, making DDoS
attacks against their sites extremely difficult.
Akamai was for a long time considered the gold standard until one day in
June 2004, when a DDoS attack knocked the company's services offline for about
an hour. Akamai never talked publicly about the specifics of the attack, but
several sources close to the investigation told me later that the outage was
the result of a carefully coordinated DNS amplification attack -- one that was
stopped when the attackers decided they had made their point (which was no doubt
to demonstrate to would-be buyers of their DDoS services that they could knock
just about anyone off the face of the Web.)
So where am I going with all of this? Well, UltraDNS marketed its DNS Shield
as a protection against exactly these same types of amplification attacks. Only
in this case it doesn't appear to have worked -- though, to be fair I haven't
heard UltraDNS's side of the story since they have yet to return my calls. No
doubt they are busy putting out fires. At any rate, score another one for the
spammers, I suppose.
Update, 7:46 p.m. ET: I heard back from Neustar. Their spokesperson,
Elizabeth Penniman, declined to discuss anything about today's
attacks, saying only that &we have a handle on the situation and continue to
work with service providers to ensure the best possible level of service to
our customers.&
[Apr 08, 2005 ]
by Paul Roberts
April 08, 2005 (IDG News Service) Problems with the Domain Name System
(DNS) servers at Internet service provider Comcast Corp. prevented customers
around the U.S. from surfing the Web yesterday, but the company said the interruptions
weren't linked in any way to a spate of recent DNS attacks known as &pharming&
Comcast technicians noticed problems with the Philadelphia-based company's
DNS servers around 6:30 p.m. EDT. The problems interrupted DNS service to Comcast
high-speed Internet customers across the U.S. just hours after the SANS Institute's
advised Internet service providers to make sure their DNS servers
weren't vulnerable to new attacks.
However, the outage wasn't caused by those attacks or by maintenance related
to the attacks, according to company spokeswoman Jeanne Russo.
During the outage, Comcast customers who attempted to connect to Web sites
such as Google.com received frequent &Page not found& errors on their Web browsers.
However, entering the numeric Internet Protocol address of the Web site in question
would connect the user to the page.
Comcast technicians began working on the DNS problem immediately after identifying
it yesterday evening and restored service to the company's customers by 12:00
a.m. EDT today, Russo said.
The DNS is a global network of computers that translates requests for reader-friendly
Web domains, such as www.computerworld.com, into the numeric IP addresses
that machines on the Internet use to communicate.
The recent attacks on DNS servers use a strategy called &DNS cache poisoning,&
in which malicious hackers use a DNS server they control to feed erroneous information
to other DNS servers. The attacks take advantage of a vulnerable feature
of DNS that allows any DNS server that receives a request about the IP address
of a Web domain to return information about the address of other Web domains.
Online criminal groups and malicious hackers have used DNS cache poisoning
recently in pharming scams, which are similar to phishing identity theft attacks
but don't require a lure, such as a Web link that victims must click on to be
taken to the attack Web site. Instead, corrupted DNS servers forward Internet
users who are looking for legitimate Web pages, such as Google.com, to Web pages
controlled by the attackers, which harvest personal information such as user
names and passwords from the victims or install Trojan horse programs or other
malicious code, according to the
The attacks have been increasing in recent months, as Internet users become
more savvy about traditional phishing scams and online criminal groups look
for new ways to collect sensitive information or financial data from victims,
the Anti-Phishing Working Group said.
In March, a rogue DNS server posed as the authoritative DNS server for the
entire .com Web domain. Other DNS servers that were poisoned with this false
information redirected all .com requests to the rogue server, which responded
to all .com requests with one of two IP addresses controlled by the attackers.
An earlier attack in March targeted vulnerable products from Symantec Corp.
and other companies to redirect requests from more than 900 unique Internet
addresses and more than 75,000 e-mail messages, according to log data obtained
from compromised Web servers that were used in the attacks, the Internet Storm
Center said.
In recent days, a spate of such attacks prompted the Internet Storm Center
to issue a &code yellow&
signifying increasing threats on the Internet, and prompted Microsoft Corp.
to issue revised instructions for configuring Windows machines used as DNS servers
to prevent cache poisoning.
[Mar 07, 2005]
Online scam artists are manipulating the Internet's directory service and taking
advantage of a hole in some Symantec Corp. products to trick Internet users
into installing adware and other annoying programs on their computers, according
to an Internet security monitoring organization.
Customers who use older versions of Symantec's Gateway Security Appliance
and Enterprise Firewall are being hit by Domain Name System (DNS) &poisoning
attacks.& Such attacks cause Web browsers pointed at popular Web sites
such as Google.com, eBay.com and Weather.com to go to malicious Web pages that
install unwanted programs, according to Johannes Ullrich, chief technology officer
at the SANS Institute's Internet Storm Center (ISC).
The attacks, which began on Thursday or Friday, may be one of the largest
to use DNS poisoning, Ullrich said.
Symantec issued an
for the DNS poisoning hole on Friday. The company didn't
immediately respond to requests for comment today.
The DNS is a global network of computers that translates requests for reader-friendly
Web domains, such as
into the numeric IP addresses that machines on the Internet use to communicate.
In DNS poisoning attacks, malicious hackers take advantage of a feature that
allows any DNS server that receives a request about the IP address of a Web
domain to return information about the address of other Web domains.
For example, a DNS server could respond to a request for the address of
www.yahoo.com with information on the address of www.google.com
or www.amazon.com, even if information on those domains wasn't requested.
The updated addresses are stored by the requesting DNS server in a temporary
listing, or cache, of Internet domains and used to respond to future requests.
In poisoning attacks, malicious hackers use a DNS server they control to
send out erroneous addresses to other DNS servers. Internet users who rely on
a poisoned DNS server to manage their Web surfing requests might find that entering
the URL of a well-known Web site directs them to an unexpected or malicious
Web page, Ullrich said.
Some Symantec products, such as the Enterprise Security Gateway, include
a proxy that can be used as a DNS server for users on the network that the product
protects. That DNS proxy is vulnerable to the DNS poisoning attack,
Symantec said on its Web site. Symantec's Enterprise Firewall Versions 7.04
and 8.0 for Microsoft Corp.'s Windows and Sun Microsystems Inc.'s Solaris have
the DNS poisoning flaw, as do Versions 1.0 and 2.0 of the company's Gateway
Security Appliance.
Internet users on some networks protected by the vulnerable Symantec products
had requests for Web sites directed to attack Web pages that attempted to install
the ABX tool bar, a search tool bar and spyware program that displays pop-up
ads, Ullrich said.
The DNS poisoning attacks were easy to detect because Web sites involved
in the attack don't mimic the sites that users were trying to reach, Ullrich
said. However, DNS poisoning could be a potent tool for online identity thieves
who could set up phishing Web sites that are identical to sites like Google.com
or eBay.com but secretly capture user information, he said.
Some of those customers told ISC that they installed a patch that the company
issued in June to fix a DNS cache-poisoning problem in many of the same products,
but they were still susceptible to the latest DNS cache-poisoning attacks, according
to information on the ISC Web site.
Ullrich said he doesn't believe that Symantec's customers are being targeted,
just that they are susceptible to attacks that are being launched at a broad
swath of DNS servers.
The ISC is collecting the Internet addresses of Web sites and DNS servers
used in the attack and trying to have them shut down or blacklisted, ISC said.
Symantec customers using one of the affected products are advised to install
the most recent hotfixes from the company, Ullrich said.
The following are assumed:
The role is: dnsrole
The user is: dnsadmin
The profile is: DNS Admin ( case sensitive )
Home directory for dnsrole is: /export/home/dnsrole
Home directory for dnsadmin is: /export/home/dnsadmin
Configuration Steps
1. Create the role and assign it a password:
# roleadd -u 1001 -g 10 -d /export/home/dnsrole -m dnsrole
# passwd dnsrole
NOTE: Check in /etc/passwd that the shell is /bin/pfsh. This ensures that
nobody can log in as the role.
Example line in /etc/passwd:
dnsrole:x:1001:10::/export/home/dnsrole:/bin/pfsh
2. Create the profile called &DNS Admin&:
Edit /etc/security/prof_attr and insert the following line:
DNS Admin:::BIND Domain Name System administrator:
3. Add profile to the role using rolemod(1) or by editing /etc/user_attr:
# rolemod -P &DNS Admin& dnsrole
Verify that the changes have been made in /etc/user_attr with
profiles(1) or grep(1):
# profiles dnsrole
Basic Solaris User
# grep dnsrole /etc/user_attr
dnsrole::::type=profiles=DNS Admin
Assign the role 'dnsrole' to the user 'dnsadmin':
If 'dnsadmin' already exists then use usermod(1M) to add the role (user
must not be
logged in):
# usermod -R dnsrole dnsadmin
Otherwise create new user using useradd(1M) and passwd(1):
# useradd -u 1002 -g 10 -d /export/home/dnsadmin -m \
-s /bin/ksh -R dnsrole dnsadmin
# passwd dnsadmin
Confirm user has been added to role with roles(1) or grep(1):
# roles dnsadmi
# grep ^dnsadmin: /etc/user_attr
dnsadmin::::type=roles=dnsrole
5. Assign commands to the profile 'dns':
Add the following entries to /etc/security/exec_attr:
DNS Admin:suser:cmd:BIND 8:BIND 8 DNS:/usr/sbin/in.named:uid=0
DNS Admin:suser:cmd:ndc:BIND 8 control program:/usr/sbin/ndc:uid=0
If using Solaris 10 you may need to add a rule for BIND 9:
DNS Admin:suser:cmd:BIND 9:BIND 9 DNS:/usr/sfw/sbin/named:uid=0
BIND 9 does not use ndc, instead
rndc(1M) is used which does not require
6. Create or Modify named configuration files.
To further limit the use of root in configuring and maintaining BIND make
dnsadmin the owner of /etc/named.conf and the directory it specifies.
# chown dnsadmin /etc/named.conf
# grep -i directory /etc/named.conf
directory &/var/named/&;
# chown dnsadmin /var/named
7. Test the configuration:
Login as the user &dnsadmin& and start named:
$ su dnsrole -c '/usr/sbin/in.named -u dnsadmin'
To stop named use ndc (for BIND 9 use rndc):
$ su dnsrole -c '/usr/sbin/ndc stop'
In this example the user 'dnsadmin' has been set up to manage the DNS configuration
files and assume the role 'dnsrole' to start the named process.
The role 'dnsrole' is only used to start named and to control it with ndc
(for BIND 8).
With this RBAC configuration the DNS process when started by user 'dnsrole'
would acquire root privileges and thus have access to its configuration files.
The named options '-u dnsadmin' may be used to specify the user that the
server should run as after it initializes.
Furthermore 'dnsadmin' is then
permitted to send signals to named as described in the named manual page.
References:
ndc(1M), named(1M), rbac(5), profiles(1), rolemod(1M), roles(1),
rndc(1M), usermod(1M), useradd(1M)
[Feb 11, 2005]
The following are assumed:
The role is: dnsrole
The user is: dnsadmin
The profile is: DNS Admin ( case sensitive )
Home directory for dnsrole is: /export/home/dnsrole
Home directory for dnsadmin is: /export/home/dnsadmin
Configuration Steps
1. Create the role and assign it a password:
# roleadd -u 1001 -g 10 -d /export/home/dnsrole -m dnsrole
# passwd dnsrole
NOTE: Check in /etc/passwd that the shell is /bin/pfsh. This ensures that
nobody can log in as the role.
Example line in /etc/passwd:
dnsrole:x:1001:10::/export/home/dnsrole:/bin/pfsh
2. Create the profile called &DNS Admin&:
Edit /etc/security/prof_attr and insert the following line:
DNS Admin:::BIND Domain Name System administrator:
3. Add profile to the role using rolemod(1) or by editing /etc/user_attr:
# rolemod -P &DNS Admin& dnsrole
Verify that the changes have been made in /etc/user_attr with
profiles(1) or grep(1):
# profiles dnsrole
Basic Solaris User
# grep dnsrole /etc/user_attr
dnsrole::::type=profiles=DNS Admin
Assign the role 'dnsrole' to the user 'dnsadmin':
If 'dnsadmin' already exists then use usermod(1M) to add the role (user
must not be
logged in):
# usermod -R dnsrole dnsadmin
Otherwise create new user using useradd(1M) and passwd(1):
# useradd -u 1002 -g 10 -d /export/home/dnsadmin -m \
-s /bin/ksh -R dnsrole dnsadmin
# passwd dnsadmin
Confirm user has been added to role with roles(1) or grep(1):
# roles dnsadmi
# grep ^dnsadmin: /etc/user_attr
dnsadmin::::type=roles=dnsrole
5. Assign commands to the profile 'dns':
Add the following entries to /etc/security/exec_attr:
DNS Admin:suser:cmd:BIND 8:BIND 8 DNS:/usr/sbin/in.named:uid=0
DNS Admin:suser:cmd:ndc:BIND 8 control program:/usr/sbin/ndc:uid=0
If using Solaris 10 you may need to add a rule for BIND 9:
DNS Admin:suser:cmd:BIND 9:BIND 9 DNS:/usr/sfw/sbin/named:uid=0
BIND 9 does not use ndc, instead
rndc(1M) is used which does not require
6. Create or Modify named configuration files.
To further limit the use of root in configuring and maintaining BIND make
dnsadmin the owner of /etc/named.conf and the directory it specifies.
# chown dnsadmin /etc/named.conf
# grep -i directory /etc/named.conf
directory &/var/named/&;
# chown dnsadmin /var/named
7. Test the configuration:
Login as the user &dnsadmin& and start named:
$ su dnsrole -c '/usr/sbin/in.named -u dnsadmin'
To stop named use ndc (for BIND 9 use rndc):
$ su dnsrole -c '/usr/sbin/ndc stop'
In this example the user 'dnsadmin' has been set up to manage the DNS configuration
files and assume the role 'dnsrole' to start the named process.
The role 'dnsrole' is only used to start named and to control it with ndc
(for BIND 8).
With this RBAC configuration the DNS process when started by user 'dnsrole'
would acquire root privileges and thus have access to its configuration files.
The named options '-u dnsadmin' may be used to specify the user that the
server should run as after it initializes.
Furthermore 'dnsadmin' is then
permitted to send signals to named as described in the named manual page.
References:
ndc(1M), named(1M), rbac(5), profiles(1), rolemod(1M), roles(1),
rndc(1M), usermod(1M), useradd(1M)
If you are a DNS administrator for anything more than a few dozen hosts,
it's easy for your database to get out of sync with what's really on your network.
The GPL software tool, Hawk, is designed to help administrators track which
hosts in DNS are really on your network and, just as importantly, which hosts
are on your network but not in DNS. Hawk can help take the mystery out of DNS
maintenance, resulting in a much cleaner, up-to-date database.
Hawk consists of three components: a monitor written in Perl, a MySQL database
backend, and a PHP Web interface. The monitor periodically checks whether hosts
on your network appear in DNS and are answering on your network. It checks for
existence on the network by way of an ICMP ping. I mention ICMP because by default,
the Perl Net::Ping module "pings" by attempting a UDP connection to a host's
echo port. With the various types of hosts possible on a typical network, this
is probably not desirable. As each IP address on your network is polled, the
monitor records or updates in the database the current IP address and the hostname,
if one exists. If the ping is successful, this timestamp is also recorded in
the database.
The Hawk interface consists of a Web page that allows you to choose which
"network" to view and how to sort the results. You can also choose whether to
view addresses that are neither in DNS nor have responded to pings. These are
typically uninteresting, so by default they are not displayed. Each host displayed
on the page has a hostname (if available), a last ping time, and a colored "LED"
indicating the current status of the address. The LED color will indicate one
of five states:
Green - Address exists in DNS, and is currently answering pings.
Yellow - Address exists in DNS, but has not answered in more than 24
hours (configurable).
Red - Address exists in DNS, but has not answered in more than 1 week
(configurable).
Blue - Address does not exist in DNS, however it is answering pings.
This could indicate an unauthorized use of an address, or it could indicate
something such as a DHCP - assigned address that has no DNS entry.
Purple - Address does not exist in DNS, and does not answer pings. This
is generally uninteresting to us, so by default these hosts are not displayed.
Installation
As previously mentioned, Hawk has three components. These components may
each be hosted on separate machines or the same machine, depending on your environment.
The monitor should run happily with any version of Perl 5. But the following
additional modules will need to be installed: Net::Netmask, Net::Ping, DBI,
and DBD::mysql. You can install these modules as follows:
# perl -MCPAN -e &install Net::Netmask&
# perl -MCPAN -e &install Net::Ping&
# perl -MCPAN -e &install DBI&
# perl -MCPAN -e &install DBD::mysql&
The database used for storing Hawk's data is MySQL. Hawk was originally written
using MySQL 3.23, but since the database requirements are minimal, you can probably
get away with older versions, and certainly newer ones. Before the Perl backend
and PHP frontend can communicate with the database, you must create the appropriate
database and table to store the data. Next, you need to create a database user
to allow read and write access to the data from the scripts. Connect to the
database as follows:
# mysql --user=&mysql admin user& --password --host=&mysql server&
Enter password:
Welcome to the MySQL monitor.
Your MySQL connection id is 8 to server version: 3.23.40-log
Type '' or '\h' for help. Type '\c' to clear the buffer.
Create the database "hawk" and table "ip" using the following SQL statements:
create table ip (
ip char(16) NOT NULL default '0',
hostname char(255) default NULL,
lastping int(10) default NULL,
primary key
unique key ip (ip),
key ip_2 (ip)
) type=MyISAM comment='Table for last ping time of hosts';
Create the user "hawk" using the following SQL:
grant select,insert,update,delete
to hawk@localhost
identified by 'hawk';
grant select,insert,update,delete
to hawk@&%&
identified by 'hawk';
This will give permission for the user "hawk" to do basic selects and updates
from any host on the network. For added security, you can limit this to a given
host by changing the "%" to a specific hostname.
For managing MySQL, you may want to consider installing phpMyAdmin, which
is available from:
phpMyAdmin is a Web-based tool for administering MySQL databases. It can
be used to add/drop databases, create/drop/alter tables, delete/edit/add fields,
execute SQL, manage keys, and import/export data. You can use this tool later
in the installation process to verify that your database is being populated
with data.
Apache/PHP
The interface was written using PHP 4.0.6 under Apache 1.3.22. Later versions
of PHP should work fine, and any version of Apache will probably work. If your
Web server is running on the same machine as the Hawk monitor, you can simply
make a symbolic link in the Apache document root to the PHP directory of hawk
as follows:
# cd /var/apache/htdocs
# ln -s /opt/hawk/php hawk
If you are running on separate machines, you will need to copy the entire
PHP directory from the installation directory to a directory named "hawk" within
the Apache document root.
Hawk is hosted at SourceForge. To download, go to:
Under "Latest File Releases", click Download and you will be taken to the
download page. The latest version will be highlighted. This article is based
on Hawk version 0.6. The downloaded file will be called hawk-0.6.tar.gz.
You can save this in the directory in which you want to extract the Hawk program,
(e.g., /opt). Extract the software as follows:
# tar xvzf hawk-0.6.tar.gz
# ln -s /opt/hawk-0.6 /opt/hawk
Within the installation directory, you have two subdirectories - one for
the monitor and one for the PHP interface. Following is a basic breakdown of
what is installed:
- directory for perl monitor daemon
./daemon/hawk
- the monitor daemon
./daemon/hawk.conf
- config file for monitor daemon
- directory for php interface
./php/hawk.conf.inc
- php web interface config file
./php/hawk.css
- style sheet file for web interface
./php/hawk.php
- web interface script
./php/images
- directory for web interface images
The first step to configure Hawk is to edit the monitor config file daemon/hawk.conf.
The variables in this file need to follow standard Perl syntax conventions,
as this file is read into the monitor script using a "do" statement. Configurable
parameters in the config file are as follows:
@networks - This should contain a list of local networks you
want to be monitored by Hawk. The networks must be specified in CIDR format.
That is, if you have a class C network (24 bits) of the range 192.168.2.0-255,
the CIDR form would be "192.168.2.0/24."
@gateways - This should contain the list of gateways used by
all networks. This parameter is not required, however if it is used, the
monitor will verify that the gateway is up before trying the rest of the
hosts on that network.
$frequency - This parameter is the number of seconds between
checks. A 0 value will cause the monitor to loop continuously.
$pingtimeout - This variable indicates how long a ping will wait
before giving up and moving on to the next host.
$debuglevel - This can be set at 0-2. During initial setup, you
may want to use debug level 2. This will allow you to see every ping, and
verify database operations. Level 1 will give basic progress reports (e.g.,
when each network is being checked). Level 0 is, of course, no logging at
all. You probably want to switch to level 1 or 0 after initial install.
$logfile - The name of the logfile where the above debugging
information is written.
$dbuser: mysql database username
$dbpass: mysql database password
$dbhost: database server hostname or ip address
$dbname: database name (&hawk&)
$pidfile: pid file used for shutting down and restarting hawk.
See hawk.conf.sample ().
The PHP backend has a similar simple configuration. The config file is php/hawk.conf.inc.
This file is sourced into the main hawk.php script so, like the monitor config
file, it must contain syntax understood by PHP. The configurable parameters
are as follows:
$dbuser, $dbpass, $dbhost, $dbname - Should
be set to the same as above.
$redzone - If a host has not been ping-able in this amount of
time (in seconds), the LED will glow red.
$yellowzone - If a host has not been ping-able in this amount
of time (in seconds), the LED will glow yellow, unless it has also surpassed
$networks - This should contain all the networks you specified
within your hawk.conf file above. However, each of the networks is paired
with a human-readable name for this parameter. If your network contains
a really large broadcast domain, it may be too large for easy viewing on
a single Web page, in which case you can break it into logical pieces. You
can do so by specifying smaller, adjacent networks. For example, if you
specified 192.168.4.0/22 in your daemon/hawk.conf above, you can break that
into the following networks in php/hawk.conf.inc for display purposes: 192.168.4.0/24,
192.168.5.0/24, 192.168.6.0/24, 192.168.7.0/24. See hawk.conf.inc.sample
The look and feel of the Web interface for Hawk are customizable using cascading
style sheets. All of the styles have been placed into a separate CSS file, php/hawk.css.
Running Hawk
After installation of all components is complete, the next step is to start
Hawk by hand and watch the logfile to verify proper operation:
# /opt/hawk-0.6/daemon/hawk &
# tail -f /var/log/hawk
If you set your $debuglevel to 2, this should provide a sufficient level
of detail to identify any problems. The most common problem is database connectivity.
If the logging seems to hang at the point it is doing a database access, the
database server name might be the issue. This will also eventually cause the
script to fail and exit. If there is a problem with user credentials (e.g.,
username/password), the script will fail immediately. Once database connectivity
is properly established, the log should display every ping attempt and every
database access/update. Also, verify that data is going into the database by
viewing database logs or using a tool like phpMyAdmin.
Once proper operation is verified above, configure your system to start Hawk
at boot. Below is a sample init.d script that can be used for starting/stopping/restarting
Hawk. See hawk.init.d.sample ().
You will need to copy the script into your init.d directory and make symbolic
links to the appropriate rc?.d directories as follows:
For the 0, 1, S, and 6, runlevels:
ln -s /etc/init.d/hawk /etc/rc0.d/K90hawk
ln -s /etc/init.d/hawk /etc/rc1.d/K90hawk
ln -s /etc/init.d/hawk /etc/rc6.d/K90hawk
ln -s /etc/init.d/hawk /etc/rcS.d/K90hawk
For the 2, 3, and 4 runlevels:
ln -s /etc/init.d/hawk /etc/rc2.d/S90hawk
ln -s /etc/init.d/hawk /etc/rc3.d/S90hawk
ln -s /etc/init.d/hawk /etc/rc4.d/S90hawk
The location of init.d and rc?.d directories will vary between systems, so
modify the commands to match the layout of your system. Also, runlevel 5 is
used differently on different systems. Some UNIX systems use runlevel 5 for
shutdown, while some Linux systems use runlevel 5 as the default runlevel. Verify
how your system uses this runlevel and create the appropriate symbolic links
Once you've verified proper operation of Hawk and installed the above startup
scripts, reboot your system at the next opportunity to verify proper startup.
Next, you need to verify the interface is working properly by opening the
page in your browser. The URL should be something like
When the page loads, select a network and click "Go". The page will be redisplayed
listing the hosts on your network as in
. If this does not work as expected, database connectivity is most
likely the problem. PHP will generally report any connectivity problems directly
on the Web page. The error messages given are usually very specific and you
should be able to identify the problem right away. You should also check your
MySQL log to verify the PHP queries are actually reaching the database.
If you were successful with your installation, you will be able to use Hawk
to manage your DNS with a little more sanity.
Greg Heim has been working as a UNIX systems administrator for 13 years.
He has a strong background in programming and relational databases. He can be
contacted at: .
Zone transfers are preventable at the firewall and routers on the perimeter
of your network. DNS client queries are transmitted on UDP port 53, and TCP
port 53 is used for zone transfers. Zone transfers outside of the protected
network (outside your firewall) via TCP port 53 should be avoided.
Most organizations have internet-facing systems with both internal and external
DNS servers to service each zone. In this case, incoming UDP and TCP port 53
should be blocked at the internal and external firewall, and DMZ routers. Allow
TCP port 53 only through the routers and firewall which connect the internal
and external DNS servers. To resolve queries for external names made by internal
hosts, the internal DNS servers should forward queries out to the external DNS
servers. External DNS servers in front of the firewall should be configured
with root hints pointing to the root servers for the Internet. External hosts
should use only the external DNS servers for Internet name resolution.
Even though Windows Server 2003 DNS only performs zone transfers with servers
that are listed in the zone's Name Server (NS) resource records, you should
still set your Windows DNS server to only allow zone transfers with specific
IP addresses. Only allow reverse lookup zones to external DNS servers
if necessary. Network Address Translation (NAT) ()
is a very good strategy to use on many networks and can be implemented on the
DMZ where the DNS server is situated. NATing adds further protection from hackers
and intruders as is obfuscates the issue by translating IP addresses to predetermined
address ranges. Restricting zone transfers to only authorized or known servers
also helps prevent the injection of unauthorized data into your DNS zone files
by an attacker. If an attacker can't capture your zone data from a zone transfer,
he won't be able to determine the makeup of your network and do ugly things
such as spoofing IP addresses to make them appear to have come from an internal
Windows DNS Zone Transfer Configuration
(Click for a larger image)
Another option, and undoubtedly the one Microsoft would prefer you use, is
to use only AD-integrated DNS zones, as opposed to Standard DNS zones. AD-integrated
DNS servers will only participate in zone replication with other AD-integrated
DNS servers. Also, all DNS servers hosting AD-integrated zones must be registered
in AD before they'll even be functional, and replication traffic between AD-integrated
DNS servers is encrypted.
DNS Cache Poisoning is a situation in which an attacker is able to
predict the DNS sequence numbers in a DNS conversation between server and client,
and then insert bogus data into the data stream. This can be used by the attacker
in a number of ways including redirecting a popular search engine to a pop-up
ad site, or redirecting a user to a bogus bank website to gain access to account
passwords.
Windows Server 2003 DNS servers use a secure response option that
eliminates the addition of unrelated resource records that are included in a
referral answer to the cache. Typically, a DNS server caches any names in referral
answers, expediting the resolution of subsequent DNS queries. However, when
the Secure Cache Against Pollution option is enabled, which it is by
default on Windows 2003 DNS servers, the server can determine whether the referred
name is polluting or insecure and discard it. The server determines whether
to cache the name offered in the referral depending on whether it is part of
the exact DNS domain tree for which the original name query was made. As an
example, a query made for marketing.companysix.com with a referral answer
of companyeight.net would not be cached.
Windows 2003 'Secure Cache Against Pollution Setting'
(Click for a larger image)
If you have BIND-based DNS servers in your environment, you should update
to BIND 9, which helps alleviate some of the more commonly used methods of DNS
cache poisoning. It doesn't prevent them, however it does contain some improvements
to the BIND protocol that make cache poisoning more difficult.
Denial of Service (DoS) attacks can occur when an attacker attempts
to obstruct the availability of network services by flooding one or more DNS
servers in the network with recursive queries or zone transfer requests. As
a DNS server is flooded with queries, its resources will eventually reach their
maximum and the DNS Server service will become unavailable. Blocking UDP and
TCP port 53 at internal and external firewalls and DMZ routers should help alleviate
this, as well as only allowing DNS-related traffic to and from authorized servers.
There is a feature built into Windows 200x DNS called zone transfer metering.
When a zone transfer occurs within the server, the server won't allow another
zone transfer to happen for a period of time, because it is possible that a
denial of service attack could be perpetrated on the server by flooding it with
requests for zone transfers and queries causing the to be locked and preventing
it from being able to do updates or answer queries efficiently - or at all.
Also on DNS at ENP
Client security and Dynamic updates: Dynamic updates are required for
Active Directory-integrated zones. For highest protection, AD should be configured
to allow secure dynamic updates or dynamic updates from DHCP instead of DNS
clients wherever possible, to increase security of the DNS zone data. When using
Secure Dynamic Updates, the DNS zone information is stored in Active Directory
and thus is protected using Active Directory security features. When a zone
has been configured as an Active Directory-integrated zone, Access Control List
(ACL) entries can be used to specify which users, computers, and groups can
make changes to a zone or a specific record. This restricts your DNS server
to only accept new registrations from computers that have a computer account
in Active Directory, and to only accept updates from the computer that registered
the DNS record initially. It also forces the DHCP server and/or client PC's
to encrypt the information.
DNS Security (DNSSEC, RFC2535) is a public key infrastructure (PKI)
based system in which authentication and data integrity can be provided to DNS
resolvers. Digital signatures are used and encrypted with private keys. These
digital signatures can then be authenticated by DNSSEC-aware resolvers by using
the corresponding public key. The required digital signature and public keys
are added to the DNS zone in the form of resource records.
The public key is stored in the KEY RR (Resource Record), and the digital
signature is stored in the SIG RR. The KEY RR must be supplied to the DNS resolver
before it can successfully authenticate the SIG RR. DNSSEC also introduces one
additional RR, the NXT RR, which is used to cryptographically assure the resolver
that a particular RR does not exist in the zone.
DNSSEC is only partially supported in Windows Server 2003 DNS, providing
basic support as specified in RFC 2535. A Windows Server 2003 DNS server can
only operate as a secondary to a BIND server that fully supports DNSSEC. The
support is partial because DNS in Windows Server 2003 does not provide any means
to sign or verify the digital signatures. In addition, the Windows Server 2003
DNS resolver does not validate any of the DNSSEC data that is returned as a
result of queries.
All of this by no means covers everything you need to know about installing
and hardening your Windows-based DNS servers, but it should be a good start
in giving you a better idea of the key things you need to do to protect your
servers and your network. Grab some aspirin
We're not filtering UDP on port 53, but nobody can resolve from us. What
do we need to change? Old versions of BIND made DNS resolution queries by
attaching to port 53 of the remote nameserver and receiving replies back on
port 53 as well. The new software connects to port 53, but the back-channel
for data is designated as a random channel at port 1023 or higher.
This presents a problem for sites that are filtering UDP traffic on port 1023
or higher.
Most &older& firewalls will have ports 1023 and higher filtered as a matter
of course. This will result in resolvers using BIND 8.1.1 not being able to
get proper name resolution for sites behind those firewalls. This impacts customers
using Allegiance Internet name resolvers, since those name servers will not
be able to query the remote site about the names in question, and will time
If you are running a firewall and nameservers, it is necessary to
remove UDP filtering for your nameserver from not only port 53
but 1023 and higher.
Won't removal of those filters create a security hole in my network?
No. You do not need to open up ports 1023 and higher for all machines on
only the nameservers. Most, if not all, firewall products will
allow the selection of specific ports to be opened for specific machines. If
you are a Allegiance Internet customer and your firewall product does not permit
this, Allegiance Internet Security Services (800-581-8711) can assist you with
possible solutions.
This might be bogus information. Treat it skeptically
Around 22:30 GMT on March 3, 2005 the SANS Internet Storm Center began receiving
reports from multiple sites about DNS cache poisoning attacks that were redirecting
users to websites hosting malware.
As the &Handler on Duty& for March
4, I began investigating the incident over the course of the following hours
This report is intended to provide useful details about this
incident to the community.
The initial reports showed solid evidence of DNS cache poisoning, but there
also seemed to be a spyware/adware/malware component at work. After complete
analysis, the attack involved several different technologies: dynamic DNS, DNS
cache poisoning, a bug in Symantec firewall/gateway products, default settings
on Windows NT4/2000,
spyware/adware, and a compromise of at least 5 UNIX
webservers.
received information the attack may have started
as early as Feb. 22, 2005 but probably only affected a small number of people.
On March 24, we received reports of a different DNS cache poisoning attack.
This attack did not appear to affect as many people.
This will be referred
to as the &second attack& in the remainder of this report.
After monitoring the situation for several weeks now, it has become apparent
that the attacker(s) are changing their methods and toolset to point at different
compromised servers in an effort to keep the attacks
This attack morphed into a similar attack with different IP addresses
that users were re-directed toward.
This will be referred to as the third
attack and is still ongoing as of April 1, 2005.
In the default configuration, Microsoft DNS server will accept bogus glue
records from non-delegated servers. These bogus records will be added to the
cache when a client attempts to resolve a particular hostname served by a malicious
or incorrectly configured DNS server. The client can be coerced to request such
a hostname as a result of an otherwise non-malicious piece of HTML email (such
as spam) or in banner advertisements on websites, to give some examples.
Based on information contained in reports of this activity, there are sites
actively engaged in this deceptive DNS resolution. These reports indicate that
malicious DNS servers are providing bogus glue records for the generic top-level
domain servers (gtld-servers.net) potentially resulting in erroneous results
(e.g., failed resolution or redirection) for any DNS request.
More information about the problem can be found at
VU#109475 - Microsoft Windows NT and 2000 Domain Name Servers allow non-authoritative
RRs to be cached by default
Secure server cache against names pollution
How to Prevent DNS Cache Pollution (Q241352)
[Jan 8, 2003]
The domain name system--the global directory that maps names to Internet
Protocol addresses--was designed to distribute authority, making organizations
literally &masters of their own domain.& But with this mastery comes the responsibility
of contributing to the defense of the DNS.
The distributed denial-of-service (DDoS) attacks against the DNS root servers
on Oct. 21, 2002, should serve as a wake-up call. The attack was surprisingly
successful--most of the root servers were disrupted by a well-known attack strategy
that should have been easily defeated. Future attacks against all levels of
the DNS-- top-level domains like .com, .org and the country
and individual high-profile domains--are inevitable.
The October attack was a DDoS &&
attack. The attackers broke into machines on the Internet (popularly called
&zombies&) and programmed them to send streams of forged packets at the 13 DNS
root servers via intermediary legitimate machines. The goal was to clog the
servers, and communication links on the way to the servers, so that useful traffic
was gridlocked. The assault is not DNS-specific--the same attack has been used
against several popular Web servers in the last few years.
The legitimate use of ping packets is to check whether a server is responding,
so a flood of ping packets is clearly either an error or an attack. The typical
defense is to program routers to throw away excessive ping packets, which is
called rate limiting. While this protects the server, the attack streams can
still create traffic jams up to the point where they are discarded.
Excess capacity in the network can help against such attacks, as long as
the additional bandwidth can't be used to carry additional attacks. By intent,
root servers are deployed at places in the network where multiple Internet service
providers intersect. In the October attacks, some networks filtered out the
attack traffic while others did not, so a particular root server would seem
to be &up& for a network that was filtering and &down& for one that was not.
Unlike most DDoS attacks, which fade away gradually, the October strike on
the root servers stopped abruptly after about an hour, probably to make it harder
for law enforcement to trace.
Future attacks against
all levels of the DNS are inevitable.
DNS caching kept most people from noticing
this assault. In very rough terms, if the root servers are disrupted, only about
1 percent of the Internet should notice for every two hours the attack continues--so
it would take about a week for an attack to have a full effect. In this cat-and-mouse
game between the attackers and network operators, defenders count on having
time to respond to an assault.
Defending the root
The root servers are critical Internet resources, but occupy the &high ground&
in terms of defensibility. The root server database is small and changes infrequently,
and entries have a lifetime of about a week. Any organization can download an
entire copy of the root database, check for updates once a day, and stay current
with occasional reloads. A few organizations do this already.
Root server operators are also starting to deploy root servers using &anycast&
addresses that allow multiple machines in different network locations to look
like a single server.
Unfortunately for
those of us that depend on the Internet, the attackers
seem likely to strengthen their tactics and distribute
new attackware.
In short, defending the DNS root is relatively easy since it is possible
to minimize the importance of any root server, by creating more copies of the
root database--some private, some public.
Top-level domains, or TLDs,