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

["Eric S. Johansson" <esj@harvee.org>]

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