The amount of security information -- combined with news groups, mailing lists, commercial vendor advisories, open source advisories and internal risk management initiatives -- make it difficult to keep track of security overall. Added difficulty comes from continually having to test and deploy security patches, and then address any issues patching causes.
This vicious cycle is seldom managed well due to the compounding effect of not hardening systems. In fact, very few organizations outside those directly exposed to Internet or Extranet users harden systems. Without hardening the system, an exact baseline is never created for the system. Rather an install-all approach is used, whereby only the vendor's updates may be applied. This prevents any mitigation at all by the administrator.
The problem then arises as this install-all creates much more risk. Even with security updates, the question becomes "are we using the services" versus "are the services running."
On the other extreme, very specific builds selecting exact packages can be made; however, this is unrealistic. A base platform that can be supported by peers (not just the person building the system) and vendors, both
Therefore, one needs to find a practice that lies somewhere in between these two extremes. This will be most effective in mitigating the security risk with an "install all" versus a very granular approach of picking each package individually.The process
The process of constructing a secure build should take a three-pronged approach: mitigate risks during the system install, investigate and minimize risk based upon an internal view, and investigate and minimize risk based upon an external view. System install
There are some key install decisions that can decrease the number of security risks the system is exposed to during installation.
When asked for the type of system, the "install all" approach should be avoided. For example, if the system is not going to host virtual machines, then the option to install Virtualization should not be activated. RedHat supports 3 base configurations on Version 5.1: Software Development, Web Server, and Virtualization. The particular use (or none) should be selected accordingly. This avoids any extras being installed.
Installation can further be honed by selecting the Customize Now option during install.
The Customize Now option will reflect applications selected automatically as part of all system installs or particular packages defined for Software, Development, Web Server and Virtualization. The Applications area of customization is a good candidate for unnecessary applications and services being installed, and should be reviewed thoroughly.Internal view
Despite the selection made during installation, Red Hat 5.1 still installs services that are not needed and are subject to unnecessary risk, as well as using processor and RAM resources.
When inheriting a system, administrators are stuck with investigating processes with PS and looking at startup scripts to identify running unneeded process. However, when deploying a new system, the startup scripts can be initially investigated and unneeded startup scripts turned off during boot up.
The chckconfig command can be used to identify the System V startup scripts configured and updated. For example the following abridged output shows all the startup scripts that exist and at what level they run:Click here to view the output code text.
A common RedHat install will include 40+ scripts that are set to run at some level. (To identify those that are active and at what level use:
chckconfig -list | grep "on".)
Some obvious ones to disable on most servers are cups (printing subsystem), isdn (used to dial over ISDN lines), iptables6 (iptables for IP version 6), gpm (cut and paste for consoles), hidd (Bluetooth daemon), kudzu (identifies new hardware...servers generally are static), nfslock and portman (NFS processes).
To turn off a startup script use the off parameter with the particular startup script name. For example, to turn off isdn use:
chckconfig isdn off
Once all the unnecessary startup scripts are removed, the system can be rebooted and tested to assure that the hardening was not too aggressive.External view
Lastly, systems should be viewed from an external perspective whenever the system is turned up, using local tools and remote tool such as nmap. Any unnecessary services should be shut off.
netstat is an ideal program that can be run locally on the box to determine what network processes are running and on which ports. Several key parameters to the netstat command are the -l (listening) and -p (program). To ease researching, the particular protocol--udp or tcp--can be specified with -tcp or -udp)
The following netstat shows the tcp services that run on a RedHat 5.1 server prior to hardening:To view the netstat text, click here.
Once the unneeded programs are identified, startup scripts and the inetd super daemon investigate to determine where the unnecessary process starts up, and then shut it down.
nmap can also be used to identify the services running on a system that are network accessible. nmap has the added benefit of seeing the system how a hacker would see the system via the network.
The following nmap shows that the output of a box that has had all unnecessary network applications shut down and/or removed -- prior to installing the actual applications -- can be installed in a hardened system (only ssh is exposed to the network).
mb2:~ rmccarty$ nmap -p 1-1024 192.168.1.103 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-05-05 14:05 CDT Interesting ports on 192.168.1.103: Not shown: 1023 closed ports PORT STATE SERVICE 22/tcp open ssh Nmap finished: 1 IP address (1 host up) scanned in 1016.214 secondsSummary
By following this process, you will be installing a more secure server. This process focuses in on the server installation, the internal view (startup scripts) and an external view of the server to assist the administrator in avoiding running unnecessary applications. About the author
Ronald McCarty is the founder and CEO of the technology services company Your Net Guard. His work has been published widely in networking, systems and security.
This was first published in May 2008