- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Bugger Off: Keeping Hackers Off Your Servers
The servers you're running if not configured carefully can leak out buckets of useful information that hackers can use against you to compromise your network. So do yourself a favor: Make sure you're not handing hackers the information they need on a silver platter.There's no foolproof method for keeping hackers at bay, but steps can be taken to prevent servers from leaking information that can be used against you.
Nearly every organization is running servers for DNS and SMTP. Any hacker who knows his onions will almost certainly attempt to penetrate them, if he can, to see what information he can glean from them.
One thing a hacker will probably try and do is perform a zone transfer from the master DNS server. Think about this for a moment.
A zone's secondary DNS server is meant to be able to perform a zone transfer to obtain and replicate a full copy of resource records for the zone from the primary DNS server. It may do this for a number of reasons: when it has been notified of zone changes by the master server, when it is started up for the first time, or simply when it's time for a scheduled refresh. A hacker, on the other hand, is not meant to be able to perform a zone transfer.
There's a good reason why not. A zone transfer contains a significant amount of information about computers in a given domain, including IP addresses, server names, and by implication and sever functions. It's valuable stuff and very useful for hackers if they can get their hands on it.
See all articles in our Series Bugger Off: The Importance of Securing Your Servers
If your DNS servers are set up correctly, you shouldn't have a problem. The secondary DNS servers will be able to perform zone transfers, but hackers will not. On the other hand, if you've set up your primary DNS server carelessly, anyone will be able to perform a zone transfer and get their mitts on the information.
To find out if your DNS server is leaking information needlessly, try this. In Linux, type:
# host -t ns yourcompanydomainname.com
to get a list of your corporate DNS server names:
yourcorporatedomainname.com name server ns1.yourcorporatedomainname.com
To try and perform a zone transfer, type:
# host -l yourcompanydomainname.com ns1.yourcorporatedomainname.com
With any luck you'll see:
Host yourcorporatedomainname.com not found: 5(REFUSED) ; Transfer failed
If you get that, congratulations. Your DNS server is set up correctly, in this respect at least.
If you're not lucky, expect to see a complete list of the names and IP addresses of all the machines in the domain. Any hacker who gets this will have just received a blueprint of the corporate network layout, and no doubt will be most grateful.
"I have seen several situations where an organization misconfigured its DNS server so badly, whereby it did not separate its internal DNS namespace and external DNS namespace into different unrelated zones," says Mati Aharoni, a network security expert and trainer at offensive-security.com. "This resulted in a complete map of the external network structure, as well as an internal map."
So it's pretty clear that if your DNS server allows anyone to carry out zone transfers, it needs fixing. Sort it out, and fast.
While the SMTP server is unlikely to be handing out network maps to hackers, it may be revealing valid mail usernames. These are particularly valuable, as it's likely some usernames will be reused as login credentials for other systems. If these can later be matched with valid passwords using an online password tool, such as Hydra, the hacker will have more valuable tools to compromise your system.
The SMTP Command
The two SMTP commands we're going to look at are VRFY and EXPN. These can be used to verify (VRFY) that a particular user name is in use on the server and to expand (EXPN) a mailing list name to reveal the user names on that list.
The VRFY command can be useful when troubleshooting e-mail problems internally to check that a particular username is correct and recognized by the server. If you have a user (referred to here as "validuser") having trouble with his or her e-mail, a tool like Netcat can connect to your SMTP server IP address and port:
|# nc -v xxx.xxx.xxx.xxx 25|
and once you receive the SMTP server banner confirming you are connected, send:
If the name is indeed valid, you'll receive back something, like:
|250 2.1.5 validuser email@example.com|
If not, you'll see:
|550 5.1.1 validuser User unknown|
Useful for troubleshooting, but even more useful for Johnny hacker. That's because with the help of a simple Python script and a text file containing a list of possible usernames, he can very quickly go through his list of usernames verifying which ones are valid on the SMTP server and which ones are not. Equally, the hacker can use the EXPN command to check likely list names to find out who the underlying users are. EXPNing "postmaster" would reveal to whom mail for postmaster is actually sent, for example. Once armed with a list of valid user names, he can attempt to match them to a range of common passwords from any easily obtainable list.
It's usually a fairly simple configuration issue to disable VRFY and EXPN, and it's unlikely to have much impact on day to day administration.
There's no foolproof method of keeping hackers at bay, but taking these steps to stop your servers divulging information that can be used against you is certainly a worthwhile step in the right direction. After all, why make it easy for them?