From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E0K7N-0000aq-RQ for garchives@archives.gentoo.org; Wed, 03 Aug 2005 14:21:14 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j73EJn2e018797; Wed, 3 Aug 2005 14:19:49 GMT Received: from redweb.harvee.org (dsl093-191-107.nyc2.dsl.speakeasy.net [66.93.191.107]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j73EFu92003864 for ; Wed, 3 Aug 2005 14:15:57 GMT Received: from localhost.localdomain (localhost [127.0.0.1]) by redweb.harvee.org (Postfix) with ESMTP id 5092076D44 for ; Wed, 3 Aug 2005 10:16:25 -0400 (EDT) Received: from harvee.org (unknown [192.168.0.2]) by redweb.harvee.org (Postfix) with ESMTP id 5FD4176D44 for ; Wed, 3 Aug 2005 10:16:24 -0400 (EDT) Received: from [192.168.0.28] ([192.168.0.28]) by harvee.org (8.12.8/8.12.8) with ESMTP id j73EGNCB014620 for ; Wed, 3 Aug 2005 10:16:24 -0400 Message-ID: <42F0D1B7.8060201@harvee.org> Date: Wed, 03 Aug 2005 10:16:23 -0400 From: "Eric S. Johansson" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Testing how secure a server is... References: <8f7a9d5805080216505f9b4a51@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Camram: capability; stamp X-Archives-Salt: f7739af8-e0a4-4ff6-999c-1b7dc4ccdf7d X-Archives-Hash: 46b6ee4128aabbc6f94f2f5e6e43e836 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