Sunday, 14 August 2011

Configuration auditing 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 following Linux posts next week I will 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. We will introduce a tool called DAD in coming weeks 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.

No comments: