Manage Learn to apply best practices and optimize your operations.

Linux security best practices for Linux server systems

Linux servers are used throughout many enterprises, and their security posture shouldn't be overlooked. In this tip, King Ables discusses risk assessment pointers for Linux server systems.

Maintaining a secure enterprise-computing environment requires policies and procedures designed to minimize unauthorized access to systems and data. To protect Linux-based computing assets from these threats, like many other security-centric processes, you must know what you want to protect and how someone might attempt to gain access. Successful security management is a mindset. In other words, think like the bad guy.

In this tip, we'll discuss risk assessment pointers for Linux-based server systems.

The first step in securing your Linux server systems is to correctly assess the risks they face. Only then can an enterprise deploy an effective set of countermeasures to prevent, detect and, if necessary, properly react to any breach that may occur.

For starters, identify the Linux assets in need of protection. Assets may include hardware, software, data or an operational service like email or website hosting. Each asset has value, either a monetary value or the potential for future revenue.

Next, identify the potential threats to each asset. Threats may originate from inside or outside the organization. Some internal threats are merely accidental, but some could be malicious.

A threat to an asset depends on the motive for the attack and how the attacker might gain access to the asset. The motive may be the sheer challenge, to harm the asset owner, or profit. The attacker may want access to your data or merely to deny access to legitimate users. Each threat has a certain probability of exploitation, often related to the value of the asset. While these are difficult to know and vary widely among organizations, using a risk management framework to assign a probability to each identified threat will help you prioritize the actions required to mitigate it.

While it is not possible to list all potential threat vectors, a summary of the most common will give you a place to start your risk assessment.

The most problematic threat vector is the user. In spite of all protection mechanisms, people can still be fooled or blackmailed into behaving improperly. User awareness, education and access privileges are important parts of any Linux risk mitigation.

Passwords often represent the most common soft spot in the security of any computing environment. To identify insecure login passwords, run a password validation checker, such as John the Ripper. Application and database passwords should also be checked for "crackability" or changed to meet such requirements. Also, identify access granted to Linux servers unnecessarily. For example, if the password file (/etc/passwd) is being remotely distributed (via rcp/rcopy or NIS), users may have login access to servers they never use, creating potential threat vectors for no benefit.

Another major threat vector is the network. Any user that can access your local network (physically or wirelessly) can then attempt to connect to any other asset on the network. All Linux systems run programs that open network ports and wait for queries from the network. Each of these represents a threat vector, either via fraudulent authentication or possibly because of a software flaw that might allow access by mistake. Use netstat(8) to find all open ports on a system.

Scan other machines on the network for open ports using Nmap(1). Each open port represents a threat vector that should either be closed or monitored for illegitimate access. Don't overlook any legacy dial-in access points. The firewall is the boundary between a trusted network and an untrusted network (e. g., the Internet). Your firewall should be configured to only pass data on known and required ports. Every port the firewall passes data through is a threat vector.

You should also examine log data to correlate access with need in addition to normal monitoring. The lastlog(8) command displays user login information. A variety of log messages can be found in /var/log/messages. Many applications and databases also provide logging mechanisms to track user access. Examining these logs will give you a view of who currently uses and (presumably) needs access to specific resources.

No software of any complexity is flawless, but flaws aren't generally known until they manifest themselves in the form of unwanted behavior. The typical bug only corrupts data or causes a crash, but some may cause unintended consequences, like allowing unauthorized access. This would obviously represent a major compromise. Attackers are in a constant search for these types of bugs and vendors work hard to fix them quickly and provide software patches when they are found. All you can do is make sure your operating system and application software is checked and updated regularly.

The process for checking for updating software on Linux servers depends on the application or version of Linux. For example, Ubuntu Linux provides an update manager (found via System > Administration > Software Source), which can be configured to check for updates every day. The more often you check for updates, the smaller your window of vulnerability. Also be wary of freeware or software from unverified sources or authors.

The most important software to monitor and keep updated is externally facing software, such as Web servers and network applications (e. g., VPN or SSH). Web server software is regularly probed for both bad configurations and bugs. Web applications can be given mischievous input that might be used incorrectly. Most Web application languages like Perl, Python, Ruby or PHP have facilities or available add-ons to sanitize input data and disable user-entered code such as SQL or JavaScript. Any data your Web servers or any other externally facing applications accept from a user represents a potential threat. Also, examine any log files produced by these programs to help identify legitimate and illegitimate access.

More on this topic

  • Learn how to perform a third-party risk assessment for compliance. 
  • See how to choose a general security risk assessment. 
  • Learn a basic framework for a cybersecurity risk assessment.

About the author:
King Ables holds BA and MSc degrees in computer science and has worked in customer support, software development, systems and network administration, and user education. He has written numerous technical articles for on-line and print journals and is author or co-author of three books on UNIX and Linux.

This was last published in January 2011

Dig Deeper on Alternative operating system security