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
