These code fragments were developed in discussion with Lance at the honeynet project. I believe releasing them does more good in helping deploy logging measures and in deterring script kiddies than it does harm in showing the kiddies detail of what a honeypot might be recording. An attacker could always determine if you were running a non-standard shell for example. What he might read here suggests to him one of the things a non-standard shell might be doing.
The bash2_patch records shell history (nearly the same thing as keystrokes at least as far as shell commands are concerned) It's an easy but not very comprehensive form of logging. bash patch. unSpawn has provided an RPM using this patch at his Belgian site. Carlo Perassi has adapted it for bash-2.05b at his Italian site.
Tim Aldrich (taldrich netlink.net) has suggested keystoke timing can help distinguish the execution of a script from human typing. This potentially shows whether you are facing a tool in the hands of any black hat, or have gained the personal attention of an exploit pioneer. I wonder how much timing information will survive the network transfer, particularly if bunches of characters get sent together (telnet line mode?).
The kern_logs changes are lower-level thorough measure that logs process details. (developed against 2.2.12) kernel mods. This results in logs such as the following
blah: PID=498, forked child 510 blah: PID=510 exec (/bin/cat) (args=2, evars=19) uid=0 euid=0 blah: PID=510 being releasedInteresting events for you to trace might be where an intruder uses a daemon to get a shell, possibly as a common user and then converts it to a root shell via a local exploit. Following the series of exec calls made by a single process (i.e. a single PID in the interval between the fork() and release() log entries) might show informative stuff such as:
inetd---tcpd---ftpd---sh(uid=-2)---xterm---sh(uid=0)
This should show which particular programs are being exploited (ftpd and xterm in my hypothetical example here). It could lead to the publication of vulnerabilities only previously known to blackhats. I'd be interested in seeing any chains like the above to match them to known vulnerabilities for the benefit of the linux security audit project (which seems to have faded away - Sardonix is the nearest thing I know of but that doesn't look very active).
Logging exec() is a thorough way of seeing what actually happens on the box as distinct from what somebody typed. Suppose somebody encrypted a session to your box, downloaded "a.out" and ran it. Your sniffer cannot tell you what it does. Neither can the bash history log. The only record of what the mystery program actually does comes from the exec patch (and that only covers fork, exec and release events). Apart from that you're probably looking at taking the system down and using tripwire to detect disk changes for whatever files still exist.
The other main thing to be logged is obviously backdoor installation. Your tripwire scans are useful for this, but real-time logging of the creation of new files, renaming of old files and chmod()s to s[ug]id status are also significant. I've written no code for this, but it ought to be simple.
This is a syslogd patch (for sysklogd-1.3-31) that records log info in "/dev/stealth_log" as well as in the destinations specified in your syslog.conf (provided that the entry goes somewhere). Of course you should replace "/dev/stealth_log" with some otherwise unused disk partition of a fair size. The logs are written in rotation round this file with a track being kept of the current position always at the start of the file so that reboots result in your records continuing from the current position instead of always overwriting the beginning. It calls fsync() for every log entry at some expense in speed and noise. This of course gives you some worthwhile local logs even after an "rm -r" or rootkit-style alteration of /var/log/*. syslogd patch.
If there are suggestions and bugfixes arising from this material please send them to me at ant notatla.org.uk .