Prevent Server Cache Poisoning And Domain Name Hijacking

When it comes to network security, you may be familiar with the risk of Web fraud, but do you know the threat of pharming?

For a On-Line Company, this risk is fatal.

In a nutshell, domain deception is the use of original access to a website.

Households, unwittingly, hijacked to counterfeit websites, such as users ready to visit a well-known brand online store, hackers can take them to fake online stores by means of domain deception, while collecting user ID information and passwords.

This kind of crime is usually achieved through DNS server's cache poisoning or domain name hijacking.

In recent months, hackers have shown the harm of this attack.

In March of this year, SANS Institute discovered a cache poisoning attack that changed the direction of 1300 famous brand names. These brands included ABC, American Express, Citi and Verizon Wireless. In January, the domain name of Panix was hijacked by an Australian hacker; in April, the IP address of Hushmail's main domain name server was modified to connect to a website made by hackers.

Statistics for tracking domain spoofing events are not yet available.

However, the anti web fraud task force (APWG) has classified domain deception into the key tasks of the recent work.

Experts say that the problem of cache poisoning and domain name hijacking has already attracted the attention of relevant organizations. Moreover, with the increasing number of online brands and increasing turnover, this problem is becoming more prominent. People have reason to worry that fraudsters will soon use this hacking technology to deceive large numbers of users, thus obtaining valuable personal information and causing confusion in the online market.

Although domain deception is technically and organized, it is very complicated.

But under the current circumstances, we can still take some measures to protect the DNS servers and domain names of enterprises without being manipulated by domain name swindlers.

Crack dilemma

The root of the DNS security problem lies in the Berkeley Internet Domain (BIND).

BIND is full of security issues that have been widely reported over the past 5 years.

Ken Silva, chief security officer of VeriSign, said that if you use BIND based DNS servers, follow the best practices of DNS management.

Johannes, chief research officer at SANS, said: "there are some fundamental problems in the current DNS. The most important thing is to unremittingly repair the DNS server to keep it up to date."

Paul Mockapetris, chief scientist of Nominum company and DNS protocol author, said that upgrading to BIND 9.2.5 or implementing DNSSec would eliminate the risk of caching.

However, if there is no interface provided by DNS management devices from Cisco, F5 Networks, Lucent and Nortel, it is very difficult and time-consuming to complete such migration.

Some companies, such as Hushmail, chose to use open source code TinyDNS instead of BIND.

Software alternatives to DNS include products from Microsoft, PowerDNS, JH Software, and other manufacturers.

No matter what kind of DNS you use, please follow the following best practices provided by Michael Networks, President of BlueCat Networks:

1, running separate domain name servers on different networks to achieve redundancy.

2, separate the external and internal domain servers (physically separate or run BIND Views) and use the pponder (Forwarders).

The external domain name server should accept queries from almost any address, but the pponder will not accept it.

They should be configured to accept queries from internal addresses only.

Close the recursive function on the external domain name server (starting from the root server to locate the DNS record down).

This can restrict which DNS servers are contacted with Internet.

3, when possible, restrict dynamic DNS updates.

4, restrict regional pmission to authorized devices.

5, using paction signature to digitally sign the region pfer and region update.

6, hide the BIND version on the server.

7, delete unnecessary services running on the DNS server, such as FTP, telnet and HTTP.

8, use firewall services on network peripherals and DNS servers.

Restrict access to those ports / services required by DNS functions.

Let the Registrar take the responsibility.

The problem of domain deception is also an important part of organization.

Not long ago, a hacker defrauded the customer service representative to modify the IP address of the Hushmail's main domain name server.

At this point, Hushmail's CTO Brian Smith has been very angry. It's really annoying that hackers have easily deceived the customer service representatives of their domain name registrars.

"This is really bad for us," Smith said.

I would like to see the Registrar formulate and publish better safety policies.

However, I can not find a registrar to do so. Since this happened, I have been looking for such a registrar. "

Alex Resin, President of Panix.com, also felt the same strong dissatisfaction when the Panix domain name was hijacked in January this year.

First, his registrar sold his domain name to a reseller without prior notice.

The reseller then pferred the domain name to a social engineer who did not inform Resin.

Resin said: "domain name system needs systematic and fundamental reform.

There are many suggestions, but things are not moving fast enough. "

It will take a long time to wait for market demand and the ICANN leadership to force the Registrar to adopt a safe pfer policy.

Therefore, Resin, Smith and ICANN chief registrar liaison officer Tim Cole have proposed the following risk reduction recommendations:

1, ask your registrar to produce written and executable policy statements.

If you need to pfer the domain name, ask them to contact you in time in the written document.

2, locking the domain name, asking the Registrar to get the unlocked password or other identity letters? Script src=>