HIDS for GNOME Servers was: Re: brute force ssh attempt mitigation



On Wed, Mar 31, 2010 at 8:07 AM, Alexandro Silva <alexoslabs gmail com> wrote:
> On 03/31/2010 12:02 PM, Christer Edwards wrote:
>>
>> On Wed, Mar 31, 2010 at 8:50 AM, Olav Vitters<olav vitters nl>  wrote:
>>>
>>> Yes.
>>>
>>> Error message is due to the NFS mounts on puppet being broken
>>> (/home/admin, /home/users). You can still log in though (aside from home
>>> dir not existing complaints)
>>>
>>> --
>>> Regards,
>>> Olav
>>>
>>
>> So I'm hearing that bruteforce mitigation via denyhosts won't add any
>> additional security, and I agree (after understanding better how
>> accounts are managed). Does this mean let's just not bother? I don't
>> think it'll hurt, and if anything it'll simply clean up the logs and
>> cut down on the noise a bit.
>>
>
>
> Hi,
>
> I'm not following this thread but I suggest the implementation of a HIDS [1]
> on the servers, so we proactive actions against many threats.
>
> [1] http://www.ossec.net

Ossec is actually more of a LIDS than HIDS, but does both. As a former
contributor I'd suggest against it only because there is no sane way
to package or maintain it without manually compiling it and going
through the interactive installer on each host. He has 1 shell script
to build and compile it on virtually every Unix platform still around.
It is beyond scary. Several years ago I wrote a key manager[1] so you
didn't have to interactively register each client to the main ossec
server. That doesn't solve manually compiling and configuring it on
each host.

However, if it was easy for a crappy non-dev like moi to get a few C
patches in (SCHED_BATCH for throttling syscheck), it would be easy for
others to do the same. Upstream (Daniel Cid) is really friendly and
easy to work with.

HIDS isn't a bad idea at all, but we don't have a sane way to manage a
lot of this stuff yet. We don't even have centralized syslog! Lets
focus on the core problems. Is there an up to date wiki page of the
good idea like this everyone has? If not we should make one and start
fleshing these projects out.

[1] http://www.digitalprognosis.com/opensource/scripts/ossec-batch-manager.pl

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]