Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -1 articles for you...
102
security advisorynetwork threatClamAVClamAV: Critical Bugs Patched for RCE and Info Leakage Threats
Recently, researchers found two critical flaws in the ClamAV open-source antivirus engine . These network security issues lead to Remote Code Execution (RCE) and remote information leakage for susceptible devices. ClamAV has now released patch versions addressing these dangerous cybersecurity vulnerabilities. This article will discuss the flaw’s discovery, its impact, and how to protect against this network security threat. . The Discovery & The Impact An HFS+ file parser ( CVE-2023-20032 ) was discovered to have an RCE vulnerability. This network security threat received a CVSS score of 9.8 out of 10 in the National Vulnerability Database and affects 1.0.0, 0.105.1, 0.103.7, and earlier versions of all three. Cisco Talos states, “This vulnerability is due to a missing buffer size check that may result in a heap buffer overflow write. An attacker could exploit this vulnerability by submitting a crafted HFS+ partition file to be scanned by ClamAV on an affected device.” Attackers could run arbitrary code with the same privileges as that of the ClamAV scanning process due to these exploits in cybersecurity, crashing the system and formulating Denial-of-Service (DoS) attacks in network security. The second network security threat is a vulnerability to remote information leakage in the DMG file parser ( CVE-2023-20052 ). The bug affects 1.0.0, 0.105.1, 0.103.7, and earlier versions. Cisco Talos notes, “This vulnerability is due to enabling XML entity substitution that may result in XML external entity injection. An attacker could exploit this vulnerability by submitting a crafted DMG file to be scanned by ClamAV on an affected device." What Can I Do to Protect Against These Bugs? ClamAV has released security patching versions 0.103.8, 0.105.2, and 1.0.1 that can mitigate these network security issues. Fedora has also created a security advisory for these cybersecurity vulnerabilities . ClamAV states, “All users should update as soon as possible to patch for two remote codeexecution vulnerabilities that we recently discovered and patched.” The release files are available for download on ClamAV.net , the Github Release page , and through Docker Hub . We urge all users to update now to protect against attacks in network security leading to compromise and prevent unauthorized disclosure of sensitive information. Be sure to register as a LinuxSecurity user , then subscribe to our Linux Advisory Watch newsletter and customize your advisories for the distro(s) you use to stay up-to-date on the latest, most significant problems impacting your systems' data and network security. . The Discovery & The Impact An HFS+ file parser (CVE-2023-20032) was discovered to have an RCE vulner. recently, researchers, found, critical, flaws, clamav, open-source, antivirus, engine, these. . Brittany Day
Feb 19, 2023
•
102
security advisorydata protectioninformation leakageSecuring Apache Web Server Against Information Leakage Risks
Information leakage is a serious threat to the security of a Linux server, and can result in a host of severe consequences including significant downtime and the compromise of sensitive data. Luckily, server administrators can mitigate the risk of information leakage through a series of configuration changes. . This article will provide some background on information leakage and the types of attacks it can lead to. We will then explain how you can configure your Linux web server to protect against information leakage. Much of this information that can be applied to improve the security of any Linux server; however, we will focus predominantly on securing an Apache web server in this article. What Is Information Leakage and Why Is It A Security Threat? Information leakage describes the actions of revealing information to an unauthorized party, and can be the result of either intentional actions such as those taken by malicious insiders, or unintentional actions such as employee negligence. Information leakage can have severe consequences for the parties affected, including data compromise, lost productivity and reputation damage. Leaving your web server vulnerable to information leakage can result in an array of serious attacks, including Cross-Site Tracing attacks (XST) attacks and Man-in-the-Middle (MITM) attacks. XST involves the use of Cross-site Scripting (XSS) and the TRACE or TRACK HTTP methods. XST attacks can be used to steal cookie information or sensitive credentials and can be mitigated by disabling the TRACE HTTP request on an Apache web server (covered in more detail below). In a MITM attack, a malicious hacker secretly relays - and potentially alters - the communications between two parties without their knowledge. MITM attacks are commonly used to gain access to sensitive data, and can be mitigated by configuring an Apache web server to reject all SSL v2/v3 connection requests (also covered in more detail below). How To Configure an Apache Web Server to Prevent InformationLeakage When securing a Linux server, the first configuration changes that should be made are to disable any potential sources of information leakage such as broadcast of the server version banner, failure to disable the directory browsing list, the ETag header, the Trace HTTP request or SSL v2/v3 and failure to review and disable optional running services that could potentially be exploited by a malicious actor. All Linux distributions have poor default configurations in regards to preventing information leakage - making it essential that the correct manual configurations are made to protect sensitive data. Let’s take a closer look at these configuration changes and how they can be made. Remove Server Version Banner Apache web server administrators should begin by ensuring that the server version banner has been removed. It is critical not to expose the version of the web server you are using, as this information can be exploited by malicious hackers. By default, Apache web servers are configured to show Apache Version and OS type. ServerSignature permits the addition of a footer line revealing the server name and version number under server-generated documents such as error messages, mod_proxy ftp directory listings and mod_info output plus, among others. ServerTokens determines if the server response header field that is sent back to clients contains a description of the server OS-type and information pertaining to enabled Apache modules. To avoid broadcasting this private information, edit your httpd.conf config file to add or modify the following directives if they don’t already exist: ServerTokens Prod ServerSignature Off Save and exit, then restart Apache. If you are running PHP, you will also want to hide your PHP version number. Learn how this can be done in this brief yet informative TecMint tutorial . Disable Directory Browsing List It is critical that Apache server administrators disable directory browser listing, which is enabled by default in Apache, toprevent visitors from being able to see the files and folders listed under root or subdirectory. When directory browser listing is disabled on a server, a forbidden error message will be displayed when a user attempts to access this information. To disable directory browser listing, add -Indexes to the Options directive for the required directory. Edit the config file corresponding with the virtual domain you’re configuring and add “Options -Indexes” to the Directory section corresponding with the directory for which you wish to disable indexes. Options -Indexes Be sure to restart Apache after you’ve saved the file. If you don't have administrator access to the system or would like to easily manage directory listing on a per-directory basis, you can use the above Options -Indexes directive in the htaccess file corresponding with the directory as well. Disable the ETag Header It is critical that the ETag header - which is enabled by default in Apache - is disabled, as this header allows remote attackers to obtain sensitive information such as inode number, multipart MIME boundary and child processes. While this is not among the most serious information disclosure vulnerabilities in Apache, it is worth disabling the ETag header regardless - especially given how simple it is to do! To mitigate the risk of potential exploits of this vulnerability, edit your Apache config to add the following: Header unset ETag FileETag None Restart Apache for the change to take effect. Disable TRACE HTTP Request Failure to disable the TRACE HTTP request, which is enabled by default in an Apache web server, can result in a Cross-Site Tracing attack and provide malicious hackers with access to cookie information. To disable the TRACE request so all such requests are blocked with 405 Method Not Allowed, edit your Apache config to add the following: TraceEnable off Restart Apache for the change to take effect. Disable SSL v2 & v3 SSL v2 and v3 are obsoleteversions of the SSL protocol that are ridden with security flaws and have since been superseded with the more secure Transport Layer Security (TLS) protocol. SSL v2 and v3 should be disabled to prevent Man-in-the-Middle attacks or the decryption of data between the affected service and clients. Disabling SSL v2 and v3 is also essential to PCI compliance and penetration testing. To configure an Apache web server to accept only the latest versions of TLS and reject all SSL v2/v3 connection requests, edit the ssl.conf file in your Apache config directory to add the following: SSLProtocol all -SSLv2 -SSLv3 Once you have saved your config and restarted Apache, you should verify your SSL configuration to ensure that your certificate parameters are as expected, and identify any potential issues before they are exploited. Learn about ten online tools that you can use to test your SSL configuration in this GeekFlare article . Review Additional Running Services It is critical to review and disable any optional services running on the host that could result in potential security issues, such as CGI execution and symbolic links. Many administrators run a 'web server' and unknowingly are running a host of other services simultaneously, which all need to be carefully reviewed and secured. If other services are running on the same web server, the banner for these services should be edited to remove any broadcast of the version number or other non-required information that could potentially be leaked, leading to compromise. The CGI execution and symbolic links services can be disabled using the Options directive in the httpd.conf configuration file. To disable CGI script execution, symbolic links, and server-side includes for your web server root directory and its subdirectories, include the following in your httpd.conf file: Options -ExecCGI -FollowSymLinks -Includes Be sure to restart Apache after you’ve saved the file. The Bottom Line With a growing number of attackstargeting Linux servers - the majority of which can be attributed to misconfigurations and poor administration, server security and responsible administration are more crucial than ever. In general, Linux is a very secure OS due to the transparency of its source code and the constant scrutiny that it undergoes by the “many eyes” of the vibrant, global open-source community. However, all Linux distros have poor default configurations when it comes to preventing information leakage - making it imperative that the proper manual configuration changes are made to protect against this serious threat, which can result in data tampering or theft. Preventing information leakage is of utmost importance and, when securing a Linux web server, the first configuration changes that should be made are to disable any potential sources of data leakage including the server version banner, the directory browsing list, the ETag header, the TRACE HTTP request, SSL v2/v3 and any unnecessary running services that could potentially lead to compromise. Have additional questions about how to secure your Linux servers against information leakage? Leave a comment below and one of our security experts would be happy to help! Stay tuned for future articles in this series which will cover topics including firewall considerations, permissions, PHP security, monitoring logs and ways to verify the security of a Linux web server. Have another topic you would like us to cover? Don’t be shy - let us know! . Discover strategies to prevent data exposure and fortify your Apache web server against significant risks.. Information Leakage, Apache Configuration, Server Security, Linux Web Server. . Brittany Day
Oct 12, 2020
•
102
system hardeningweb serverfirewall configurationSafeguarding Your Apache Web Server: Preventing Data Leaks and Errors
Over the next couple of weeks and months, LinuxSecurity editors and contributors will be writing a series on Linux Web Server Security. This week, we’re summarizing the risks Linux administrators face when trying to secure their systems, as well as outlining the first steps that should be taken toward ensuring that your systems are secure. This series will dive deeper into topics including preventing information leakage, firewall considerations, protecting file and directory permissions, securely running PHP applications, monitoring logs and how to verify the security of a Linux server. . Much of this information originated from the Linux Security HOWTO, a comprehensive resource written by LinuxSecurity.com Founder Dave Wreski more than twenty years ago to offer the Linux community a place to start with securing their systems before much of the existing open source security documentation was created, now updated to reflect modern security principles and practices. With the growing prevalence of Linux web servers globally, security is often touted as a strength of the platform for such a purpose. Due to the transparency of Linux source code, vulnerabilities are identified and fixed very rapidly and, as a result, Linux generally fares better than alternative proprietary OSes when it comes to security . However, a Linux-based web server is only as secure as its configuration, and the unfortunate reality is that often many Linux servers are quite vulnerable to compromise due to misconfigurations and poor administration. While specific configurations vary wildly due to factors such as environment and specific use cases, there are various universal steps to securing a Linux web server that can be taken to ensure basic security considerations are in place. Misconfigured Servers Carry Great Risk A selection of serious security risks are associated with the compromise of a web server, including the use of the hijacked server as a source of malware or the creation of a spam-sending relay, among othermalicious activities. Even if the operating system and packages are fully patched with security updates, a misconfigured server can still be compromised. Server Security: A Fundamental, And Often Neglected, Aspect of System Hardening Many aspects of a system’s overall security are contingent upon server security. For instance, securing web applications begins with configuring the server itself strictly with security in mind. It is common for server owners to deploy various layers of security to react in real-time to hacking attempts and threats for HTTP requests. However, securing the server as a whole and any running services to the highest level is the first fundamental step to mitigating the risk of being hacked or compromised. With the abundance of malware being installed into web applications hosted on Linux-based servers, it is clear that many servers are configured with little or no security in mind. For users of personal blogs, a compromise is often both an embarrassment and an inconvenience. However, for small and large businesses alike, having your company’s site or blog serving up malware due to a compromise often results in a significant loss of business and creates a very poor reflection of your company's IT services on the public, as well as on potential clients. As you can see, server security is of utmost importance - and should be a top priority for all server owners and system administrators. That being said, let’s take a look at some risks administrators face, considerations that should be made and steps that can be taken improve the security of your Linux web servers. This series will provide general information that can be applied to improve the security of any Linux server, but will focus predominantly on securing an Apache web server. Information Leakage Information leakage, or the actions of revealing information to an unauthorized party, carries severe consequences for both businesses and individuals including data compromise, reputation damage and financialloss. Information leakage can be the result of either intentional actions such as those taken by malicious insiders, or unintentional actions such as employee negligence. Luckily, there are various measures that system administrators can take to secure web servers against this serious threat. The first and relatively trivial configuration changes that should be made to secure a Linux server are to disable any potential sources of information leakage. All Linux distributions have poor default configurations in regards to preventing information leakage. As a result, it is imperative that the correct manual configurations are made in order to protect sensitive data. Potential sources of information leakage that Apache web server administrators should disable include the directory browsing listing, the ETag header, the Trace HTTP request and SSL v2/v3. Administrators should also ensure that the server version banner has been removed. Let’s take a closer look at these configurations and how they can be made. Remove Server Version Banner Removing the server version banner is one of the first configurations that Apache server administrators should consider to prevent information leakage. It is critical not to expose what web server version you are using, as this information can be exploited by malicious hackers. The Apache default configuration shows Apache Version and OS type. To hide this information from unauthorized parties. Edit your httpd.conf config file to add or modify the following directives if they don’t already exist. ServerTokens Prod ServerSignature Off Save and exit, then restart apache. Disable Directory Browser Listing It is critical that Apache server administrators disable directory browser listing to prevent visitors from being able to see the files and folders listed under root or subdirectory. When directory browser listing is disabled on a server, a forbidden error message will be displayed when a user attempts to access this information. To disabledirectory browser listing, add -Indexes to the Options directive for the required directory. Edit the config file corresponding with the virtual domain you’re configuring and add “Options -Indexes” to the Directory section corresponding with the directory for which you wish to disable indexes. Options -Indexes Be sure to restart apache after you’ve saved the file. If you don't have administrator access to the system or just want to easily manage directory listing on a per-directory basis, you can use the above Options -Indexes directive in the htaccess file corresponding with the directory, too. Disable the ETag Header The ETag header should always be disabled, as it allows remote attackers to obtain sensitive information such as inode number, multipart MIME boundary and child processes. To mitigate the risk of potential exploits associated with the compromise of this sensitive information, edit your apache config and add the following Header unset ETag FileETag None Restart apache for the change to take effect. Disable Trace HTTP Request The Trace HTTP method is enabled by default in an Apache web server. Failing to disable this HTTP request can provide malicious hackers with access to cookie information, and can also result in a Cross Site Tracing attack. To disable the TRACE request so all such requests are blocked with 405 Method Not Allowed, edit your apache config and add the following: TraceEnable off Restart apache for the change to take effect. Disable SSL v2 & v3 SSL v2 and v3 are ridden with security flaws, and must be disabled to prevent Man-in-the-Middle attacks which can result in data tampering or theft. Disabling SSL v2 and v3 is also essential to PCI compliance and penetration testing. To configure an Apache web server to accept only the latest versions of TLS and reject all SSL v2/v3 connection requests, edit the ssl.conf file in your apache config directory and add the following: SSLProtocol all -SSLv2 -SSLv3 Once you have saved your config and restarted, you should verify your SSL configuration . Review Additional Running Services It is critical to review and disable any services running on the host that are not required. Many administrators run a 'web server' and unknowingly are running a host of other services simultaneously, which all need to be carefully 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 could potentially be leaked. Firewall Considerations All Linux servers should make use of the built-in software firewall which, in most cases, is iptables. Iptables makes a very easy command line interface for managing the firewall - there is no need to write intricate iptables scripts. Debian and Ubuntu incorporate an application called ufw which is a command line interface for iptables. Using ufw, simple commands can open or close ports, without the user being an iptables wizard. Regardless of whether or not additional firewalls are in place, the host internal software firewall should always be enabled. Only allowed services should be able to communicate in and out of specified ports and network interfaces. Consider if a company's perimeter firewall is compromised. In this case, the only layer of defense would be the software firewall on the host. Similarly, if the host is compromised through a web application, restricting access to network traffic of that host will provide some protection against island hopping or other intrusions. ModSecurity is an excellent free and open-source web application firewall that can be used with Apache. You can download ModSecurity download . Installation, configuration and troubleshooting documentation is available on Github . Multiple other great free and open-source firewalls, which you can learn about in this TechRadar.pro article , are also available to Linux users. Disabling ICMP– Not Required Administrators will often disable or filter ICMP requests, though doing this has no security benefits. In the case of something like DNS, ICMP requests are actually used in the DNS spec to query if a server is available before sending the DNS request. ICMP replies are extremely beneficial to web servers as well and can serve in troubleshooting a web server that appears to not be responding to HTTP requests. The threat of a ping flood is minimal today. Unless the attacker has considerably larger network bandwidth than the target, the flood attempt is going to cause little effect. Ping echo replies take very little CPU from the target to reply to - making the threat of a ping flood a bit like throwing many small pebbles in an attempt to take down a brick wall. This is why the majority of modern DoS attacks focus on HTTP requests instead of ICMP - driving up CPU and memory usage from the web server is far more effective to execute. In short, there is no reason to disable ICMP. Permissions File and directory permissions in Linux is often a confusing topic which leads to differing views, especially in the case of web directories and files. The worst advice, which should never be followed, is to change files or folders to 777. This allows anyone in the world to execute or write to your server. The best example of this is rogue WordPress plugins that malicious hackers push to servers via a simple HTTP POST command. If directory permissions are 777, anyone can read, write or execute anything in that directory - and anyone can post malicious code. Apart from the read/write/execute permissions, ownership permission also needs attention. The web directory on your server should not be owned by the Apache user. A regular user should be the owner of the web directory, and the group should be the Apache user. Even if the read/write/execute permissions are accurate, a rogue or runaway process or PHP application can then have full access to make changes to your entire web directory. Unfortunately,this ownership change can make the push button upgrades for Drupal and WordPress problematic. The binary and configuration directory permissions must also be protected. In Apache, the permission for binary and configuration is 755 by default, meaning that any user can access the conf and bin folder and view the configuration of the server. Administrators should consider disallowing access to the main config files by restricting ownership and file permissions on these files. PHP Applications Running PHP on a Linux server is required for many popular applications such as Drupal and WordPress, among others. New vulnerabilities are being found in not only poorly written PHP code, but in the language itself, at an alarming rate. Since PHP is often paired with MySQL, a PHP compromise can mean a compromise of the accompanying MySQL database for the web server. Hence, it is critical to be on top of any PHP software or plugin updates. Do not install or use PHP code from unknown sources. For blogging software, minimize the number of plugins or extensions in use. If a plugin or add-on is not activated or in use for the blog or website, remove the unused files from the server. Ensure that 404 pages for the server do not provide any extraneous information and do not interpret what was put in the URL bar. Visit a random 404 page on the web server as a test. The resulting 404 page should only provide a generic 'Sorry, that page was not found', and should not try to interpret or relay results that the user placed in the URL bar. 404 pages that allow user input manipulation are an entry point for attackers to craft XSS and other malicious attempts. Learn about other PHP security best practices in this NixCraft tutorial. Monitoring Logs Logs are a critical part of monitoring the security of a web server. Many Linux distributions offer tools for automating log monitoring. The Logwatch application sends a daily email report of all of the logs on the server to inform on varying log entries such as thenumber of emails sent, potential web attackers, SSH attempts and IPs causing errors in logs. In a large corporate environment it is common to send logwatch emails along with other mail directed to the root user (cron errors and other system messages) to a single company email list. Administrators in the company then subscribe to that single email list to stay informed of any alarming notifications in various servers' logs for the company. Learn how to install and use Logwatch in this TechRepublic tutorial . Conclusion Linux is a popular operating system for web servers and web hosting, and is unfortunately also becoming an increasingly popular target for compromise - mainly due to misconfigurations and poor administration. Strict security considerations are needed to ensure that attacks and attempts to insert malicious code are avoided. Taking care to reduce information leakage, restrict permissions, keep PHP and other applications updated, and monitor all server logs will help Linux server administrators stay on top of potential attack vectors and avoid compromise. Got a tip for securing a Linux web server that hasn’t been addressed in this article? Please let us know in the Comments section below and we’ll include it here. Next week we will take a deeper dive into preventing information leakage. . Much of this information originated from the Linux Security HOWTO, a comprehensive resource written . couple, weeks, months, linuxsecurity, editors, contributors, writing. . Brittany Day
Sep 21, 2020
•
102
web server securityserver configurationinformation leakageSecuring Linux Web Server Configuration: Malware Risks and Best Practices
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.
Apr 28, 2015
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More