Re: [gentoo-user] Testing how secure a server is...

[Raphael Melo de Oliveira Bastos Sales]

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 <goanookie@×××××.com>:
>
>
> On 8/3/05, Raphael Melo de Oliveira Bastos Sales <raphael.melo21@×××××.com>
> 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 <wwong@×××××××××.edu >:
> > > 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@g.o mailing list
> > >
> > >
> >
> > --
> > gentoo-user@g.o mailing list
> >
> >
>
>
>
> --
> I have plenty of common sense,
> I just choose to ignore it.
> --- Calvin
>

-- 
gentoo-user@g.o mailing list