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?
CD-ROM?).
> 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: