[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hardening checkpoints

On Thu, Dec 15, 2005 at 12:27:01PM +0000, kevin bailey wrote:
> now i've generally relied on debian issuing security patches but i
> thought i should be more proactive RE security.

This is very important, as you're now aware. The most secure OS in
the world is only as secure as the admin makes it.

> here's my proposed checklist to carry out for securing a domain
> server -

This question comes up on email lists all the time; a quick google
search will complement your list below.

> 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.

Consider putting the tripwire binary somewhere read-only (NFS?

> 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.

Firewalls on the perimeter /and/ the host itself are very useful.
Your network should be protected on its edge already, but I strongly
suggest taking the time to design and implement a useful firewall on
the servers you run as well. Even if you're network firewall is
perfect, you (likely) can't fully trust other hosts on the inside.

> BTW - FTP *has* to be available - many of the users only know how
> to use FTP.

This is a frequently asked question -- iptables can be used to
firewall machines serving 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.

This is a practice which applies (or should apply) to servers and
business networks as well.

> 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.

See the other post in this thread for a simple way to deal with
this. There are more elegant ways, but you get the idea.

> 3. make sure only required services are accepting incoming
> requests.

> so, use something like nmap to test for open ports on a remote
> machine. 

You may also want to audit the services you choose to run using
Nessus or by analyzing the code yourself (assuming you can get
access to the code). I also use lsof(8) to find applications
listening on the network when I'm on the host, or nc(1) to perform a
simple remote scan of the host when nmap isn't available.

> make sure only required services are running.

And that running services are patched, just as you keep track of
patches for the OS.

> 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 .

You could keep your key on a USB fob, which would allow you to
authenticate pretty much everywhere. Certainly, try to avoid
allowing both password- and key-based authentication.

> certainly check the strength of the existing passwords.

And check new passwords as users are added to the system.

> 5. ongoing security

> sign up to email lists to monitor security issues RE the services used.

This list is a good start ; ).

> get script to run and check status of server every day.

Consider using a monitoring suite like Nagios, especially if you
have a group of servers to monitor.


o--------------------------{ Will Maier }--------------------------o
| jabber:..wcmaier@jabber.ccc.de | email:..........wcmaier@ml1.net |
| \.........wcmaier@cae.wisc.edu | \..........wcmaier@cae.wisc.edu |
*---[ Debian: The Universal Operating System (www.debian.org) ]----*

Reply to: