Monday, 15 March 2010

Configuration of key network services (DNS, SMTP, etc.)

There are many key services on any network that people do not commonly think about until there is a problem. These services go for the most part unknown by many, but if they were to break or be compromised could have dire consequences for the organization. Simple services such as DNS provide the backbone to any network infrastructure. For the most part, the security of the Internet is tied to the security of services such as DNS. For instance, if an attacker can take over an e-commerce sites DNS it can install a man in the middle system to capture user names and passwords associated with a site as the clients use it.

For this reason, these services need to be treated with special care.

There are a number of simple rules that apply to configuring any key network system. These are:

1. Install the service on a dedicated host. This means running the service on a system that is built solely for this purpose. The only other applications on a host should be there to support the functioning and security of the system. Where possible, even remove windowing systems if they are not needed. BIND DNS software will run happily on Linux with nothing but itself and maybe an SSH service that is configured to be accessible from a secure administration host.

2. Run only those services that are absolutely needed. Rule number one leads to only installing those services that are absolutely needed. This is only those services necessary for the functioning of the key service. The host should be a bastion. It should be configured to be fit for purpose and nothing else (this does not mean turning off logs).

3. Ensure that the system is patched and up-to-date. Rule one makes this much simpler. The less services that are running on a host, the less that need to be patched and the less down time and cost that are associated with it. This means operating system patches, application patches and any other updates that could affect the security of the system.

4. Chroot where possible. In the UNIX chapter we introduce chroot (change root). This utility creates a virtual system root and adds an extra layer of defense to the system.

5. Removable vendor documentation and sample code. Many instances of IIS and Php-Apache web servers have been compromised because of vendor sample code. In this case, the application and the website could be secure, but with a backdoor built in. If you don’t use it remove it.

6. Run all services and applications using least privilege. Running a service as administrator or root is asking for trouble. Running a service with a guest level account will not stop it being compromised due to vulnerability, but will slow down the attacker. Slowing down the attacker gives the security administrator a chance to minimize the damage.

7. Modify service banners. Security by obscurity is not a good thing, but neither is making it easy for the attacker. Many automated systems and Internet worms based their attacks on an information and versioning. Many automated attack tools also function this way. This may not stop a determined attacker, but it will stop casual attacks.

8. Ensure logging and monitoring. Logging is critical. There is no compliance regime that allows logs to be disabled. Logging alone is better than nothing but without monitoring it becomes little more than forensic evidence after the event. Logs are affected when they are checked. In the Windows chapter we introduce a tool called DAD that can be used to correlate logs between multiple hosts.

9. Control remote administration. Control how the system is administered. Consider implementing a centralized system that administrators are required to look into first before connecting to the key systems and do not allow remote administration directly from the Internet. Use local firewalls and host-based IDS to control access. Always encrypted any administrative access and strongly consider alternate access control methods such as tokens or smartcards for authenticating users.

10. NEVER allow root or administrator access directly to the host other than from the console. On top of that restrict most console access. Whenever a user needs to access a key system with a valid reason they should do so under their own account. If they need to run something with administrator privileges they should run a utility such as SUDO (UNIX) or Run-as (Windows) to escalate their privileges.

11. Implement and monitor file integrity tools. Eventually something will go wrong. If an attacker does compromise a host that is running a correctly configured file integrity tool (such as AIDES or Tripwire) will firstly let you know what has changed and next allow the determination as to whether the box can be salvaged. Any host without an integrity tool that has any signs of compromise must be built from scratch. There are no exceptions to this rule. The call to rebuild or not rebuild a compromise host with file integrity tools should only be made by a suitably qualified individual.

12. Architect the system correctly. Look at where the system is placed in what controls help protect it. Consider network intrusion detection systems (NIDS) and network monitoring devices as well as firewalls. Look at how logging is protected. Syslog on UNIX for instance uses no authentication and is sent over clear text. An attacker could compromise logs without compromising a host unless these are protected somehow (e.g. IPSec VPN).

There are many key systems that will be available on any network. DNS, SMTP relays, log servers, NTP (Network Time Protocol) servers and authentication servers are just some of the many systems that need special levels of protection. These systems get compromised; the attacker can generally use them to expand their attack across the rest of the network.

Systems such as DNS cannot be excluded from any compliance exercise. For instance, Sarbanes Oxley (SEC financial system requirements in the US for listed and otherwise controlled entities) requirements cover the protection of systems involved in the reporting of financial statements. For this reason many individuals exclude DNS. The question to ask is how many users connect to a system using the host IP address? In particular, how many of the accounting and finance staff would even know the IP address of the server?

In this instance DNS is critical. If an eternal attacker could subvert DNS is likely that they could also take over any financial system in the organization. If DNS is compromised no reliance may be placed on the financial statements.

Know your key systems and protect them well. These are the organizations crown jewels.

Mail Relays

Open mail relays (SMTP gateways) with direct connections to the Internet are particularly vulnerable to attack. These systems are goldmines for Spammers and organized crime. What most organizations do not realize is that they are liable for spam and fraudulent statements that are forwarded using an insecure system for. Not only this, but many attackers use such systems to hide defamatory e-mails and to send abusive messages.

When configuring eight SMTP mail gateway consider the following:

1. Disable open relaying. Do not allow any domain and any address to send e-mail to from any location. This is not a difficult concept. The purpose of an organization’s e-mail server is not to provide free access to e-mail for the entire world. It is designed such that it can send and receive its own e-mail and it should be restricted for this purpose. Even free e-mail services such as Hotmail do not allow people to send and receive non-Hotmail related e-mails.

2. Disable commands such as VRFY and EXPN. VRFY (Verify) is designed to test the existence of an account. EXPN (expand) is used to expand e-mail groups to see who was a member of the group. For example, could have the entire sales department as a member. There is no need to allow spammers to test whether users exist or not. Allowing these commands on the mail gateway is asking for spam. There are worse problem is that could also occur.

3. Limit file transfer size. No matter what size files your users think they should be able to send there is always a limit. Apart from loss of information and critical information that can be sent via e-mail there are simple issues such as denial of service. If your e-mail server is running on a server with a 10 Gb disk it is unlikely that you would like to accept an 11Gb attachment. always place a limit on the maximum size of an e-mail.

4. Limit system access. Limit (by IP address) those addresses that can send mail to different addresses. If you only allow internal e-mail from inside your organization and do not allow Internet addresses to use your internal domain.

5. Scan for malware. Always check both incoming and outgoing content for malware. Most people understand the need to scan incoming e-mails. The issue is with e-mail that is going to other places. Just because an e-mail is leaving your organization does not mean you do not need to scan it. If a virus leaves your organization and infects another and you have not taken precautions, your organization will be liable for damages you have caused. It can be argued that they should have had their own antivirus solution, but the fact of the matter is that your organization is the root cause and you liable for the damages. Remember how damage much the “I love you” virus was estimated to have caused in 2000[1].

6. Implement content filtering. First there is the issue of what is both coming into and leaving your organization. E-mail is a common way for both staff and attackers to remove protected information. Worse, abusive or defamatory e-mails leave the organization liable to damages. The range of issues that can impact an organization through e-mail covered in the Legal Issues chapter.

7. Add a legal disclaimer to all e-mails. All e-mails, both incoming and outgoing should have a disclaimer. This is a simple thing to add to an e-mail that will save a lot of grief down the track. It may not stop something bad from happening but least it limits the liability of the organization to an extent.

8. Block mail from open relay blacklists and specific domains. There are blacklists containing the addresses of known spammers. In addition, if your system is constantly being attacked, block it. There is no necessity to accept e-mail from anywhere in the world. Look at where you expect to get e-mail from and what you need.

9. Use encryption where possible. Where possible encrypt the transmission of e-mail and the access to it. In particular, it is possible to use encrypted communications between internal divisions (such as Interstate or international e-mail servers) and it is potentially possible to encrypt e-mail between business partners.

10. Test the system regularly. Eicar files can be used to test that the virus signature is working. On top of this vulnerability testing tools such as Nessus can be used to ensure that no new vulnerabilities have appeared. These can also be automated so that they can report on new vulnerabilities as well. In some cases, sending an actual virus can be more effective than an Eicar file - But it can also be far far more dangerous.

Eicar files. An Eicar file is a test file that is designed to validate the functioning of an antivirus server. Of course, all antivirus engines put a lot of effort into testing Eicar files.


DNS is that unknown worker which goes considered until there is a problem. DNS resolves host names to IP addresses (and also conversely IP addresses to host names). Without DNS the Internet would stop. This is a big claim until you realize that people do not remember numbers. We can remember several thousand names but we cannot remember even 50 IP addresses easily.

Even within organizations DNS is key to the security of access as individuals connect to named servers and (usually) not to IP addresses. To secure a DNS server is essential to consider the following points:

1. Restrict zone transfers. DNS zone transfers are needed from the primary DNS to the secondary. Never allow anything else, not even secondary to secondary transfers.

2. Disable recursive checks and retrievals. There is no reason to allow recursive queries from ever host on the Internet. At best it is a waste of resources, at worst an attack path.

3. Log ALL zone transfer attempts. Any attempt to do a zone transfer should be treated as an incident. This is always going to be someone or some program looking for information about the configurations of systems. This should never be permitted.

4. Restrict queries. Not all queries are necessary. Information that is not necessary should be restricted on a need to know basis.

5. Restrict dynamic updates. Only authorized hosts should be allowed to change DNS entries.

6. Deploy split DNS. Split DNS involves logically and physically separating the external and internal address spaces.

o External IP addressing should include that information that is necessary for services on the Internet to function correctly.

o Internal IP addressing should be restricted to your organizations own systems.


A DNS Server is recursive when it assumes the duty of resolving the answer to a DNS query. DNS servers are generally recursive by default. Exposed recursive servers can be used by attackers (e.g. Cache poisoning attacks). At best they are lost system resources doing lookups for unrelated entities.

Bind version 8.x and above provide the capability to configure the server to be non-recursive with selected exceptions for explicit IP addresses. This allows the servers to answer recursive queries for the organizations own hosts while blocking recursive queries from unauthorized hosts on the Internet.

To configure DNS correctly:

· Recursive queries can be allowed for internal DNS

· Recursive queries should be blocked for external hosts

Where there are exceptions (for roaming hosts for instance) these can be configured separately.

Zone Transfers

Secondary DNS servers use the zone transfer function to update changes to the DNS zone databases. These changes are received from the primary (or SOA, Start of Authority) DNS servers.

Only allow zone transfers between the primary and secondary DNS servers. Secondary DNS severs should never be allowed to respond to a zone transfer request.

Do not block TCP 53 and think that you are ok. TCP is used for valid DNS queries. The blocking of TCP port 53 is breaking DNS and not fixing zone transfers.

Split DNS

Split DNS involves the logical separation of the external and internal name resolution functions.

· Information that is necessary for hosts on the Internet is maintained on the external DNS servers.

· Information about the internal hosts and IP space is maintained and resolved using the internal DNS servers.

· When a system is required to support reverse PTR lookups, generic information should be provided. PTR records do not matter they are just required to resolve to something. To have reverse PTRs work requires a name… ANY name. This is NOT the real internal name.

Split-Split DNS

A split-split DNS is the idea DNS architecture. In figure 19.4, the split-split DNS architecture is displayed. This involves a back to back private address DMZ segment with two firewalls (it is possible to do this with a single firewall and 3 interfaces as well). The DMZ network and internal private network each have:

• Two DNS Advertiser hosts on the DMZ

• Two DNS Resolver hosts on the DMZ

• Two internal DNS servers on the internal network


Figure 1 Split-Split DNS

There are at least two of each kind of server to provide for fault tolerance and load balancing. At least one of each type will be primary and the other a secondary DNS server (Windows Active Directory DNS servers do not use this system). Zone transfers are allowed only to occur between the primary and secondary servers. This is:

o External DNS. Acts as an advertiser and resolver system

o Internal DNS. Acts as to resolve queries for internal client hosts

o Each zone needs its own Primary and Secondary DNS. Zone transfers should only be allowed from primary servers to secondary servers (and not the other way)

Split-split DNS has multiple DNS servers located in the DMZ. Separate DNS servers provide name and domain advertising and resolution. A pair of DNS servers are positioned within the internal network as well. These are all run as duplicates to provide fault tolerance and load balancing.

A total of at least six DNS servers (three primary and three secondary servers) are required for a split-split DNS configuration. The three classes of DNS servers are:

· DNS Resolvers. DNS resolvers provide only DNS caching. These systems are configured to be DNS forwarders and allow access only from the internal network hosts.DNS resolvers do not maintain a DNS zone database and are not authoritative for any domains. This setup allows split-split DNS to aid in stopping DNS hijacking attacks.

· DNS Advertisers. DNS advertisers maintain the organizations domains that are “advertised” over the Internet (the organizations authoritative zones). DNS advertisers don’t allow recursive queries to be preformed.

· Internal DNS Servers. Internal DNS servers resolve queries that originate from the internal network hosts. Internal DNS servers function identically to internal DNS servers in a “split DNS” setup.

[1] The “I love You” virus (actually a worm) was estimated to have caused around US$ 10 billion worth of damages. See and for more information.

No comments: