Friday, May 29, 2009

Howto find DNS Server Version remotely using fpdns

A nameserver basically responds to a query. Interoperability is an obvious requirement here. The standard protocol behaviour of different DNS implementations is expected to be the same.

The reality is quite different though. fpdns uses a series of borderline DNS queries to determine the vendor, product and version of a nameserver.

A nameserver basically responds to a query. Interoperability is an obvious requirement here. The standard protocol behaviour of different DNS implementations is expected to be the same.

Requirements for protocol behaviour of DNS implementations is widely documented in the case of ‘common’ dns messages. The DNS protocol is over 20 years old and since its inception, there have been over 40 independent DNS implementations, while some implementations have over 20 versions.

The methodology used to identify individual nameserver implementations is based on “borderline” protocol behaviour. The DNS protocol offers a multitude of message bits, response types, opcodes, classes, query types and label types in a fashion that makes some mutually exclusive while some are not used in a query messages at all. Not every implementation offers the full set of features the DNS protocol set currently has. Some implementations offer features outside the protocol set, and there are implementations that do not conform to standards.

Also, new features added to - or bugs removed allow for differentiations between versions of an implementation.

Install fpdns in Ubuntu

sudo aptitude install fpdns

This will complete the installation

Using fpdns

fpdns [-c] [-d] [-f] [-p port] [-Q srcaddr] [-r retry] [-s] [-t timeout] [-v] server

Where: server is an ip address or a resolvable name
or ‘-’ to read list of servers from stdin
-c (where appropriate check CH TXT version) [off]
-d (debug) [off]
-f (force check CH TXT version) [off]
-F (maximum forked processes) [10]
-p port (nameserver is on this port) [53]
-Q srcaddr (source IP address) [0.0.0.0]
-r retry (set number of attempts) [1]
-s (short form) [off]
-t time (set query timeout) [5]
-v (show version)

fpdns Examples

BIND Version 8 Example

fpdns -D google.com

fingerprint (google.com, 216.239.34.10): ISC BIND 8.3.0-RC1 — 8.4.4
fingerprint (google.com, 216.239.36.10): ISC BIND 8.3.0-RC1 — 8.4.4
fingerprint (google.com, 216.239.38.10): ISC BIND 8.3.0-RC1 — 8.4.4
fingerprint (google.com, 216.239.32.10): ISC BIND 8.3.0-RC1 — 8.4.4

BIND Version 9 Example

fpdns -D debianhelp.co.uk

fingerprint (debianhelp.co.uk, 212.67.202.2): ISC BIND 9.2.3rc1 — 9.4.0a0 [recursion enabled]
fingerprint (debianhelp.co.uk, 212.67.203.246): ISC BIND 9.2.3rc1 — 9.4.0a0 [recursion enabled]

TinyDNS Example

fpdns ns1.eu.dedicatedserver.com.

fingerprint (ns1.eu.dedicatedserver.com., 213.198.65.226): DJ Bernstein TinyDNS 1.05

Microsoft windows 2003 Example
fpdns -D microsoft.com

Source: http://www.ubuntugeek.com/howto-find-dns-server-version-remotely-using-fpdns-fingerprinting-dns-servers.html

Monday, May 25, 2009

DNS Servers Are Under Fire

DNS server support, DNS server error, Domain name server
The number and severity of domain name service server attacks have risen sharply on networks around the globe, as phishers, pharmers and other malicious code writers embrace the latest way to circumvent traditional forms of mitigation.

Sandvine has observed an increase in server attacks, particularly DNS attacks on broadband networks. DNS server are suddenly overwhelmed by a glut of spoofed DNS requests and responses, causing the server to process requests slower and slower until it eventually fails entirely - impacting subscribers' ability to use the Internet for the duration of the attack.

Sandvine Security Operations Services team has identified increases where single attackers performed over 1000 times the normal amount of lookups on a DNS server in a 12-hour period. These attackers are engaging in a form of DNS attack called DNS poisoning - the act of tainting the server's cache with incorrect routing information so illegitimate sites appear in a browser despite a legitimate web address being requested.

One successful poisoning attempt could affect many thousands of users, and result in droves of subscribers being taken to exploitive sites that bilk them of their personal information, steal their identity, download malware (worms, spyware, adware, etc.) onto their computers, or bombard them with irrelevant advertisements - even though they typed in the correct URL into their browser or followed the right hyperlink. Poisoning can be accomplished by individual computers or by networks of 'zombie' computers directly on the ISP's network or spread around the world.

As threatening as DNS attacks and poisoning are to the personal- information integrity of subscribers, the damage is compounded for broadband service provider networks. DNS attacks are responsible for overwhelming DNS servers to the point of failure, causing massive, wide-scale service outages. This results in subscriber churn, destroys brand equity, and can cost millions in subscriber refunds, not to mention the substantial financial burden of trying to identify and alleviate the problem.

"Broadband service providers must protect their network and subscribers with multi-layered, network-based approaches," said Don Bowman, VP, Consulting Systems Engineering, Sandvine Incorporated. "Attacks and malicious code are becoming more and more evasive and targeted. Service providers need to proactively monitor their networks for threats and respond in real-time to shut down these attacks."


Source: http://news.softpedia.com/news/DNS-Servers-Are-Under-Fire-2226.shtml

Monday, May 18, 2009

Installation of DHCP Server in 2008

Installing DHCP server in Windows 2008 Infrastructure

DHCP plays a very important role in leasing out the IP addresses to clients, when you are running this service into your server. In Windows 2008 Server there have been some improvements over Windows 2003 Server, especially major improvements in backup and restore.

Understanding DHCP process

Workstation boots up and broadcast is sent to all nodes on a subnet. This broadcast works on UDP port 68 and server is listening to these broadcasts on UDP port 67.
Installing DHCP server in Windows 2008

1. Go to start, Programs, Administrative tools in that Server Manager
2. Select Roles node in Server Manager, then click Add roles and select DHCP Server
3. Verify the network Bindings option.
4. Then IP v4 Settings page will come, Provide domain name and DNS IP address.
5. IF wins is required in your environment provide those details also.
6. Then Enter Start IP and End IP address range along with SM and gateway
7. In DHCP v6 stateless mode select enable if it's required
8. After the above steps you will see your DHCP server has just been configured.

Improvements in Windows 2008 DHCP (Backup and Restore)

In Windows 2008 DHCP Server you no longer need to export those registry keys or manually move database to different server, because backup and restore can be performed from DHCP console.

To Backup DHCP database

1. Open DHCP manager
2. Right Click on server name and choose backup
3. Give the path where it has to be stored

To restore DHCP database

1. Go to the server where DHCP has to be restored
2. Right click on server name and restore, give the path from where it has to be restored
3. It will ask to stop and start the services. Select Yes.

Source:symantec.com

Thursday, May 14, 2009

iYogi Acquires Clean Machine Inc.

Larry Gordon, Founder of Clean Machine appointed as President Global Channel Sales at iYogi


New York, NY, May 11th, 2009 : iYogi, a global direct to consumer and small business technical support provider, today announced it’s acquisition of Clean Machine Inc, a provider of remotely administered PC security and performance management services. Clean Machine will operate as a separate brand under the iYogi services umbrella along with the recently lunched Support Dock (www.supportdock.com) and its comprehensive range of 24/7 technical support services for computers, printers, MP3 players, digital camera, routers, servers and more than 100 software applications. Larry Gordon, Founder of Clean Machine is appointed as the President of Global Channel Sales for iYogi.

computer repair,help and support

iYogi will integrate technology and innovation that Clean Machine Inc. has developed for delivering an enhanced service experience by proactively managing the health and security for PC's and Apple Computers. This acquisition also broadens iYogi's access to key markets through Clean Machine's existing partnerships. Larry Gordon's past experience and successful track record will accelerate iYogi's expansion through his focus on global alliances.
Commenting on the acquisition of Clean Machine Inc., Uday Challu, CEO & Co-founder of iYogi, said,

"This acquisition will help iYogi to enhance our customer experience and extend our market reach to the millions of consumers that are challenged by the increasingly complex technology environment. Clean Machine's proactive maintenance and management of PCs in home and small business environment will be our launch platform for building the next generation of managed services for consumers."

"We are delighted to have Larry spearheading partnerships and global alliances for iYogi. His incredible experience in marketing, sales and building global alliances will help forge partnerships with retailers, multiple service operators, software publishers, original equipment manufacturers (OEM) and other such companies that are at the frontlines for managing tech support issues for consumers and small businesses",
added Challu.


With more than 20 years of experience, Larry Gordon has played a variety of strategic roles in marketing, sales and building alliances. Larry was the Executive Vice President at Capgemini and Kanbay. He was also VP of Global Marketing for Cognizant (Nasdaq: CTSH), a leader in global IT services and Director of Marketing for New York based Information Builders.

"I am excited to join a company that shares a common mission to Clean Machine in creating a global brand for delivering the best technical support to consumers and small businesses. We also share a common approach of utilizing highly skilled talent with leading edge tools, thereby delivering services at incredible price-points, with high margins for our partners",
said Larry Gordon, the newly appointed President of Global Channel Sales at iYogi.

ABOUT IYOGI


Headquartered in Gurgaon, India with offices in New York, USA, iYogi provides personalized computer support for consumers and small businesses in United States, United Kingdom, Canada and Australia. IYogi's 24/7 phone and remote technical assistance, spans across a comprehensive range of technologies we use every day from a wide range of vendors. Utilizing its proprietary technology iMantra , and highly qualified technicians, iYogi delivers amongst the highest benchmarks for resolution and customer satisfaction. iYogi is privately held and funded by SAP Ventures, Canaan Partners, and SVB India Capital Partners. iYogi was recently awarded the Red Herring Global 100 Award, recognizing it as one of the 100 most innovative private companies driving the future of technology. For more information on iYogi and a detailed list of technologies supported, visit: www.iyogi.net.

ABOUT CLEAN MACHINE


Clean Machine Inc. is a NJ-based and incorporated company that helps consumers and small business owners easily manage and protect their computing environments safely and cost effectively. The company is has a unique, powerful and inexpensive PC concierge service. Specifically, each customer is assigned a highly-trained tech concierge who remotely examines their computer system on a scheduled and very secure basis. The PC concierge will immediately fix software-based problems and prevent new threats to the customer's computing environment including offensive pop-ups, browser redirects and slow performance, and then provides a detailed report. Clean Machine's proprietary Radar(TM) technology (Remote Access Detection Audit and Repair) allows its expert technicians to remotely resolve any problems, eliminating the need for customers to go through the frustrating process of speaking with a tech support expert, and still having to do the work themselves. In other words, the Clean Machine PC concierges do it all. For more information on Clean Machine please visit www.pccleanmachine.com.

Tuesday, May 12, 2009

How the DHCP Server Callout API Operates?

A internal table is maintain by Microsoft DHCP Server on the occurence of dhcp protocol, trigger third-party DLL function calls. Developers register to have occurrence of these events call their functions by creating a specified registry entry that Microsoft DHCP Server reads upon startup.

The location of the registry entry is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCPServer\Parameters

The following registry key values must be specified for this entry in order to enable the callout server:

Key NameKey DatatypeValue
CalloutDllsREG_MULTI_SZString that contains the local path to the DHCP callout DLL. For example: "C:\Program Files\MyCalloutServer\my_dhcp.dll"
CalloutEnabledDWORD32-bit unsigned integer value that specifies 0 if the DHCP callout server is not enabled, and 1 if it is.

How Microsoft DHCP Server loads and handles third-party DLLs impacts third-party DLL developers. Microsoft DHCP Server takes the following steps in loading third-party DLLs:

  1. Microsoft DHCP Server checks the previously defined registry location for the presence of third-party DLLs.
  2. If no registry entries are found, the DHCP Server internal hook table remains empty, and no DHCP Server event notifications are sent.
  3. If one or more registry entries is found, Microsoft DHCP Server reads the first registry entry, in alphabetical order, and attempts to load the corresponding third-party DLL. If the DLL loads successfully, Microsoft DHCP Server ceases checking for additional third-party DLLs.
  4. Microsoft DHCP Server calls the DhcpServerCalloutEntry function in the loaded third-party DLL, retrieving the associated DHCP_CALLOUT_TABLE function and thereby determining which events initiate notification to the third-party DLL. Notification comes in the form of corresponding third-party functions: one or more of which can be included in the third-party DLL, and each of which are defined in the following DHCP Server API reference pages.
Because the DHCP Server API enables developers to hook into the core functionality of Microsoft DHCP Server, use care when writing the third-party DLL functions. Several events that result in third-party DLL function calls occur when locks are held by the DHCP Server, and therefore, poorly written hooks can destroy DHCP Server heaps and critical information in Microsoft DHCP Server structures.

Source: msdn.microsoft.com

Wednesday, May 6, 2009

Importance of Public DNS Servers

The purpose of a DNS server is to enable people and applications to lookup records in DNS tables. Most DNS servers are now private, meaning that they are configured to only provide service to the people and organizations who own and maintain them.

A few domain name servers on the Internet provide DNS resolutions for anyone who requests it of them. These are known as "Public DNS Servers."

Most public DNS servers are public on purpose. A few public DNS servers are public only because they have been misconfigured by their system administrators. Those DNS servers tend to eventually be fixed.

Public DNS Servers

Level 3 Communications (Broomfield, CO, US)
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
Verizon (Reston, VA, US)
151.197.0.38
151.197.0.39
151.202.0.84
151.202.0.85
151.202.0.85
151.203.0.84
151.203.0.85
199.45.32.37
199.45.32.38
199.45.32.40
199.45.32.43
GTE (Irving, TX, US)
192.76.85.133
206.124.64.1
One Connect IP (Albuquerque, NM, US)
67.138.54.100
OpenDNS (San Francisco, CA, US)
208.67.222.222
208.67.220.220
Exetel (Sydney, AU)
220.233.167.31
VRx Network Services (New York, NY, US)
199.166.31.3
SpeakEasy (Seattle, WA, US)
66.93.87.2
216.231.41.2
216.254.95.2
64.81.45.2
64.81.111.2
64.81.127.2
64.81.79.2
64.81.159.2
66.92.64.2
66.92.224.2
66.92.159.2
64.81.79.2
64.81.159.2
64.81.127.2
64.81.45.2
216.27.175.2
66.92.159.2
66.93.87.2
Sprintlink (Overland Park, KS, US)
199.2.252.10
204.97.212.10
204.117.214.10
Cisco (San Jose, CA, US)
64.102.255.44
128.107.241.185



Source: tech-faq.com

Friday, May 1, 2009

How to Secure Network from Kaminsky's DNS Cache Poisoning Flaw

The seriousness of the recent DNS cache poisoning vulnerability, discovered by security researcher Dan Kaminsky, raises the bar for network security administrators and should provoke development of a comprehensive plan to address this insidious threat. Every enterprise has a caching DNS server and is thus a target of the Kaminsky DNS cache poisoning flaw.

A Kaminsky DNS cache poisoning attack consists of two steps:

Step No. 1: The attacker sends fake DNS queries, or questions, to internal caching DNS servers. These queries are for domains that the caching server will not have cached, so it will have to generate subsequent queries to authoritative servers on the Internet.

Step No. 2: The attacker then sends a barrage of fake answers to each fake question, attempting to spoof the answer from the authoritative server. To succeed, the attacker has to correctly guess various query parameters—such as Transaction ID and User Datagram Protocol (UDP) source port—before a valid response from the legitimate authoritative server reaches the caching DNS server. There are some additional technical details about the fake answer that will be discussed later in this article.

If the attacker succeeds in getting his or her fake answer accepted by the caching DNS server, the consequences are quite serious. The poisoned DNS entry can be used to redirect Web traffic, e-mail or any other IP application to a malicious server controlled by an attacker. Since the DNS points users to their destinations, it is completely unaware that the traffic is being diverted.

Protecting against the Kaminsky attack

As with any security vulnerability, the best approach for protecting against the Kaminsky attack is to employ multiple defenses. In this case, traditional firewalls and intrusion prevention systems (IPS) can be part of the solution, providing an initial defensive shield that will reduce the number of fake DNS query requests and responses.

But most firewalls and IPS will not stop a fake DNS response from poisoning the DNS cache if the DNS query parameters match. This means it is a primary consideration to ensure that the DNS server itself employs the best possible defenses. Put another way, DNS security starts with the DNS server.


Source: eweek.com