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

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

[Raphael Melo de Oliveira Bastos Sales]

Hi there,

   I was wondering what tools should I use to detect security flaws to
my server and a few tips on how to use them. What are the most common
forms of attack and how do I avoid being attacked by one of them?

   The services avaliable are only Apache - SSL and SSH. I've
installed an firewall, iptables and firestarter to control it, and
blocked all ports except 443 and 8080, where the SSH is listening.
Apache has PHP installed as a module.

Thanks for the attention,

Raphael.

-- 
gentoo-user@gentoo.org mailing list

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

[Peter De Zutter]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

Hi,
2 tools nmap and nessus for network/port scanning and others.
For hardering you could use bastille.
Of course all found in portage.
Peter

On 8/3/05, Raphael Melo de Oliveira Bastos Sales <raphael.melo21@gmail.com> 
wrote:
> 
> Hi there,
> 
> I was wondering what tools should I use to detect security flaws to
> my server and a few tips on how to use them. What are the most common
> forms of attack and how do I avoid being attacked by one of them?
> 
> The services avaliable are only Apache - SSL and SSH. I've
> installed an firewall, iptables and firestarter to control it, and
> blocked all ports except 443 and 8080, where the SSH is listening.
> Apache has PHP installed as a module.
> 
> Thanks for the attention,
> 
> Raphael.
> 
> --
> gentoo-user@gentoo.org mailing list
> 
> 


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

[-- Attachment #2: Type: text/html, Size: 1292 bytes --]

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

[Colin]

On Aug 2, 2005, at 7:50 PM, Raphael Melo de Oliveira Bastos Sales wrote:

> Hi there,
>
>    I was wondering what tools should I use to detect security flaws to
> my server and a few tips on how to use them. What are the most common
> forms of attack and how do I avoid being attacked by one of them?
>
>    The services avaliable are only Apache - SSL and SSH. I've
> installed an firewall, iptables and firestarter to control it, and
> blocked all ports except 443 and 8080, where the SSH is listening.
> Apache has PHP installed as a module.
>

Want to know how secure your server is?  Try and hack it!

A good port scanner like nmap should be a basic check of your  
firewall.  I would also set nmap (if it can do this) to perform a SYN  
flood as it scans, to see if your server can withstand that basic DoS  
attack.  (Adding --syn to your TCP rules in iptables can prevent SYN  
flooding when used with SYN cookies.)  When you break in, find out  
why it worked and how it can be patched.

Some things I would advise (I'm currently working on a server at the  
moment as well):
  - If the server is really important (or if you're paranoid), use  
the hardened-sources with PIE/SSP to prevent badly-written programs  
from arbitrarily executing code.
  - Enable SYN flood protection.  There's a kernel option somewhere  
about IPv4 SYN cookies, enable that, and couple it with --syn  
attached to your TCP rules in iptables.  It's a very popular denial- 
of-service attack.
  - Whenever you need to login or authenticate yourself, make the  
system delay five seconds after a bad password is entered.  This will  
make a brute-force attack much much slower (0.2 passwords/sec as  
opposed to millions passwords/sec without a delay, depending on your  
server's speed).
  - Make sure iptables is set to deny all traffic that isn't  
explicitly allowed.
  - Turn off any services you don't need.
  - Read through your logs every now and then.  I highly advise  
having the server burn them to a CD/floppy every now and then for an  
instant backup.  Get a log reader/parser, too.

Naturally, hide the server in the attic or basement.  Chain it to  
something, or if it has a security slot, use a security cable.  Put a  
lock on the case door.  Unplug your floppy/CD drives if you're not  
using them.  As of this writing, there is no kernel option to keep  
your computer or its innards from walking away. :-)
--
Colin
-- 
gentoo-user@gentoo.org mailing list

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

[Raphael Melo de Oliveira Bastos Sales]

Thanks Peter.  I'm just finishing visiting the home page of almost
every package on the net-analyzer category. If I didn't have such a
short dead line, I'd test them all. ;)

2005/8/3, Peter De Zutter <goanookie@gmail.com>:
> Hi,
>  2 tools nmap and nessus for network/port scanning and others.
>  For hardering you could use bastille.
>  Of course all found in portage.
>  Peter
> 
> 
> On 8/3/05, Raphael Melo de Oliveira Bastos Sales <raphael.melo21@gmail.com>
> wrote:
> > 
> > Hi there,
> > 
> >    I was wondering what tools should I use to detect security flaws to
> > my server and a few tips on how to use them. What are the most common
> > forms of attack and how do I avoid being attacked by one of them? 
> > 
> >    The services avaliable are only Apache - SSL and SSH. I've
> > installed an firewall, iptables and firestarter to control it, and
> > blocked all ports except 443 and 8080, where the SSH is listening.
> > Apache has PHP installed as a module. 
> > 
> > Thanks for the attention,
> > 
> > Raphael.
> > 
> > --
> > 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

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

[Raphael Melo de Oliveira Bastos Sales]

Hey Colin,

I was looking at the /etc/ssh/sshd_config file and found these:

LoginGraceTime 600
MaxAuthTries 6

Is the first one what you meant?

The second seems like an attempt to avoid brute force login. 

Also, does Grub need any kind of password protection? I don't know if
it was Grub or Lilo that allowed root access unless password
protected. Am I mistaken?

As you can see, I still have a lot to learn. ;)

2005/8/3, Colin <signofzeta@gmail.com>:
> 
> On Aug 2, 2005, at 7:50 PM, Raphael Melo de Oliveira Bastos Sales wrote:
> 
> > Hi there,
> >
> >    I was wondering what tools should I use to detect security flaws to
> > my server and a few tips on how to use them. What are the most common
> > forms of attack and how do I avoid being attacked by one of them?
> >
> >    The services avaliable are only Apache - SSL and SSH. I've
> > installed an firewall, iptables and firestarter to control it, and
> > blocked all ports except 443 and 8080, where the SSH is listening.
> > Apache has PHP installed as a module.
> >
> 
> Want to know how secure your server is?  Try and hack it!
> 
> A good port scanner like nmap should be a basic check of your
> firewall.  I would also set nmap (if it can do this) to perform a SYN
> flood as it scans, to see if your server can withstand that basic DoS
> attack.  (Adding --syn to your TCP rules in iptables can prevent SYN
> flooding when used with SYN cookies.)  When you break in, find out
> why it worked and how it can be patched.
> 
> Some things I would advise (I'm currently working on a server at the
> moment as well):
>   - If the server is really important (or if you're paranoid), use
> the hardened-sources with PIE/SSP to prevent badly-written programs
> from arbitrarily executing code.
>   - Enable SYN flood protection.  There's a kernel option somewhere
> about IPv4 SYN cookies, enable that, and couple it with --syn
> attached to your TCP rules in iptables.  It's a very popular denial-
> of-service attack.
>   - Whenever you need to login or authenticate yourself, make the
> system delay five seconds after a bad password is entered.  This will
> make a brute-force attack much much slower (0.2 passwords/sec as
> opposed to millions passwords/sec without a delay, depending on your
> server's speed).
>   - Make sure iptables is set to deny all traffic that isn't
> explicitly allowed.
>   - Turn off any services you don't need.
>   - Read through your logs every now and then.  I highly advise
> having the server burn them to a CD/floppy every now and then for an
> instant backup.  Get a log reader/parser, too.
> 
> Naturally, hide the server in the attic or basement.  Chain it to
> something, or if it has a security slot, use a security cable.  Put a
> lock on the case door.  Unplug your floppy/CD drives if you're not
> using them.  As of this writing, there is no kernel option to keep
> your computer or its innards from walking away. :-)
> --
> Colin
> --
> gentoo-user@gentoo.org mailing list
> 
>

-- 
gentoo-user@gentoo.org mailing list

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

[Colin]

On Aug 2, 2005, at 9:18 PM, Raphael Melo de Oliveira Bastos Sales wrote:

> Hey Colin,
>
> I was looking at the /etc/ssh/sshd_config file and found these:
>
> LoginGraceTime 600
> MaxAuthTries 6
>
> Is the first one what you meant?
>
> The second seems like an attempt to avoid brute force login.
>

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.

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


> Also, does Grub need any kind of password protection? I don't know if
> it was Grub or Lilo that allowed root access unless password
> protected. Am I mistaken?

GRUB does have some password protection, but it is optional and only  
needed IIRC if you want to boot something other than the default entry.

> As you can see, I still have a lot to learn. ;)

Me too.  I'm waiting for some more hardware to arrive before I  
connect this server to the networks (it's primarily a NAT gateway  
with iptables, but also *for the LAN, not the Internet* runs Apache,  
ProFTPd, SSHd and rsyncd for Portage).
--
Colin
-- 
gentoo-user@gentoo.org mailing list

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

[Willie Wong]

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

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

[Raphael Melo de Oliveira Bastos Sales]

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.

2005/8/3, Willie Wong <wwong@princeton.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@gentoo.org mailing list
> 
>

-- 
gentoo-user@gentoo.org mailing list

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

[Willie Wong]

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 <wwong@princeton.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@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

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

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Hi,
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.
>
>  
>
..SNIP...
For a long time using 'prelude+snort' easy to set up and use, all are in
portage and there is a guide to setup.
Or just snort alone. Simpler easier.
HTH. Rumen


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3397 bytes --]

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

[kashani]

Colin wrote:
> 
> Want to know how secure your server is?  Try and hack it!
> 
> A good port scanner like nmap should be a basic check of your  
> firewall.  I would also set nmap (if it can do this) to perform a SYN  
> flood as it scans, to see if your server can withstand that basic DoS  
> attack.  (Adding --syn to your TCP rules in iptables can prevent SYN  
> flooding when used with SYN cookies.)  When you break in, find out  why 
> it worked and how it can be patched.

I'd like to put forth a few words of caution.

	Depending on the complexity of your environment aggressive security 
scans can be fairly detrimental to your services stability. Make sure 
you inform the other admins if any that a scan will be taking place and 
do it in off hours. While most Internet facing applications today are 
pretty good about handling a scan internal custom built applications or 
newly released appliances are not.
	I once had massive load balancer failures across three geographic sites 
because of an unauthorized port scan by out new security director. Yes 
they shouldn't have locked up when send a weird packet, but we'd have 
avoided quite a bit of downtime if we had known what to look for.

kashani

-- 
gentoo-user@gentoo.org mailing list

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

[Peter De Zutter]

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

On 8/3/05, Raphael Melo de Oliveira Bastos Sales <raphael.melo21@gmail.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<http://gentoo-wiki.com/HOWTO_Use_Snort%2C_Acid%2C_and_MySQL_Effectively>.
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 
<http://cnscenter.future.co.kr/resource/security/ids/1465.pdf> , 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@princeton.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@gentoo.org mailing list
> >
> >
> 
> --
> gentoo-user@gentoo.org mailing list
> 
> 


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

[-- Attachment #2: Type: text/html, Size: 5330 bytes --]

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@gmail.com>:
> 
> 
> On 8/3/05, Raphael Melo de Oliveira Bastos Sales <raphael.melo21@gmail.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@princeton.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@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

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

[Eric S. Johansson]

Colin wrote:
> 
> On Aug 2, 2005, at 7:50 PM, Raphael Melo de Oliveira Bastos Sales wrote:
> 
>> Hi there,
>>
>>    I was wondering what tools should I use to detect security flaws to
>> my server and a few tips on how to use them. What are the most common
>> forms of attack and how do I avoid being attacked by one of them?
>>
>>    The services avaliable are only Apache - SSL and SSH. I've
>> installed an firewall, iptables and firestarter to control it, and
>> blocked all ports except 443 and 8080, where the SSH is listening.
>> Apache has PHP installed as a module.
>>
> 
> Want to know how secure your server is?  Try and hack it!

a better place to start would be a simple inventory of what you are 
running, its version, configuration and what you want to run.  If 
there's a delta, justify or fix.  no need to do any sort of Port 
scanning or penetration testing 80% of the time.

a simple inventory most of your security questions right off the bat. 
Of course it's not as sexy or ego inflating as running penetration tools 
but it gives you one thing the others don't.  And audit trail. 
Something you can show to your lawyers and insurance people that you 
practiced due diligence in knowing your system vulnerabilities.

if you are running Apache however you do need to run some form of attack 
because it is trivially easy to write an Apache configuration which 
leaves you butt naked to the world and not know it until you've been had.

there are similarly complex services (i.e. Samba) that leave you easily 
vulnerable.

so my advice would be to use more secure and easily secured alternatives 
whenever possible.

> A good port scanner like nmap should be a basic check of your  
> firewall.  I would also set nmap (if it can do this) to perform a SYN  
> flood as it scans, to see if your server can withstand that basic DoS  
> attack.  (Adding --syn to your TCP rules in iptables can prevent SYN  
> flooding when used with SYN cookies.)  When you break in, find out  why 
> it worked and how it can be patched.
> 
> Some things I would advise (I'm currently working on a server at the  
> moment as well):
>  - If the server is really important (or if you're paranoid), use  the 
> hardened-sources with PIE/SSP to prevent badly-written programs  from 
> arbitrarily executing code.

you should run this no matter what.  There is no excuse to leaving 
yourself vulnerable to these kinds of attacks if there is a method of 
catching them.  Security is not just a single layer.  It's multiple 
layers of good coding, language used, and operating system provided 
barriers.  Since developers insist on using languages like C, C++ 
providing features behind most security problems, you really need 
PIE/SSP in place for when the inevitable mistake happens.

>  - Enable SYN flood protection.  There's a kernel option somewhere  
> about IPv4 SYN cookies, enable that, and couple it with --syn  attached 
> to your TCP rules in iptables.  It's a very popular denial- of-service 
> attack.

again, never run without it.  That way you don't need to do any testing 
because the problem is handled.

>  - Whenever you need to login or authenticate yourself, make the  system 
> delay five seconds after a bad password is entered.  This will  make a 
> brute-force attack much much slower (0.2 passwords/sec as  opposed to 
> millions passwords/sec without a delay, depending on your  server's speed).

again should be built-in to system services.  Why do it yourself and 
risk error?

>  - Make sure iptables is set to deny all traffic that isn't  explicitly 
> allowed.

apparently good statement but let's look at the implications.

if the services aren't on and there is nothing listening on the port, 
this isn't really necessary.  if the services are on but not needed, see 
recommendation above about turning them off.

if services are needed on one interface but not the other, bind to the 
right interface.  It would make sense to use a deny rule in case 
something goes wrong.

if you are providing services to the net at large, deny rules are not 
practical.

If you're providing services to a limited number of people on the net at 
large, you need to worry more about authentication and communications 
confidentiality.

If you are providing services internally, may be practical in some 
cases, but more likely to bite you in the butt when things change on the 
internal network.

that's all the cases I can think of, any others?

>  - Read through your logs every now and then.  I highly advise  having 
> the server burn them to a CD/floppy every now and then for an  instant 
> backup.  Get a log reader/parser, too.

very good advice.  I personally like the idea of storing logs on another 
machine.  But a log reader/parser to bring out the highlights.  Also be 
prepared to spend hours every day verifying each log quirk.  Whenever 
possible, try to eliminate noise from the logs so you can pull out the 
real information necessary to detect problems.

> 
> Naturally, hide the server in the attic or basement.  Chain it to  
> something, or if it has a security slot, use a security cable.  Put a  
> lock on the case door.  Unplug your floppy/CD drives if you're not  
> using them.  As of this writing, there is no kernel option to keep  your 
> computer or its innards from walking away. :-)

I put my servers in a block of cement and drop them in the middle of the 
North Atlantic.  Only the U.S. Navy knows where they are.

---eric
-- 
gentoo-user@gentoo.org mailing list

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

[Eric S. Johansson]

Raphael Melo de Oliveira Bastos Sales wrote:
> 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.

first, on the issue of distributing, yes, you will have a nominally more 
secure application.  This assumes of course that the attacker cannot 
take any part of your application and use it against you by accessing 
the database themselves.

the interesting paradox is that by moving your application to another 
machine and using a network between them for communicating data, the 
application usually runs faster.

Think carefully about the RPC mechanism.  Don't try to reinvent the 
wheel with your own socket connection because you will spend a lot of 
time getting it right and validating it when you could be doing other 
things that are more fun, productive, and impressing your boss with your 
lack of "not invented here" attitude.

corba is complex to get started but it is one of the faster RPC 
mechanisms available (if memory serves).  XML RPC is trivially easy to 
use but is much slower because of XML.  Sun RPC.  Well, it's a gray 
beard.  Try not to use it.

On the security profile, don't sweat it.  The best you can do is set out 
the local machine firewalls to deny access from each other except for 
the database connection.  ssh should only be permitted from your green 
network.  Everything else really depends on what you need exposed and where.

connection security can be handled with SSL.  Many database engines 
support this (if memory serves).


---eric
-- 
gentoo-user@gentoo.org mailing list

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

[Joseph]

On Tue, 2005-08-02 at 23:50 +0000, Raphael Melo de Oliveira Bastos Sales
wrote:
> Hi there,
> 
>    I was wondering what tools should I use to detect security flaws to
> my server and a few tips on how to use them. What are the most common
> forms of attack and how do I avoid being attacked by one of them?
> 
>    The services avaliable are only Apache - SSL and SSH. I've
> installed an firewall, iptables and firestarter to control it, and
> blocked all ports except 443 and 8080, where the SSH is listening.
> Apache has PHP installed as a module.
> 
> Thanks for the attention,
> 
> Raphael.

I have port knocking installed on firewall, to further protect any SSH
attacks. 
So port 22 is closed (in stealth mode) and only opens if it received the
right knock sequence, moreover it is only opened to an IP address from
which received successful knock sequence; all others see this port as
closed (in stealth mode).

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

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

[Nagatoro]

Willie Wong wrote:
> 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

Mind sharing those scripts?

-- 
/Naga
-- 
gentoo-user@gentoo.org mailing list

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

[Willie Wong]

On Wed, Aug 03, 2005 at 10:01:58PM +0200, Nagatoro wrote:
> Willie Wong wrote:
> >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
> 
> Mind sharing those scripts?
> 

Do not mind of course. But the scripts are really nothing to speak of. 
For example:

I put in conf.d/local.start
------
tail --follow=name /var/log/pwdfail/current | /usr/local/sbin/sshd_pwd_blklst.pl &
------

where the perl script is the following

------
#!/usr/bin/perl -w
# If an IP has more than 5 failed loging from SSH in the past 10, 
# we ban it for 1 hour.
# If an IP attempts to connect to a non-existing user, we ban it for 1
# hour

my @ip_addys;
while (<>) {
        if(m/sshd.*Invalid.user[^\d]*(\d+\.\d+\.\d+\.\d+)/){
                 system("iptables -A ssh_blacklist -s $1 -p tcp --destination-port ssh -j LOG --log-prefix AUTO_BLACKLIST_invld_usr");
                 system("iptables -A ssh_blacklist -s $1 -p tcp --destination-port ssh -j DROP");
                 system("echo \"iptables -D ssh_blacklist -s $1 -p tcp --destination-port ssh -j DROP\" | at + 1 hour");
                 system("echo \"iptables -D ssh_blacklist -s $1 -p tcp --destination-port ssh -j LOG --log-prefix AUTO_BLACKLIST_invld_usr\" | at + 1 hour");
        }
        elsif(m/sshd[^\d]*(\d+\.\d+\.\d+\.\d+)/) {
                if((scalar @ipaddys) > 8) { shift(@ipaddys); }
                push(@ipaddys, $1);
                if(scalar (grep { $_ eq $1 } @ipaddys) > 4) { 
                        system("iptables -A ssh_blacklist -s $1 -p tcp --destination-port ssh -j LOG --log-prefix AUTO_BLACKLIST");
                        system("iptables -A ssh_blacklist -s $1 -p tcp --destination-port ssh -j DROP");
                        system("echo \"iptables -D ssh_blacklist -s $1 -p tcp --destination-port ssh -j DROP\" | at + 1 hour");
                        system("echo \"iptables -D ssh_blacklist -s $1 -p tcp --destination-port ssh -j LOG --log-prefix AUTO_BLACKLIST\" | at + 1 hour");
                }
        }
}
-----
As you can see... it is the most primitive type to just pass a regexp
through the log file, sets some counters, and bans some ip addys with
system calls to iptables. 

I used to also run something similar over /var/log/apache2/error_log
to parse against the common worm attacks.

W
-- 
   Be careful or be road-kill.
		  -- Calvin
Sortir en Pantoufles: up 3 days,  4:00
-- 
gentoo-user@gentoo.org mailing list

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

[Ryan Viljoen]

Joseph could you direct me toward a how to on how to set that up, please.

Raphael have you gone through
http://www.gentoo.org/doc/en/security/index.xml it has some good
points and worth going through and ticking off each one.

Cheers
Rav

On 8/3/05, Joseph <syscon@interbaun.com> wrote:
> On Tue, 2005-08-02 at 23:50 +0000, Raphael Melo de Oliveira Bastos Sales
> wrote:
> > Hi there,
> >
> >    I was wondering what tools should I use to detect security flaws to
> > my server and a few tips on how to use them. What are the most common
> > forms of attack and how do I avoid being attacked by one of them?
> >
> >    The services avaliable are only Apache - SSL and SSH. I've
> > installed an firewall, iptables and firestarter to control it, and
> > blocked all ports except 443 and 8080, where the SSH is listening.
> > Apache has PHP installed as a module.
> >
> > Thanks for the attention,
> >
> > Raphael.
> 
> I have port knocking installed on firewall, to further protect any SSH
> attacks.
> So port 22 is closed (in stealth mode) and only opens if it received the
> right knock sequence, moreover it is only opened to an IP address from
> which received successful knock sequence; all others see this port as
> closed (in stealth mode).
> 
> --
> #Joseph
> --
> gentoo-user@gentoo.org mailing list
> 
> 


-- 
"When you play a Microsoft CD backwards you can hear demonic Voices...
that's nothing - when you play it forward it installs Windows"
Are you fearing my mouse? <:3___)~~~~

-- 
gentoo-user@gentoo.org mailing list

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

[Joseph]

On Wed, 2005-08-03 at 23:37 +0200, Ryan Viljoen wrote:
> Joseph could you direct me toward a how to on how to set that up, please.

I use freesco firewall and they have small package (add-on) called
knock, you can install it on a floppy see my howto:
http://forums.freesco.org/support/index.php?showtopic=13731
but eventually I moved it to HD (as I had too much problems with 1.68Mb
floppies) 
My intension was to use this setup to print to a remote printer location
over SSH, and it works like a charm.

The knock demon runs on firewall (that is the best setup) and listen for
specific knock sequence.  You can open any port this way.  
If you have a Gentoo based firewall, knock in in portage but your
machine must more mussels to run Gentoo; and Freesco will run on any
"door-stopper" starting from 486. 

-- 
#Joseph

> Raphael have you gone through
> http://www.gentoo.org/doc/en/security/index.xml it has some good
> points and worth going through and ticking off each one.
> 
> Cheers
> Rav
> 
> On 8/3/05, Joseph <syscon@interbaun.com> wrote:
> > On Tue, 2005-08-02 at 23:50 +0000, Raphael Melo de Oliveira Bastos Sales
> > wrote:
> > > Hi there,
> > >
> > >    I was wondering what tools should I use to detect security flaws to
> > > my server and a few tips on how to use them. What are the most common
> > > forms of attack and how do I avoid being attacked by one of them?
> > >
> > >    The services avaliable are only Apache - SSL and SSH. I've
> > > installed an firewall, iptables and firestarter to control it, and
> > > blocked all ports except 443 and 8080, where the SSH is listening.
> > > Apache has PHP installed as a module.
> > >
> > > Thanks for the attention,
> > >
> > > Raphael.
> > 
> > I have port knocking installed on firewall, to further protect any SSH
> > attacks.
> > So port 22 is closed (in stealth mode) and only opens if it received the
> > right knock sequence, moreover it is only opened to an IP address from
> > which received successful knock sequence; all others see this port as
> > closed (in stealth mode).
> > 
> > --
> > #Joseph

-- 
gentoo-user@gentoo.org mailing list

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

[Nagatoro]

Willie Wong wrote:
> On Wed, Aug 03, 2005 at 10:01:58PM +0200, Nagatoro wrote:
>>Mind sharing those scripts?
> 
> Do not mind of course. But the scripts are really nothing to speak of. 

Thanks!
-- 
Naga
-- 
gentoo-user@gentoo.org mailing list

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

[Jarry]

Joseph wrote:

> I have port knocking installed on firewall, to further protect any SSH
> attacks. 
> So port 22 is closed (in stealth mode) and only opens if it received the
> right knock sequence, moreover it is only opened to an IP address from
> which received successful knock sequence; all others see this port as
> closed (in stealth mode).

Hm, never heard of it...
How can this methot be installed and used with gentoo/iptables?
Any more info about it?

Jarry

-- 
gentoo-user@gentoo.org mailing list

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

[Peter De Zutter]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

This document should give you some info

http://gentoo-wiki.com/HOWTO_Port_Knocking

Peter


On 8/4/05, Jarry <jarry@gmx.net> wrote:
> 
> Joseph wrote:
> 
> > I have port knocking installed on firewall, to further protect any SSH
> > attacks.
> > So port 22 is closed (in stealth mode) and only opens if it received the
> > right knock sequence, moreover it is only opened to an IP address from
> > which received successful knock sequence; all others see this port as
> > closed (in stealth mode).
> 
> Hm, never heard of it...
> How can this methot be installed and used with gentoo/iptables?
> Any more info about it?
> 
> Jarry
> 
> --
> gentoo-user@gentoo.org mailing list
> 
> 


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

[-- Attachment #2: Type: text/html, Size: 1226 bytes --]