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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
