Securing UNIX and Linux Systems
The different vendors of UNIX and Linux make it difficult to write one comprehensive, step by step, guide for securing your UNIX/Linux system. We can, however, generalize some basic concepts about securing the environment that you can customize to your specific installation to produce a more secure operating system. Following these guidelines will help reduce your chance of compromise, make the forensics easier if you do get compromised, and hopefully get your system back online faster.
Step 1: Pick a good, supported operating system.
IS&T currently supports:
- BU Linux (CentOS) on x86
- MacOS X
In addition, we have a lot of experience with IBM’s AIX, and SGI’s IRIX operating systems that we can share with you. While you are free to pick the operating system of your choice that best fits your needs, sticking with an operating system that IS&T can support will likely result in a more secure environment.
If you are picking from outside our list make sure that you select on operating system with a good track record for supplying security fixes in a timely fashion and join their mailing lists so you can be sure to know about critical patches when they are released.
Step 2: Stay Current with Patches
Nearly every system compromise is the result of an unpatched system. It is critical that you not only get all the current patches when you install your system but that you maintain the current patch level. This may mean scheduling routine and emergency downtime to install new versions of the kernel and other core components when the patches can’t be applied live. IS&T has provided tools for Solaris and BU Linux to help with automating patch installation.
Third party applications must also be kept secure. Numerous compromises start with an old version of a web server or web application, a forgotten SSH server or overlooked sendmail. When these components are part of the operating system the vendor may help you keep current, but when you start adding third party services to your host, you must make a procedure by which you ensure you stay current. This is increasingly true with web applications which have become a very popular target in the last few years.
Step 3: Use a Firewall
Nothing protects a service from compromise like a well configured firewall! Sure, your public web server has to be accept traffic from everything on the Internet, but do you really have users that need to SSH in from other continents? Some systems do, but for most systems it is totally unnecessary to SSH into the system if you’re not on campus (or connected to the VPN server from off-campus!)
Configuring a software firewall is easy and supported on most platforms. See our host-based firewalls section for more information.
Step 4: Use File Integrity Monitoring and Change Auditing
File Integrity Monitoring and Change Auditing is using software to detect changes to the contents or attributes of your filesystems. While files in home directories and temp space change constantly, many sections of your system are static such as /usr or behave in predictable ways like /var. By monitoring these sections of the filesystem, you can easily detect when something changes and determine if it was the work of a patch or systems administrator, or if it is indicative of a compromise. Tripwire is the most well known public offering, but Boston University has developed its own application known as Baseline, which is available to the BU community.
Step 5: Keep your clocks in sync!
If you use Kerberos authentication it is essential that you keep your system clock synchronized to our central servers, but even if you don’t it’s still a good idea. It is very easy to do — just configure your system’s network time protocol (ntp) subsystem to synchronize against the BU time servers:
If you use BU Linux or installed Solaris from our Jumsptart servers, NTP should have been properly configured for you by default.
Step 6: Copy your logs to our Central Log Server
Every time something interesting happens on your servers the system records it via the syslog facility to log file located (generally) in /var/log. When a system gets compromised, the first thing an intruder often does is erase those logs so you don’t see all the interesting things that lead up to the compromise.
You can thwart this by storing your logs on more than one system. Syslog provides a mechanism for forwarding the log data to another host, and IS&T runs a log server that will gladly accept a copy from you. We manage the logs, store them, back them up, and do all the necessary steps to make sure they are available if and when you need them. ’
Access to these logs is limited to the smallest set of administrators necessary for the log server and are used internally only to look for signs of compromise.
Setting up logging is easy to do, you only need to add one line to your syslog.conf and restarting syslog. See our complete instructions for more details on configuring remote logging.
Step 7: Follow our Global UID System
Want to make sure that the users logging in to your system are the users you think they are? Would you like a set of tools for determining when accounts on your system belong to users who have left the University? Would you like to be able to quickly set up accounts for new users that tie to the Kerberos authentication system so the users don’t need a local password?
We have a set of tools for you! The University’s User Administration (UserAdm) Tools and Global UID system provides a consistent, enterprise wide mapping between a person, a username, and a user id (uid, also known as an index id) and a set of tools for managing user accounts. UserAdm tools come with Solaris installs done through our Jumpstart server, and are incorporated into BU Linux as well.
Learn more about UserAdm Tools and The Global UID system.