Re: hardening checkpoints
On Thu, 2005-12-15 at 12:27 +0000, kevin bailey wrote:
> hi,
>
> was recently rootkitted on a debian machine because i'd left an obscure
> service running.
>
> now i've generally relied on debian issuing security patches but i thought i
> should be more proactive RE security.
>
> here's my proposed checklist to carry out for securing a domain server -
> i.e. one which mainly deals with serving websites and email for virtual
> domains.
>
> could people please supply any enhancements/corrections/deletions or point
> to any resources which detail a better hardening checklist for debian.
>
> 1. before attaching server to network install and configure tripwire.
>
> and could possibly put key executables on to CD-ROM and leave them in the
> server.
>
> 2. firewall
>
> not i'm not sure about the need for a firewall - i may need to access the
> server over ssh from anywhere. also, to run FTP doesn't the server need to
> be able to open up a varying number of ports.
>
> BTW - FTP *has* to be available - many of the users only know how to use
> FTP.
>
> since my experience of firewalls is to protect a home network i basically
> turned off access by default - and then only opened up a couple of ports
> which were needed.
>
> maybe the new iptables feature of --state ESTABLISHED which uses stateful
> packet filtering is the way forward.
>
> currently - i see no compelling need to set up a firewall - especially since
> if i get it wrong i could lose access to the machine.
I suggest you set up host based firewalling, where iptables limits
incoming/forwarding/outgoing traffic to whatever services you are
running. This is especially important if your running a webserver and
allow user cgi uploads, or cgi's with vulnerabilities are already
installed. For example, I had cacti from debian stable installed on a
monitor server at one point that got hacked by a script kiddie well
before the security patch was released. I have also had web users
install vulnerable cgi's that kiddies use to install programs that
launch DOS attacks on other networks, which in turn caused my network to
get DDOSed in retaliation (I am guessing really). Anyways on a
multi-user web server it difficult to track down the vulnerable cgi
unless you run the cgi's as the account owner (as apposed to all running
as www-data), and the conversion to suexec or cgiwrap is nontrivial
(although I recommend it highly as you can also get cpu/mem limits with
cgiwrap), so for me blocking new or unrelated outbound connections was
the easiest. Now this does not protect me really from root exploits
since it is obvious they can get in the door, but for now I am checking
my binaries regularly as well as keeping my kernel up to date.
Occasionally I see denied outbound connections to strange port numbers
in my logs, most of them look like they are from evil scripts trying to
call home.
It would be really nice if iptables could tell me what user it was that
was trying to open the connection (I know I can setup a rule to match a
user, but wouldn't this create a lot of overhead to have one rule for
each user on my system? (I have a lot)).
Here is the guide I used for creating my firewall rules, I also read up
a bit on netfilter/iptables and tested it on a local system before
installing it on my servers.
http://www.sun.com/blueprints/1103/817-4403.pdf
> also, surely the most important set is next - which is
>
> 3. make sure only required services are accepting incoming requests.
>
> so, use something like nmap to test for open ports on a remote machine.
> make sure only required services are running.
>
> 4. enhance authentication
>
> maybe set up ssh access by authorised keys only - but again this has a
> problem when i need to log in to the server from a putty session on a PC in
> an internet cafe .
>
> certainly check the strength of the existing passwords.
>
> 5. ongoing security
>
> sign up to email lists to monitor security issues RE the services used.
>
> get server to run chkrootkit regularly and email results.
>
> run snort to check for attacks.
>
> get script to run and check status of server every day.
>
>
> any comments gratefully received,
>
> kevin
>
>
--
Vittorio R Tracy <vrt@fastmetrics.com>
Fastmetrics LLC.
Reply to: