Attacks/Breaches
8/30/2013
06:52 PM
Ehsan Foroughi
Ehsan Foroughi
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Thwart DNS Hijackers: 5 Tips

Domain name system attacks hit The New York Times and Twitter hard last month. Here are five ways to make your DNS records harder to hack and easier to recover if they're compromised.

4. Avoid having low TTL where possible, specifically on master records.

DNS caching can delay a DNS hijacking. The higher the TTL (time to live), the longer a hijacked domain needs to stay hijacked before it can reach the masses. However, many services use low TTL; for instance, only one minute, for load-balancing purposes.

One way of avoiding low TTL on the master record in high-traffic services is to have the master record point to a number of static servers that serve a lean landing page and have all other services use a sub-domain with low TTL.

For example, you can have "your-service.com" with high TTL to serve a small landing/login page, and use "www.your-service.com" and "api.your-service.com" with low TTL service for the rest of the application. As long as the DNS records for "your-service.com" are set up with high TTL and point to your secure DNS servers, hijacking the registrar will take a fairly long time to hit the majority of users due to the caching nature of the DNS.

5. Use high TTL for MX records to delay the hijackers' ability to reroute your emails.

Despite the fact email is known to be inherently insecure, a large amount of confidential information gets passed around in email inside companies. DNS hijackers can essentially steal these emails and cause considerable damage to an organization. Using high TTL for mail exchanger (MX) records in a DNS adds a delay for hijacking emails. Using email encryption such as PGP (pretty good privacy) will also ensure that attackers can't steal the information in the emails.

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.