Re: hardening checkpoints
Will Maier wrote:
> 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.
the machine is in a serverfarm - but after the advice given RE FTP/SFTP or
forcing FTP to use the ports 21 and 20 - ftp-data - i should be able to
implement a firewall.
>
>> 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.
>
thanks for your points,
kev
Reply to: