Re: Honeynet Project Security Advisory 2004-001: Sebek

[John Washington <jawashin () uiuc edu>]

On Jan 22 at  2:02 pm, Edward Balas handed me the following bytes:
> Solutions:
> ==========
>
>
> In the immediate term, a revised sbk_install.sh script has been
> added to the sebek-linux-2.1.4 code.  This installer first changes
> the name of the kernel module, then it then modifies the module
> loading process to reduce the number of symbols that are left
> floating in memory.   This short term fix will cause sebek_rape to
> fail , however one should always follow best practices.
>
>       - "-y" flag has been added to the insmod command, this prevents
>              the definition of ksymoops symbols for Sebek, which
>              with then cause sebek_rape to fail.
>
>       -  a few code changes have been added to make it a little
>          bit harder extract the config.
>
> This patched version is available at:
>
>       http://www.honeynet.org/tools/sebek
>       16708ad30e2caf8431735439fcb60fd5  sebek-linux-2.1.5.tgz
>
> In the short term, a new version of the Linux client will be
> available, that will make it more difficult to detect and extract
> the configuration from memory.

Wouldn't it also make sense to do something along the lines of using known (non-conflicting) module names (determined 
at setup for the honeypot) that would appear innocous on the honeypot?  Obviously this can be applied to other things 
that are common.

As a sidenote, the reason I would choose (random) valid names is to lower the probability of just looing for a string 
that doesn't fit/isn't known.

Thanks for the time.

John Washington
Dreading the away messages...