Re: [cobalt-security] Forensics on a hacked server

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Eugene,

> kernel modules are nasty stuff.  

Indeed. I've run into a couple of 'em so far and it was always messy.

> Thus, Tripwire would have nothing to notice!  

Depends on. Usually an intruder has to gain access somehow and once on the box 
he needs to download his files and has to line up his ducks properly in order 
to implant the stuff. During that time you have a good chance to catch these 
modifications.

The more time the intruder has to make himself comfortable the less likely it 
is to catch him - unless he is careless and doesn't cover his tracks well 
enough.

> If the intruder keeps files in often-changing
> directories that are not usually checked by tripwire, it's no more
> useful than chkrootkit.

Quite right.

> On a system like Cobalt, with very little variation in hardware
> configuration, it would make perfect sense to have monolithic kernel
> without module support at all.  It would be much more difficult to get
> inside unnoticed. 

Defenitely. A while ago I had hired a kernel guru to build a custom 
(monolithic) kernel for the RaQ4 (and possibly the RaQ3) which should ideally 
also have LIDS support (Linux Intrusion Detection System). 

We used the C33 Kernel sources as a base (which were current at that time) and 
diff'ed it back and forth against 2.2.19 and 2.2.23 to isolate the changes 
and new security patches which we had to backport.

However, that guy quickly (and in drastic) words explained to me why the 
Cobalt RaQ4 kernel is so unstable. The memory management in the Cobalt kernel 
is FUBAR if you know what that means. It has been literally patched to death. 
That's why you don't get a good uptime out of any RaQ3 or RaQ4 since the C28 
kernel. The Cobalt kernel was never designed to be maintained with reasonable 
ease - to the contrary. So I do have a great deal of respect for the work of 
Tim Hockin and the other Sun Cobalt kernel maintainers, but the RaQ4  kernel 
isn't what it could be. Not their fault I guess and they sure won't get 
funded to rewrite that stuff from scratch.

In the end when we were done we had a LIDS capable 2.2.19 kernel with the Sun 
Bandwith Management, the Raid support, the network drivers and the LCD 
drivers. But we did run into plenty of minor or major issues which we were 
unable to overcome in reasonable time. One of the issues was the LIDS 
administration which is no trivial task. Running customers through that and 
supporting their queries would have been a hellish task. Especially if 
something goes wrong, which will always happen when you mess on *that* low 
level of the OS.

> As a workaround, one could use a "module locker
> module" - that, once loaded, would shut the module loading interface
> until next reboot.  

Yes, that's what LCAP does. With that you can throw abilities out of a running 
kernel - like the ability to load or unload kernel modules.

> I think I've heard about such thing (can anyone provide a pointer?).

http://packages.debian.org/stable/admin/lcap.html

-- 

With best regards,

Michael Stauber