Greetings fellow Linux security enthusiasts, Interested in becoming a LinuxSecurity contributor, but need an article topic idea and some guidance to help you get started? . We’re looking for contributors with an understanding of Linux firewalls who can help provide insight into how firewalls can be implemented and configured to improve the security of a Linux system. If you would like to contribute an article on this topic, we suggest that you explore: The types of attacks that firewalls can and cannot protect against Limitations of firewalls, and the the importance of taking a defense-in-depth approach to securing a Linux system Tips and advice for using firewalls to secure a Linux system How using a web application firewall (WAF) can improve security Best practices for securely configuring and maintaining firewalls The LinuxSecurity.com contributor program provides you with the opportunity to share your knowledge and experience with a community of like-minded people who share your passion for Linux and security, receive comments from community members, and engage in meaningful discussions about the topics that interest you most. To get started, register and customize your User Profile . If you are new to LinuxSecurity.com, I would like to extend a warm welcome to the LinuxSecurity community! Yours in Open Source, Brittany Day Be Aware of Zero Trust Challenges Implementing Zero Trust recommendations could potentially lead to a decrease in work productivity during encryption and increased costs associated with ongoing administration. . Participate in our contributor initiative to provide knowledge on Linux security measures and elevate system protection with your experience.. Linux Firewalls, Security Configuration, Open Source Community. . 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.