DISCLAIMER: We recommend you consult your organisation's security and privacy polices, as well as any laws for your area before implementing any of the suggestions in this section.
G.1 syslog configuration
Consider using syslog's remote logging feature to send logs to a separate logging computer.
Remote logging ensures that even if the UNIX system is compromised, attackers cannot simply modify the log files to cover their tracks.
Consider protecting the network logging stream with authentication and encryption, for example by tunnelling it over SSH with netcat.
If logging over the network, do log to local files as well.
Unless this computer is a log server, ensure that syslog will not accept incoming log packets over the network. On some systems this is the default. On others it may be implemented by starting syslog with the -t option (nolisten).
Consider increasing the level of logging provided by syslog.
Make sure that the messages of the LOG_AUTH facility at level LOG_INFO and above get logged.
For email, enable a minimum level of "info" for mail messages to be logged by syslog.
Check that there is a reliable mechanism for log rotation. If there is not, you may need to replace an existing logging daemon with a more secure or full-featured one.
Check that all login attempts are logged, both successful and unsuccessful. There may be several different ways to log in, such as at the console, through X and through SSH.
Consider protecting your log files with filesystem attributes if possible, to make them append-only. See section E.4.2 for details.
OpenBSD, AIX
G.2 Monitoring of logs
G.2.1 Process for log monitoring
Logs and audit trails are only of limited use unless people are actively monitoring them. Decide on a specific time period within which people will monitor the logs.
Consider automatically emailing logs or log extracts to the internal email addresses of the relevant people. Check that the sensitivity of information contained in the logs is appropriate to distribute this way.
G.2.2 Automated log monitoring tools
Automated tools cannot replace human judgement, but they make the process of people monitoring the logs much more efficient by providing different filtered and processed views on the logs, and alerting automatically based on defined patterns.
Automating to some degree is highly recommended as otherwise it is unlikely that the human component of the log monitoring task will actually be done.
Two example programs are swatch and logsentry. Further information on log monitoring and available tools is available at http://loganalysis.org
Ensure any automated reporting facilities provided by your operating system are turned on, and are sending output to an appropriate user for reading. (e.g. FreeBSD / OpenBSD daily scripts)
Regularly monitor logs for both successful and unsuccessful logins, and uses of su and sudo.
Regularly check for repeated access failures.
G.3 Enable trusted audit subsystem if available
On many platforms a more comprehensive audit subsystem is optionally available.
The benefit is to allow more dependable and configurable logging of a wider range of security events.
Enable the trusted system audit features if available for your platform.
Linux, Solaris, HP-UX, AIX
G.4 Monitor running processes G.4.1 Availability of servers
Do actively monitor the running status of server processes on your machines - tools are available that make it possible to do this remotely. Some
examples of these are:
Argus system monitoring software http://argus.tcp4me.com/
Big Brother http://www.bb4.org Nagios http://www.nagios.org/
For some commercial UNIX variants, specialized server monitoring tools are also available from the vendor.
G.4.2 Process accounting
Consider turning on process accounting, if available for your system. Process accounting allows the kernel to keep records of each command run, the user and the time, exit codes, as well as what amount of system resources (CPU, memory, disk I/O) were used.
Regularly monitor process accounting log files for activity of interest.
Check that process accounting log files are owned by root and have permissions 600.
G.4.3 lsof
lsof is a tool for monitoring open system files that can be useful in checking current activity on the system. lsof may be included with your operating system, and is also available from the source at ftp://lsof.itap.purdue.edu /pub/tools/unix/lsof/
G.5 Host-based intrusion detection G.5.1 File integrity checker
Consider using a file integrity checker for intrusion detection, providing monitoring for unexpected filesystem changes.
When using a file integrity checker:
Have a system administration procedure in place to check and update the database at least weekly to reflect legitimate changes. Without this any real security alerts may be lost amidst the noise of legitimate changed files.
Consider storing the integrity checker binary, its database and configuration file on hardware write-protected media, and using a
binary that is statically linked.
Consider running the integrity checker from a bootable CD. This is the most tamper-proof option, but is not appropriate in many cases because it involves downtime while the check is run.
An example file integrity checker is the open source Tripwire, available from http://sourceforge.net/projects/tripwire/
AIX, Solaris
G.5.2 Antivirus / malware detection
Antivirus products that run on UNIX systems are often aimed at detecting Windows malware that passes through a UNIX email or file server. However several companies also produce antivirus software specifically targeting known UNIX malware.
In particular where UNIX is deployed on desktop workstations, consider the use of antivirus / malware detection software to detect content-based attacks on the clients.
Depending on the operating system, free tools may also be available to check for known trojaned binaries or malicious kernel modules that may be
installed by an attacker after compromising the system. The chkrootkit tools available from www.chkrootkit.org are able to detect some of the most common rootkits. Chkrootkit runs on Linux, *BSD, Solaris, HP-UX and Mac OS X.
Host-based intrusion detection - notes: HP-UX
G.6 Network intrusion detection G.6.1 Signature matching IDS
Consider deploying a signature matching network intrusion detection system, aimed at detecting attempted and successful network attacks.
Snort is one open source network IDS which performs real-time traffic analysis and packet logging. It can use protocol analysis and content searching/matching to detect a variety of known attacks, based on configured signatures. Snort is available at: http://www.snort.org/
Do not run a signature matching network IDS tool or protocol analyser in promiscuous mode on the server itself. Instead use a separate
computer/device. This protects your server and network from vulnerabilities in the IDS software itself.
Consider connecting the IDS to the network to be monitored via a read-only network tap or a spanning port on the switch.
G.6.2 ARP monitoring
Consider using an ARP monitoring tool to detect ARP spoofing attacks within your LAN.
One such tool is arpwatch, available at http://www-nrg.ee.lbl.gov/
Monitoring - general notes: OpenBSD