Monday, 10 March 2008

Unnecessary Services

It is essential to always ensure that servers are hardened (i.e. patched and unused services removed) prior to having a system “go live”. The auditor’s role is to verify that any new system is configured against the baseline standard. A default install of nearly any Operating Systems leaves a vast number of services running which, at best, are feasible to never be used, or at worst, leave ports open to external break-ins. The first stage in removing unneeded services is to work out which services are running on a host and to decide which are essential services needed for the operation of the system. UNIX is no different. In fact, the primary difference with UNIX is that although it starts with many enabled services, it can be quite simple to turn these off and configure the host as a bastion running only a single service.

In many cases it is also possible to further restrict the individual services on the host. Many services are configurable with access control conditions or lists to further restrict the services needed on a host. A good example of this would be restricting access via SSH to an administrative LAN using the SSH server configuration directives. Client systems and desktops as well as Servers and network devices come installed with excessive services enabled by default. It is important to remember that this not only makes the system more secure but increases a systems efficiency and thus;

  1. Makes the systems better value for money (increases ROI),
  2. Makes administration and diagnostics on the host easier.
In this pursuit, netstat is one of the most effective tools available to the auditor. This tool lists all active connections in addition to the ports where programs are listening for connections. Simply use the command “netstat -p -a –inet” for a listing of this information. Note however that many versions of UNIX did not support the “netstat –p” option. Consequently on the systems it may be necessary to use other tools in order to find process information.

Turning Off Services in UNIX
This process will vary dependant on the version of UNIX or Linux being run. Most settings are contained within configuration files though some UNIX’s (such as HP-UX) have a registry system. Always ensure that you have thoroughly investigated the system that you are going to audit before you start the audit.

Controlling Services at Boot Time
Before we get into how services are started, will brief look at how their underlying stack may be configured. The reason for this is that individual services will be impacted through the underlying configurations. The file, “/etc/sysctl.conf” is common to the majority of UNIX systems. The contents, configurations and men are processing will vary across systems. The sysctl (System Control) configuration will in the majority of cases control the system configurations that of prime importance to the auditor. All of the options listed below may not be found in this file, but they may be included in one format or another.
  • ip_forward: This option lets the IP stack act as a router and forward packets. Multiple interfaces are not required for this functionality.
  • accept_source_route: This setting configures the operating system to accept source routed packets.
  • tcp_max_syn_backlog: This setting allows the configurations of the maximum number of SYNs in the wait state.
  • rp_filter: This setting provides basic IP spoofing protection for incoming packets.
  • accept_redirects: This setting configures the network stack to accept redirect messages and allow them to alter routing tables.
  • tcp_syncookies: This setting provides syn-cookie based protection against syn flood DOS attacks.
  • send_redirects: This setting controls whether or not the system can generate redirect messages.
  • accept_redirects: This setting is a secondary control used to configure redirect acceptance behavior.
The auditor should create a script to test these settings. The benefits are twofold:
  1. The settings may be initially tested against an agreed baseline standard, and
  2. The settings may be tested over time such that a system may be compared to its baseline standard and also a change log.

No comments: