First of all, thanks everyone for your replies. I really appreciate the help. I'll be testing snort, since it was the most mentioned one.
I'm also going to test bastille. Had a problem emerging psad, one of its dependencies. I'll send the error message later. I made all the tests with nmap to check if the firewall was working OK, the results took more from 90 to 150 minutes. And it actually said that my Gentoo Server was a Longhorn beta machine and that the SSH service was an HTTP proxy. I assume that is a good thing. Not only the attacker would have to be very patient, but also the results would be confusing. Besides, since it is not replying to ping, some people would actually think that the host is down and ignore it. I used Authforce to test if it would be easy to brute force HTTP authentication. It replied that it didn't find any passwords. Again, a good thing. About the Honey Pot. I'll read about it later. My top priority is to have a good IDS running. ;) I need to get all the arguments I can, or else my department's chief I'll force me to migrate my Web Application to Java + Corba, and I don't want to do that. He claims that if someone invades my machine, it will have direct access to all data. That I have to distribute the database, put it in another machine and have the web application access that database over the network. I feel this is a bit overkill. Not only it would force the data travel through the network, slowing it down, but would also increase the complexity of the security layout, forcing to make the two machines very secure, unstead of just one of them. Besides, I might be wrong, but I feel that a Local Socket is faster and safer than Corba trasmitting data over the internal network. If anybody has any comments, I'd be more than happy to hear it. 2005/8/3, Peter De Zutter <[EMAIL PROTECTED]>: > > > 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 > -- gentoo-user@gentoo.org mailing list
