A new Adore root kit

Perl isn't my strongest language (I usually write pure C code), but it seemed like the best bet for such a quick and dirty task... But, any strong Perl coders, forgive any obvious mistakes on my part... ;-)

This is one of the best reasons to run a tight SNORT Prelude
configuration. The default NIDS code is sort of like virus scanners
in that they only tell you about KNOWN attack signatures. However,
you can make a SNORT configuration that's more like a checksum
integrity tool (like Tripwire, AIDE or Samhain, only for net traffic).

Basically you have to be able to characterize, in detail the proper
and expected behavior of the protected system(s). A profile
of everything it should be allowed to do on the net. For example a
web server might need:

Inbound:
dst port 80 or 443 from anywhere,
dst port NTP from (list of three to give NTP peers),
dst port SSH from (list of two or three sysadmin workstations
and/or staging servers)
dst port SNMP from (list of NMS systems)
Outbound:
dst port any from port 80 or 443 (http and https)
dst port CVS (perhap for automated checkout of new changes
which are checked in by webmasters, web authors, programmers, etc.
dst port DNS to (list of internal name servers) (for reverse lookup?)

... and so on.

Once done properly ANY traffic that doesn't fit these rules will
be an alert on the NIDS (network intrusion detection system).
(Unless it also exploits a bug in your NIDS, which is hopefully
pretty hard to do these days).

Of course this sort of Draconian/totalitarian configuration is only
suitable for highly specialized servers. The more services running
on a machine the harder it is to characterize it's traffic. For most
client systems (workstations) ... FORGET IT!

I hope its clear why this works better than looking for bad traffic.
Here we look for "not good traffic." (Similarly one of the first
rules of secure and robust programming for parsers is that it's better
to suppy a list of known innocuous characters, tokens whatever, then
to attempt to filter out a list of "suspects").

JimD

So, is some sort of hardware-based code signing really the only thing that can be done? Other than "don't let bad people get root", of course.

or,

Arjan has patches for 2.6 in the RH kernel that allow access through /dev/mem to only the first 1MB of memory (for tools that look at BIOS info, eg SMBIOS), and non-RAM memory (X drives PCI cards using IO through /dev/mem).

>In either case, however, you must contend with the fact that it is still 
>possible to patch code into the kernel without loading a module via /dev/mem.

To block access through /dev/mem, just drop the sys_rawio capability.  [You
might even be able to drop sys_rawio after starting X; I've only dropped it 
on servers.]

Some good references are:
   http://lwn.net/1999/1202/kernel.php3
   http://lwn.net/2000/0629/backpage.php3  # Subject: disabling module loading 

But I recall that some time ago LWN (or possibly some other Linux web page, not sure) reported discussions among kernel developers about deprecating the making of statical kernels altogether. Did that already happen with 2.6? Is it likely to happen?

Anyway, this solution is not quite feasible for most ordinary users: configuring the kernel with its hundreds of options is tedious, and I have found it can be difficult to decide what drivers or features can be disabled safely. The result is also less flexible when new hardware is installed. So I do not think the statical kernel a very practical solution for most users. Other alternatives are needed for securing against rootkit modules..

For those interested in patching the kernel w/o LKM
http://www.phrack.org/phrack/58/p58-0x07

It's worth noting that the issue of signed modules has recently cropped up in a debate on lkml. It looks as though something will eventually go mainstream - but what form it'll take is still subject to list wrangling.

Cheers,

Jon.