4.12 The importance of logs and alerts
It is easy to see that the treatment of logs and alerts is an important issue in a secure system. Suppose a system is perfectly configured and 99% secure. If the 1% attack occurs, and there are no security measures in place to, first, detect this and, second, raise alarms, the system is not secure at all.
Debian GNU/Linux provides some tools to perform log analysis, most notably swatch,
[13] logcheck or log-analysis (all will need some customisation to remove unnecessary things from the report). It might also be useful, if the system is nearby, to have the system logs printed on a virtual console. This is useful since you can (from a distance) see if the system is behaving properly. Debian's /etc/syslog.conf comes with a commented default configuration; to enable it uncomment the lines and restart syslogd ( /etc/init.d/syslogd restart):
daemon,mail.*;\
news.=crit;news.=err;news.=notice;\
*.=debug;*.=info;\
*.=notice;*.=warn /dev/tty8
There is a lot regarding log analysis that cannot be fully covered here, a good resource for information is
Counterpane's Log Analysis Resources. In any case, even automated tools are no match for the best analysis tool: your brain.
4.12.1 Using and customising logcheck
The logcheck package in Debian is divided into two packages logcheck (the main program) and logcheck-database (a database of regular expressions for the program). The Debian default (in /etc/cron.d/logcheck) is that logcheck is run daily at 2 AM and once after each reboot.
This tool can be quite useful if properly customised to alert the administrator to unusual events in the system. Logcheck can be fully customised so that it can send mails from events recovered from the logs that are worthy of attention. The default installation includes profiles for ignored events and policy violations for three different setups (workstation, server and paranoid). The Debian package includes a configuration file /etc/logcheck/logcheck.conf, sourced by the program, that defines which user the checks are sent to. It also provides a way for packages that provide services to implement new policies in the directories: /etc/logcheck/hacking.d/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_, and /etc/logcheck/ignore.d.workstation/_packagename_. However, not many packages currently do so. If you have a policy that can be useful for other users, please send it as a bug report for the appropriate package (as a wishlist bug). For more information read /usr/share/doc/logcheck/README.Debian
The best way to configure logcheck is to install it (it will ask for the user to which reports should be mailed and generate /etc/logcheck/logcheck.logfiles from syslog entries). If you wish to add new log files just add them to /etc/logcheck/logcheck.logfiles. The package dependency will also force the installation of logcheck-database; during installation it will ask which security level is desired: workstation, server or paranoid. This will make /etc/logcheck/ignore.d point to the appropriate directories (through symbolic links). To change this run dpkg-reconfigure -plow logcheck-database. Then create the /etc/ignore.d/local, this file will hold all the rules to exclude messages that should not be reported. Leave it empty for the moment (a simple cp /dev/null /etc/ignore.d/local will work).
Once this is done you might want to check the mails that are sent, for the first few days/weeks/months. If you find you are sent messages you do not wish to receive, just add the regular expressions (see regex(7)) that correspond to these messages to the /etc/ignore.d/local. It's an ongoing tuning process; once the messages that are sent are always relevant you can consider the tuning finished. Note that if logcheck does not find anything relevant in your system it will not mail you even if it does run (so you might get a mail only once a week, if you are lucky).
4.12.2 Configuring where alerts are sent
Debian comes with a standard syslog configuration (in /etc/syslog.conf) that logs messages to the appropriate files depending on the system facility. You should be familiar with this; have a look at the syslog.conf file and the documentation if not. If you intend to maintain a secure system you should be aware of where log messages are sent so they do not go unnoticed.
For example, sending messages to the console also is an interesting setup useful for many production-level systems. But for many such systems it is also important to add a new machine that will serve as loghost (i.e. it receives logs from all other systems).
Root's mail should be considered also, many security controls (like snort) send alerts to root's mailbox. This mailbox usually points to the first user created in the system (check /etc/aliases). Take care to send root's mail to some place where it will be read (either locally or remotely).
There are other role accounts and aliases on your system. On a small system, it's probably simplest to make sure that all such aliases point to the root account, and that mail to root is forwarded to the system administrator's personal mailbox.
FIXME: it would be interesting to tell how a Debian system can send/receive SNMP traps related to security problems (jfs). Check: snmptraglogd, snmp and snmpd.
http://www.debian.org/doc/manuals/secur ... log-alerts