Message-ID: <CAM2Hf5kLn6-Em-vd-4wQumFOeiG1jRr+QG4T2wzT9PqDKphrsw@mail.gmail.com>
Date: Tue, 6 Dec 2011 13:20:51 -0800
From: Gage Bystrom <themadichib0d@...il.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: one of my servers has been compromized

Sounds pretty neat to be honest. But one thing I'm wondering is that if
they have root, what's stopping them from turning that off? After all they
need root to load the modules in the first place, so if they are in a
position to want to do that, then they are in a position to turn that off.
Granted they probably wouldn't be able to load modules till next boot(at
least Id probably cry if that wasn't the case) but even that can be a win
scenario depending on how they want to execute the final step.
Even in the scenario that they can't unneuter root, that's even a worse
situation. Marginal protection will fall in the face of what needs to be
done. Namely taking that semi permanent step to neuter root could be a
serious pain if suddenly you needed unneutered root again. Would likely
have to take the system down to fix it. Who wants to be the guy to explain
that situation to their boss? Ergo Im pretty doubtful that such an option
couldn't be reversed by root and even if you can, its a pretty large risk
to do so if the server is fairly important.

But the hid itself could be a formidible opponent(I'm going off your word
for this one), and the kernel.panic_on_oops is a good idea since at least
then you can blame the shutdown on an attacker that screwed up and likely
left ample evidence behind.

Basically what I've been trying to say(outside of satisfying my curiosity
about several good points) is that people need to pay attention to who
their 'opponent' is at the moment. You remedy the problem presented by the
opponent with the right response. Anything more is a waste, anything less
is disastrous. Maybe that's why people like to over respond to things, to
be on the safe side, but all that means is you are far more easier to
figure out and predict to a skilled attacker. What's worse of you are
applying fixes to things that are a nonissue to an attacker in the first
place then you are in a false sense of security. Not to say that all the
things mentioned have been bad ideas(I'm endorsing several of the good
ones), but people need to make sure they understand what it is they are
/really/ stopping or mitigating and ask themselves what is it that they
should be stopping or mitigating. Good tools for the wrong job still makes
them wrong tools for ones situation.
On Dec 6, 2011 12:40 PM, "John Jacobs" <flamdugen@...mail.com> wrote:

>
> Those considering Tripwire I would ask they take a look at OSSEC-HIDS; the
> filesystem change notification is outstanding and with inotify() support
> you get immediate notification of changes.  The monitoring and alerting of
> log files is also exceptional.  I am not affiliated with OSSEC in any way.
> http://www.ossec.net/main/about
>
> I would recommend from a "rooting" aspect that kernel module loading be
> disabled after boot.  This is accomplished by removing the CAP_SYS_MODULE
> permission using something like lcap on older systems or by using the
> sysctl value of 'kernel.modules_disabled = 1'.  This can save a box by
> preventing automatic or intentional loading of a vulnerable modules or a
> module-based rootkit.
>
> The sysctl value of 'kernel.panic_on_oops = 1' also is a good idea.
>
> Thanks,
> John
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists