H.1 First put in place a host firewall.
H.1.1 Identify host firewall software
Most UNIX operating sytems provide a packet filtering host firewall system, either as part of the base install, or as an option you can install.
On a minority of systems, a reasonable host firewall is already configured by default on newly installed systems, though this can usually be tightened further.
Linux, Solaris, HP-UX, FreeBSD, OpenBSD, AIX, IRIX
H.1.2 Design host firewall
Do not assume that there is an internal network whose computers are trusted.
The point of the host firewall is to ensure that when one of the other
computers on your internal network is compromised, and the attacker is then able to launch attacks directly from the local LAN, they will still be unable to contact all of the services on this computer. Therefore, design the host firewall by assuming that the internal computers are already compromised, and may seek to attack this system.
Restrict incoming network connections to the minimum set of TCP/UDP port numbers required for this computer's role, as determined in section A.6 Consider also restricting outgoing connetions to the minimum set of
destination port numbers required for the computer's role. If this computer is compromised, this can make it more difficult for (the less sophisticated) malicious software to connect back out to an attacker to receive instructions.
Where a service on this computer only needs to communicate with specific hosts, consider making this explicit in the firewall rules, restricting that port number to only communicate with the specified hosts.
Ensure that the following ports can NOT be accessed over the network:
TCP port 25 (SMTP, unless this host is a mail server), UDP and TCP port 111 (portmap),
TCP port 587 (mail submission agent)
TCP ports 6000-6010 (the X Window System),
and any other services that are for use on the local computer only.
If the IPv6 stack on this computer has not been disabled, then verify that the firewall rules correctly handle IPv6 packets coming from the local LAN. Some firewall configurations ignore IPv6. Even on an IPv4 network this may give unintended access if the attacker already controls another point on the LAN.
Packet filtering can be difficult to implement correctly. For more information on firewalls and packet filtering, the following references may be of use:
Internet Firewalls FAQ
http://www.interhack.net/pubs/fwfaq/
Building Internet Firewalls, Second Edition
H.1.3 Weak end system
For computers with more than one network interface, be aware of the "weak end system" model used by most UNIX operating systems (RFC1122). This means that on hosts with more than one network interface, even if a service only binds to the IP address of one interface, this will not protect it from packets that are received on a different interface but addressed to that IP.
This is particularly important where second network cards are used to provide a separate management network.
To address this, either:
Turn off weak ES behaviour (see OS specific footnotes) or, 1.
add explicit host firewall rules to block packets coming into one interface but addressed to the IP address of another interface.
2.
Solaris, FreeBSD
H.2 Position this computer behind a border firewall.
Position the UNIX system on a protected subnet, with at least a separate firewall device sitting between it and the open Internet.
H.3 Network stack hardening/sysctls
The kernel's network settings can be tuned and made more secure, usually using the sysctl command or configuration file. The details of how to do this are very specific to each operating system. It is recommended to check the following settings:
Disable IP source routing.
Disable ICMP redirects.
Disable forwarding/routing of IP packets unless this computer is a router. See OS specific footnotes for details.
If your OS provides syncookies to mitigate SYN-flood denial of service, then ensure that this feature is turned on. Syncookies are available on Linux, Solaris and FreeBSD.
Consider configuring shorter state timeouts and increasing the size of state tables to make the system more resistant to denial of service.
For servers, consider configuring a static IP address on the host itself, rather than using a static IP allocation through DHCP.
On critical computers, consider using a static ARP cache to prevent ARP spoofing attacks from the local LAN.
Linux, Solaris, HP-UX, FreeBSD, OpenBSD, AIX
Further information on adjusting network parameters is provided in the following documents:
UNIX IP Stack Tuning Guide v2.7 (Rob Thomas) - covers AIX, Solaris, HP-UX, Linux, FreeBSD and IRIX.
http://www.cymru.com/Documents/ip-stack-tuning.html
TCP/IP Stack Hardening - covers AIX, FreeBSD, HP-UX, Linux, Solaris and IRIX.
http://www.cromwell-intl.com/security/security-stack-hardening.html
H.4 Connect to network for the first time
It is recommended to connect the computer to the network for the first time at this stage.
I. Test Backup/Rebuild Strategy
I.1 Backup/rebuild strategy
When an intrusion or suspected intrusion is detected, your options in responding will depend critically on whether you have an effective backup/rebuild strategy in place beforehand.
With a rebuild process that is largely automated, it is possible to either swap in a new hard disk and rebuild the server, or rapidly deploy a replacement server, allowing the compromised machine to be taken off the network quickly while maintaining uptime.
This ability to disconnect the computer rapidly reduces the risk of further intrusion to other systems, and at the same time preserves evidence on the hard disk at an early stage. But it depends on an effective restore and rebuilding process already being in place.
Implement a backup, restore and rebuilding process that satisfies your security policy.
Depending on the uptime requirements determined in section A.4 for this system, consider whether a replacement hard disk or a full replacement server is appropriate for your situation.
Protect the confidentiality and integrity of the backups themselves, as the information in the backups is usually as sensitive as the original system. For example, the authentication information in the backup is often sufficient to
compromise the original system remotely. For integrity, the aim is that an attacker compromising this system can only alter future backups, and not past backups.
I.2 TEST backup and restore
The implementation of the restore/rebuild system is not complete until it has been tested out in practice.
Schedule a full restore/rebuild of the system to verify that the process works and is sufficiently fast.
I.3 Allow separate restore of software and data
Consider having business data backed up and restorable separately from executable programs.
After a compromise, this allows more flexibility, for example to restore today's data but with the system and software backup from three weeks ago.
I.4 Repatch after restoring
Repatch the system immediately after restoring from backup, to ensure that all the patches and software updates released between the time that backup was made and the present are applied.
I.5 Process for intrusion response
After an intrusion or suspected intrusion has taken place, it may be necessary to liaise with law enforcement, and/or investigate what has happened, and determine if other systems on your network have been affected.
I.5.1 Documented process
Have a documented response process in place before any incident occurs.
If it is decided that police investigation is desirable, it is recommended to contact law enforcement at the earliest possible stage in the process, and to coordinate any actions with them first.
One suggested response procedure is described in the document Steps for Recovering from a UNIX or NT System Compromise Your procedure should be tailored to meet your specific requirements.
As part of your process, record in writing any steps taken in investigating an incident.
It is usually important to determine how the attacker broke in, since if you clean and restore the system without knowing this then the attacker may simply re-enter the system via the same vulnerability.
I.5.2 Forensic tools
Any investigation is best done on a forensically sound image of the affected hard disk, rather than on the original disk. If law enforcement involvement is desired, then it is recommended to leave the disk imaging to law
enforcement, and to avoid altering the system in any way before this is done.
In other cases, consider having the capability to make a forensically sound image of an affected hard disk, using dd or similar tools on a second, clean system. This will require having spare hard disks available ahead of time to create the image.
It is beyond the scope of this document to detail sound handling of the digital evidence. Some of the issues involved are mentioned in the document
Collecting Electronic Evidence After a System Compromise
Autopsy is one free forensic filesystem analysis tool for UNIX systems. It may be used to examine images of storage devices from a compromised system, and generate a timeline of recent file access.
If using this tool, run it only on an image copy of the original hard disk, on a non-networked machine.
Autopsy is available at http://www.sleuthkit.org/autopsy/desc.php
Solaris
I.5.3 Malware detection tools
For some incidents it may be useful to apply known-malware detection as described in section G.5.2 as a quick way to confirm that the system was compromised. Of course, a failure to detect known malware does not indicate that the system was clean.
J. Maintain
J.1 Mailing lists
Notifications of patch releases and security updates are generally done via mailing lists.
Subscribe to the vendor "announce" list as well as any security mailing lists for your specific operating system.
Subscribe to the appropriate security/updates mailing list for each third party software package installed.
Also subscribe to security advisory mailing lists from your local incident response team (if you have one available).
AusCERT Security Bulletins are available at http://www.auscert.org.au/1 US-CERT Vulnerability Notes are available at http://www.kb.cert.org/vuls/
J.2 Software inventory
Maintain an up-to-date list of software installed on each system, with version numbers. This list includes the base OS and each piece of third party software.
This is significant, as when a vulnerability advisory is released, it is easy to check whether the versions on your systems are affected.
J.3 Rapid patching
The window of time between vulnerabilities being publicly announced and
widespread exploitation is now very short. Design your patching and update process aiming to allow critical patches to be applied within 48 hours of patch release.
For important systems, maintain a test environment where patches can be trialled first before deploying to production systems.
Be aware that installing patches/updates can sometimes re-enable services that you have disabled.
J.4 Secure administrative access
J.4.1 Strongly authenticated access only
Only administer the computer at the console, or else over the network using tools that are properly encrypted and authenticated, such as SSH or a web interface protected by SSL. Do not assume that a corporate internal network is secure.
J.4.2 Administer only from a secure workstation
Ensure workstations used to administer a UNIX or Linux server are as least as secure as the server itself. Otherwise keystroke logging can steal your SSH private key passphrase and all administrative passwords. Public key cryptography will not protect against this.
Consider allocating system administrators two separate workstations, one for administering the systems, and the other for general work such as email,
web browsing and document creation.
J.5 Log book for all sysadmin work
Maintain a log book to record all significant system administration work on the system.
J.6 Configuration change control with CVS
Consider using a CVS server on a separate computer to manage the configuration files such as those in /etc and /usr/local/etc. This also makes rebuilding the system more efficient.
See section F.14 for secure use of CVS.
J.7 Regular audit
Design and put into action a process to re-assess the security of the system at regular intervals.
J.7.1 Re-apply this checklist
Periodically re-check the system against this checklist, and ensure that the system is still in conformance with your security policy.
In particular, re-check at this time that the software installed is only the minimal set decided on.
J.7.2 Check for dormant accounts
Regularly audit the system for dormant accounts and disable any that have not been used for a specified period of time, in accordance with your site's security policy.
At this stage also audit the password files for unauthorised additions or inconsistencies.
J.7.3 Audit weak passwords
Where appropriate, consider regularly applying a password cracking program such as "John the Ripper" to check for weak passwords.
This is especially worth considering for a multi-user system which does not have any mechanism for enforcing difficult passwords. John the Ripper is available from: http://www.openwall.com/john/
J.7.4 Apply network scan/audit tools
Use network port scanning and vulnerability scanning tools from a separate computer to check periodically that open network ports are as expected, and that no well known vulnerabilities are detected.
nmap is a port scanning tool available from: http://www.insecure.org/nmap/
Nessus is a vulnerability scanning tool available from: http://www.nessus.org OpenVAS is a vulnerability scanning tool available from:
http://www.openvas.org