Many of the kernel bugs present in the Linux system are potential security flaws. Hackers use the vulnerabilities inherent in the Linux kernel to gain privilege escalation or to create denial-of-service attack vectors. . One of the main issues that developers are concerned about is the fact that some of the most severe vulnerabilities can be exploited completely remotely, and unlike phishing scams that rely on user action, these vulnerabilities are completely free-roaming. Of course, Linux remains one of the most secure operating systems available thanks to its founding principles of transparency and collaboration. Most vulnerabilities are spotted and resolved before they become an issue, but what are developers doing to protect against the inherent vulnerabilities that do threaten their Linux systems? Understanding the Most Common Linux Vulnerabilities Cybercriminals tend to exploit the same Linux vulnerabilities, so it's vital that developers have an awareness of those potential gaps in their kernel security. The majority of Linux security bugs are going to occur in the software development stage, and these are the source of the majority of cybercriminals’ success. Most commonly, hackers are looking for: Weak Configurations: During the software development stage, configurations need to be remodeled and adapted to suit the developer's intent. Using default configurations is a quick way to leave security gaps, leaving your software much more vulnerable to attacks. Those default configurations are great, but they may not be 100% suitable when it comes to security, and even the slightest change to those default configurations can have a ripple effect across the entire Linux security system. By not being aware of the right configurations, your systems may be exposed, and you won't even notice until harm is caused. Programming Issues: Server security is one of the top reasons that developers prefer to use Linux. Unfortunately, the concept of a 100% secure system is more difficult to achieve thanever, even though Linux distributions have a virtually 24/7 security update system that is continuously rolling out improvements and solving specific programming defects. Linux security is made weaker through improper resource management and the introduction of buffer flows as well, but luckily there are solutions. Access is the key, via limiting the number of people who can access the developing system. This can mitigate the fallout of any bad actors who have gained access to your programming. Server Vulnerabilities: In recent years, there has been an influx of new vulnerabilities that threaten Linux security. Developers need to know as much as they can about these vulnerabilities, such as Heartbleed, GHOST, and shellshock. These flaws can be extremely destructive because they dramatically affect server functionality. If left untreated, they can lead to security issues with network services and system library services, at the very least. How Can I Detect Linux Vulnerabilities? The goal of any developer is to ensure preventive security measures are the focus rather than curative ones. This can be extremely challenging on open-source code, which is why the focus of recent years has been on vulnerability detection. This guide to vulnerability management walks through the essentials of developer security and is a fact-based template for establishing a more secure system and network. Performing a vulnerability audit regularly should be part of the developer's workweek. While Linux vulnerabilities can't all be prevented, they can be reduced. That means more secure systems and less damage that is able to be caused by those with ill-intent. How Can I Reduce Linux Vulnerabilities? There are some straightforward ways to reduce the number of vulnerabilities in your Linux systems. The key things to remember are: Reduce Your Redundant Software: Software applications often come with their own set of vulnerabilities. When looking at your network, make sure that you only have the software installed that you really need . Of course, the more software applications that you have installed, the more vulnerable your system will be and the harder it will be to identify the source of an attack. Auditing Code: This best practice is becoming much more common as Linux experts have realized just how transformative it can be in terms of security. Code auditors need to be deployed if you are looking to minimize vulnerabilities. Learn about Linux: The more that you know about Linux and how it works, the easier it will be to reduce vulnerabilities. Linux already has many built-in security measures in place. The more that you know about them, the easier it is to ensure that all of your decisions are based on taking advantage of these security measures. How Can I Treat Linux Vulnerabilities? Hackers and developers alike are always going to need to be on the alert for new vulnerabilities. When a new vulnerability is spotted, developers know that they have to upgrade their software if they don't want to risk system compromise. Automatic software updates are fantastic for treating new vulnerabilities, even if they can often lead to full system updates. These updates are the key to ensuring that your systems are as secure as possible. Linux servers are about as secure as a system can be - but they aren't invulnerable. As cyber threats continue to increase, developers are having to consider vulnerability management and the advantages of Open Source more than ever before. The more that developers can learn about the detection, prevention, and treatment of vulnerabilities, the more secure their work will be. . Discover strategies for developers to tackle Linux security vulnerabilities and enhance system defense measures.. Linux Kernel Management, Securing Open Source, Vulnerability Detection, Linux System Audits. . Brittany Day
With the significant prevalence of Linux web servers globally, security is often touted as a strength of the platform for such a purpose. However, a Linux based web server is only as secure as its configuration and very often many are quite vulnerable to compromise. While specific configurations vary wildly due to environments or specific use, there are various general steps that can be taken to insure basic security considerations are in place. . Many risks are possible from a compromise including using the web server into a source of malware, creating a spam-sending relay, a web or TCP proxy, or other malicious activity. The operating system and packages can be fully patched with security updates and the server can still be compromised based purely on a poor security configuration. Security of web applications first begins with configuring the server itself with strict security in mind. Many will often deploy various layers such as a WAF, IDS, or Mod Security to react in real time to various hacking and threats for HTTP requests. However, securing the entire server and any running services with a high level of security in mind is the first fundamental step to avoid the risk of being hacked or compromised. With the abundance of malware being installed into web applications hosted on Linux based servers (such as the many recent timthumb.php WordPress plugin vulnerabilities), it is clear many servers are configured with little or no security in mind. For users of personal blogs, a compromise is often an embarrassment and inconvenience. However for small and large businesses, having a site or blog of your company serving up malware from a compromise is a loss of business and creates a very poor reflection of your company's IT services on the public as well as potential clients. Web servers that are compromised and serving malware often are then very quickly flagged in Google's Safe Browsing listing which most all major browsers subscribe. When flagged, often 24 hours or more are needed to clear thelisting as the Safe Browsing check only scans sites once a day for changes. Do not let this happen to your company's website! Information Leakage The first and relatively trivial configuration changes that should be made are to disable any information leakage from your server. All Linux distributions have poor default configurations in regards to information leakage for Apache and other services. While most dismiss this as not a concern, the less information you broadcast to a hacker, the better. Every request to your Apache web server can reply back with information such as the exact OpenSSL version, PHP version, and many other items. While some applications like OpenSSH require the broadcasting of their version in the banner for operation, there is no functional reason for Apache to broadcast its version number to the world, and likewise nor any other related Apache modules. Fetching the HTTP headers with curl from as an example can provide the following information publicly: $ curl -I HTTP/1.1 200 OK Date: Sun, 25 Mar 2012 02:11:54 GMT Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Python/2.5.2 Last-Modified: Mon, 15 Dec 2008 03:07:18 GMT ETag: "c622-f16-45e0d23f9c580" Accept-Ranges: bytes Content-Length: 3862 Content-Type: text/html The server signature is also displayed on any 404 pages: The following changes can be made to eliminate both Apache and PHP from disclosing their version information. Apache configurations: ServerTokens Prod ServerSignature Off TraceEnable Off Header unset ETag FileETag None PHP configurations to be made in php.ini: expose_php = Off display_errors = Off track_errors = Off html_errors = Off After making those changes and restarting Apache, the same curl command to fetch HTTP headers now provides minimal information: $ curl -I HTTP/1.1 200 OK Date: Sun, 25 Mar 2012 02:13:01 GMT Server: Apache Last-Modified: Sat, 24 Jul 2010 18:21:28 GMT Accept-Ranges: bytes Content-Length: 15 Vary: Accept-Encoding Content-Type: text/html Review Additional Running Services It is critical to review and disable any services running on the host that are not required. Many often run a 'web server' and unknowingly are running many other various services which all need to be reviewed and secured. If other services are running on the same web server, the banner for those services should be edited to remove any broadcast of the version number or other non-required information that is leak. Other services one might run might include SMTP (Postfix banner, or Sendmail banner), SSH (ssh suffix banner), or even DNS (BIND also has a banner!). While these services may be completely separate from any web application or web server, be aware that they too broadcast version information and can often provide additional information to a potential hacker. Nmap can be used to quickly scan open services running on the host and also report back the banner being advertised by each service. The nmap command to use is: $ sudo nmap -sV [target] Below is a particularly exposing Linux server with many services open to the internet, all broadcasting version information in the banners: $ sudo nmap -sV Password: Starting Nmap 5.51 ( https://nmap.org/ ) at 2012-03-24 21:46 EDT Nmap scan report for (192.168.1.120) Host is up (0.051s latency). rDNS record for 192.168.1.120: test. Not shown: 986 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.1p1 Debian 5 (protocol 2.0) 25/tcp open smtp Postfix smtpd 53/tcp open domain ISC BIND 9.6-ESV-R4 80/tcp open http Apache httpd 2.2.9 ((Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Pyth...) 110/tcp open ssh OpenSSH 5.1p1 Debian 5 (protocol 2.0) 111/tcp open rpcbind 135/tcp filtered msrpc 139/tcp filtered netbios-ssn 443/tcp open ssl/http Apache httpd2.2.9 ((Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Pyth...) 445/tcp open netbios-ssn Samba smbd 3.X (workgroup: HOME) 465/tcp open ssl/smtp Postfix smtpd 587/tcp open smtp Postfix smtpd 1720/tcp filtered H.323/Q.931 4444/tcp filtered krb524 Service Info: Host: ; OS: Linux Below are a few common services that could also be running on your web host which can have the banner configured to reveal a minimal amount of information: Disable SSH banner suffix Debian and Ubuntu allow users to disable the Debian version suffix of the SSH banner by setting the following in /etc/ssh/sshd_config: DebianBanner no Disable Postfix banner The banner for Postfix is easily configurable in /etc/postfix/main.cf by editing the following line as desired: smtpd_banner = Hello! Hopefully samba is not open to the internet, but the samba server banner is configurable in /etc/samba/smb.conf server string = Samba Server Version %v Remove Version from BIND banner Use this configuration in your named.conf to disable the broadcast of the version: options { version "Not disclosed"; } Firewall Considerations All Linux servers should make use of the built-in software firewall which in most cases is iptables.
Get the latest Linux and open source security news straight to your inbox.