1. Host-Based Intrusion Detection 0
Even a patched system, with wrapped services running a suitably configured
packet filter, stands a significant chance of being intruded upon by an
unwanted visitor.
1.1. Standard Host-Based Intrusion Detection
- Keep reliable logs of what's going on on your system and read
them! Log-scanning utilities and remote-logging are useful here.
- Know what files have changed (e.g., /bin/login,
/bin/ps...) so as to be able to detect an intrusion
and effect a repair. To do this use a standard host-based
intrusion-detection system (IDS) such as Tripwire which
analyses files for signs or change. Other IDSs
(e.g., Cheesewire)
monitor network and process activity in addition.
1.2. Rootkit Detection
- An intruder who gains root access may install a
rootkit, a set of system utilities and even kernel-related
software designed both to exploit the machine/system, and to hide the
presence of the exploitation and intrusion --- such a rootkit can
hide itself from standard IDSs: even running an IDS and all
it depends on from read-only media is not good enough: all
applications, including of course IDSs, rely on the integrity of the
kernel, in particular the integrity of the system-calls. Any rootkit
which changes the system-calls automatically comprises any non-kernel
related IDS which is running under the OS.
We introduce methods of detecting rootkits below.
For more on rootkits and how to detect them, see
Unix Security: More Stuff.
1.3. Boot from a CD --- "Its the only way to be sure"
The only sure-fire way of discovering a rootkit which changes the kernel
(the running OS) in order to hide itself is to periodically boot the host
from a CD-ROM containing an IDS and (minimal) OS and check the system disk(s)
for intrusion, then boot back from disk as usual. This is hardly convenient
for 24/7/265 servers, but it works.