On 8/3/05, Raphael Melo de Oliveira Bastos Sales <[EMAIL PROTECTED]> wrote:
Which IDS system do you recommend? I also need to worry about HTTP
auth brute force. Know any way to stop it from happening?

Snort, oinkmaster and ACID, there is a decent guide here .
About that http thingy, depends on how critical your apache is. It's worth mentioning the O'Reilly book Linux Server Security. I bought it when I was faced with a the things and problems that involve running a production server. It gives a good general insight in the matter.

I've read about HoneyPots, which I can only assume is a decoy for an
attacker. Anyone knows how to set one up?

Never don this before, but a quick google did find a little pdf on how to setup a honeyput on a redhat.
Setting Up a Honeypot Using a. Bait and Switch Router , now  if only could have some spare time to check it out. It is hard to resist it not to try it.

I have a feeling that there isn't much I can do if a pro actually
tries to break the system. All I can do is avoid the dummies from
doing it as well.

That sums it up pretty good.
Peter

2005/8/3, Willie Wong <[EMAIL PROTECTED] >:
> On Tue, Aug 02, 2005 at 09:43:17PM -0400, Colin wrote:
> > Neither is what I was thinking of, but they're quite similar.
> > LoginGraceTime means if nobody logged in within 10 minutes of the
> > connection being opened, then it will be closed.  I don't know
> > exactly what MaxAuthTries does, but I imagine after the sixth invalid
> > login, the connection would  be closed.
> >
>
> Yes, and if the failure reaches half the number, all further failures
> will be logged. In the case of
>   MaxAuthTries 6
> It means that the first three failures will go unnoticed, the fourth
> through sixth logged, and the connection closes after that.
>
> There is, unfortunately, not an option in sshd_config to allow for the
> behaviour you specified, where after a password failure, the next
> prompt comes up delayed by five seconds. Perhaps if should be put as a
> feature request (=.
>
> Your best bet against brute forcing sshd is
>   1) Not allowing password login at all
>     or
>   2) Use some sort of IDS coupled with a firewall rule to block the
>      particular host after multiple login failures. But even that
>      won't stop a distributed brute force. But then again, if you are
>      guarding a system that really demands that much security against
>      a determined cracker, you really should consider NOT putting the
>      system on the internet.
>     or
>   3) Maybe port-knocking? Note that just by running ssh on a
>      non-standard port, you probably are avoiding most of the 5|<|21p7
>      kiddie attacks... again, only someone who really wants in on your
>      system will take the effort to locate where sshd is listening.
>
> > I found this site, check it out.  It's for Red Hat (Gentoo is
> > better!), but it's the same SSHd:
> > http://www.faqs.org/docs/securing/chap15sec122.html
> --
> It's easy to come up with new ideas; the hard
> part is letting go of what worked for you two
> years ago, but will soon be out of date.
>         -- Roger Von Oech
> Sortir en Pantoufles: up 2 days,  9:25
> --
> gentoo-user@gentoo.org mailing list
>
>

--
gentoo-user@gentoo.org mailing list




--
I have plenty of common sense,
I just choose to ignore it.
--- Calvin

Reply via email to