On Wed, Aug 03, 2005 at 02:25:29AM +0000, Raphael Melo de Oliveira Bastos Sales 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? > > I've read about HoneyPots, which I can only assume is a decoy for an > attacker. Anyone knows how to set one up? > > 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. >
Beats me there? Guys? Thoughts? I don't run an enterprise server. I am just a student q=. All I care about is not having my own server rooted by script kiddies to serve warez. With that said, since I found most IDS too powerful for my needs and difficult to configure (too steep a learning curve for my limited needs), I just code my own IDS in perl q=. I just have scripts that parse the server logs and look for trigger conditions, at which time it blocks off the offending site or the entire service for a set amount of time necessary. Pretty standard way to deal with things I believe. But then, since you are really into security, perhaps you need better systems. Finally, if you are just working with the SSH portion of the brute forcing problem, /. had an article about it a few weeks back. There were MANY IDS systems posted in the comments that specifically works with openssh. HTH, W > 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 -- A nice box of chocolates can provide your total daily intake of calories in one place. Now, isn't that handy? Sortir en Pantoufles: up 2 days, 12:06 -- gentoo-user@gentoo.org mailing list
