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 advisorybackup strategiesransomwareStrengthening WordPress Security on Linux: Key Strategies & Threats
Did you know that 43.1% of websites on the Internet run on WordPress, according to W3Techs? Most WordPress websites run on Linux servers, which makes them prime targets for hackers—these servers experience approximately 90,000 attacks each minute! . As the owner or admin of a WordPress website, security should always be your top priority. You must monitor vulnerabilities within WordPress and third-party plugins for potential vulnerabilities and exploits that could result in website defacement, malware infections , data breaches, downtime, and other damaging repercussions. Luckily, there are proven strategies for securing your WordPress website, which we'll discuss here. Why Is WordPress Security Critically Important? Maintaining the security of a WordPress site is paramount, whether for personal or professional use. Unfortunately, many beginners overlook security when setting up new WordPress sites, which can prove costly in terms of reputation damage and lost business revenue. WordPress security risks are on the rise mainly because it's so popular, making it a prime target for cybercriminals. Many sites rely on a lot of third-party plugins for added features, but if these plugins aren't updated regularly or properly vetted, they can introduce vulnerabilities. Many WordPress sites are running outdated plugins that haven't been patched in years. Even when patches are available, not everyone updates right away. The enormous variety of themes and plugins, all created by different developers, adds to the difficulty in maintaining robust security across the entire WordPress ecosystem. Worse yet is the persistent ransomware threat to WordPress sites. Hackers can gain entry to vulnerable WordPress sites and lock up all files before demanding payment to unlock them. Worse yet, sometimes these attackers can’t even unlock these files themselves, leaving you with financial damage and a broken site! Below, we will examine some common WordPress vulnerabilities and security threats thatadmins face. What Are Common WordPress Vulnerabilities? To protect your WordPress site from persistent and emerging attacks, you must first understand some common vulnerabilities that hackers exploit. The following are the most prevalent and problematic WordPress vulnerabilities that may lurk within a typical WordPress installation. Outdated Software The most common vulnerability you'll find in WordPress websites is outdated software. This may include the use of an outdated WordPress version, as well as the use of outdated plugins inside the CMS. You need to update a WordPress installation and its plugins to ensure your site is secure from software flaws that newer versions don't have. Worse still, many of those flaws become common knowledge to hackers once developers issue a software update, placing outdated sites at even greater risk. Despite the risk, over 21% of known WordPress websites still use older, unsupported versions of the CMS. Vulnerable Plugins & Themes Vulnerable WordPress plugins can be a real headache and danger for users because they open the door to various security problems. Imagine these plugins like unlocked windows in your house—hackers can easily slip through to wreak havoc. They might install other dodgy plugins without you knowing or even mess with your website’s code to do harmful things like steal data. It's essential to monitor your plugins and ensure they're updated to the latest, safest versions. Otherwise, you're leaving your site vulnerable to an array of attacks. A recent critical vulnerability in the Hunk Companion plugin (tracked as CVE-2024-11972 ) demonstrates the risk of vulnerable WordPress plugins. This flaw, found by WPScan, is being actively exploited to install vulnerable plugins, creating significant security risks. This flaw, which affects all versions of Hunk Companion before 1.9.0 and has a CVSS score of 9.8, enables attackers to exploit Remote Code Execution (RCE), SQL Injection, Cross-Site Scripting (XSS) , and other maliciousactivities by installing or reactivating compromised or outdated plugins. Despite the availability of the fix, only 11.6% of users have upgraded, leaving approximately 8,800 sites still at risk. Another critical vulnerability was recently found in the popular WordPress security plugin Really Simple Securit, which has put over four million websites at risk. This bug allows attackers to log in as any user, including admins, without needing a password, thereby gaining full access to the site's permissions. The ease of exploitation and potential for severe consequences, such as malware injection, unauthorized content changes, and attacks on visitors, have earned this vulnerability a CVSS score of 9.8 out of 10. Just recently, some big security holes were found in the Woffice WordPress theme, used on thousands of websites. These issues could let bad actors take control of your site by registering with admin privileges or logging in as any user - including you! Weak Passwords Weak passwords are also a persistent vulnerability for WordPress websites. Hackers exploit weak passwords by targeting administrator accounts that can grant them complete control of a WordPress site. From there, nothing stops them from wreaking havoc and making whatever changes they wish. Shared Hosting Although shared hosting is popular for WordPress website owners, it has significant security vulnerabilities . If an attacker manages to execute a privilege escalation attack on the underlying server, they gain unfettered access to every WordPress website it hosts, too. Lack of Server Hardening Another common vulnerability present in WordPress websites is a lack of server hardening. The default installation of the WordPress CMS leaves various features turned on for the convenience of the site's owner. However, some of those features, such as the built-in file editor, the hotlinking function, PHP execution, and directory browsing, can be powerful weapons in the hands of an attacker. Using those functions, an attackercould execute malicious code, conduct a cross-site scripting attack , or enable a denial-of-service attack. Incorrect File Permissions Misconfigured file permissions are another common vulnerability found in WordPress websites. Generally speaking, the underlying wp-content and wp-admin folders that house most of a WordPress site's files should have restricted file permissions, including a restriction on who can write to them. However, plenty of novice admins change those default permissions while trying to troubleshoot configuration issues and fail to change them back, creating a major vulnerability. Essential WordPress Security Tips & Best Practices for Linux Users To combat the vulnerabilities discussed above, owners and operators of WordPress Websites must follow established WordPress security best practices to the letter. Here's what they are and some other tips on keeping WordPress sites secure. Keep Software & Plugins Updated The most important way to keep a WordPress website secure is to update the CMS to the latest version and enable auto-updates for the future. Plus, it's equally important to keep all installed plugins up to date, too. This means checking with plugin developers regularly or installing software that can check for new plugin versions and make the necessary updates for you. Keeping WordPress plugins up-to-date will protect against bugs like the previously mentioned CVE-2024-11772 and the recently identified critical flaw in the Really Simple Security WordPress plugin. Admins must monitor security advisories vigilantly and apply the latest WordPress software and plugin patches as soon as they are released. Be Wary of the Software Packages You Install WordPress users should be vigilant about the software packages they install, preferably sticking to direct downloads from verified sources. A recent sophisticated yearlong supply-chain attack reported by security firms Checkmarx and Datadog demonstrates the importance of this WordPress security best practice. The attack involves malicious actors distributing Trojanized versions of open-source software, specifically through the NPM repository and GitHub, to infect devices. One such package, @0xengine/xmlrpc, masquerades as a legitimate JavaScript implementation but contains a backdoor that activates malicious code, resulting in attackers stealing credentials and other sensitive information, including SSH private keys and AWS access keys. A second package, yawpp, indirectly installs this malware by requiring @0xengine/xmlrpc as a dependency. This malware campaign has resulted in approximately 390,000 stolen WordPress credentials and has persisted due to its subtlety and strategic updates. Install & Configure a Firewall Installing a firewall is another excellent way to keep a WordPress website secure. WordPress-specific firewall software can monitor incoming and outgoing data for signs of malicious activity. Plus, many can halt DDoS attacks in progress and block vulnerability scans that alert hackers to exploitable site vulnerabilities. We recommend focusing on WordPress plugins to keep the process of adding a firewall as simple as possible. Using add-ons will be the most straightforward option. WordPress Firewall Rules to adhere to when configuring your firewall can be found here. Scan for Malware & Security Threats It's also good to perform periodic scans of your WordPress website to detect any malware or security threats that may have slipped by your site's defenses. Various tools can scan WordPress sites for such things, and many of the best ones are totally free, too. WPScan is an invaluable tool for Linux administrators looking to protect their WordPress sites from malware and other persistent threats. By scanning for malware and security risks, WPScan allows admins to identify issues such as outdated plugins, vulnerable themes, and weak passwords that need fixing. Installation is quick and painless, and its vulnerability database updates regularly to protect against new threats,making life simpler for administrators who want to maintain secure, healthy websites. Secure WordPress Usernames & Passwords Defining and enforcing a secure password policy is another best practice for securing a WordPress website. At a minimum, the policy should insist on passwords of at least 20 characters, which include letters, numbers, symbols, and a mix of capital and lowercase letters. Installing a two-factor security plugin that adds a time-limited one-time password to every login into the WordPress front-end or back-end is also advisable. Set Up Off-Site Backups Maintaining complete and current offsite backups of a WordPress website is a critical bulwark against malware intrusions and ransomware attacks. Having multiple backup versions of a WordPress website spanning a reasonable amount of time is important. This allows you to restore a version of your WordPress website before malware or ransomware infiltration. Plus, having the backup copies offsite eliminates any chance that a successful server-side attack will compromise them, too. Limit Login Attempts Limiting login attempts is another best practice for guarding a WordPress website against brute-force password attacks. To do it, you can configure your website to lock a user account after a reasonable number of login attempts. You can also set it to ban connections from the IP address associated with the failed login attempts. While these measures alone won't stop a hacker in their tracks, they will significantly slow their efforts to harm your site. Use HTTPS for Encrypting Data Switching your WordPress site over to HTTPS is vital for security and trust. HTTPS protects information by encrypting data sent between visitors, making it hard for hackers to intercept and read personal details like passwords or sensitive financial data. In addition, it ensures users communicate directly with your authentic website, protecting against man-in-the-middle attacks. Plus, search engines prefer sites using HTTPS, as they won't appear as"Not Secure" in browsers - improving both search rankings and trust among visitors. To enable HTTPS on your site, purchase and install an SSL certificate from your hosting provider. Afterward, modify WordPress settings so your URL includes s:// rather than ://. Additionally, force all traffic through HTTPS while simultaneously addressing mixed content issues with plugins like Really Simple SSL for enhanced peace of mind for both visitors and you alike. Secure File Permissions & Ownership As previously mentioned, it's important to set the proper file permissions and ownership for the files associated with a WordPress website. Most WordPress folders should be 755, and most individual files should be 644. Of course, there are always exceptions to those generalities, so it's important to follow all relevant WordPress and plugin documentation and to check trustworthy guides on the subject. Use an Uptime Monitor Uptime monitors can be a useful security tool because they can alert you to a problem with your WordPress site as soon as it happens. When there's any possibility of a malicious intrusion, every second counts. An uptime monitor could warn to block an attack in progress or at least blunt its damage. Add ReCAPTCHA in WordPress Login In addition to the aforementioned two-factor authentication, it's also advisable to add ReCAPTCHA functionality to your WordPress site's login pages and user forms. Various plugins make this easy, and installing one can safeguard your site against botnets, spam, and attacks from sketchy shared IP addresses. Conduct Security Audits & Penetration Testing Since no WordPress security scheme will ever be perfect, conducting regular security audits is an excellent way to ensure your site complies with the previously covered security best practices. It is also good to perform penetration testing to ensure your security measures work as intended. Implement Robust Monitoring & Logging Practices Finally, every WordPress website should include robustmonitoring and logging . The logs generated by the WordPress installation and any plugins can be treasure troves of useful data. For example, your site logs may reveal intrusion attempts by hackers and even clue you into specific vulnerabilities they may be looking to exploit. Various plugins will aggregate your logs into a single interface and even send you alerts based on predefined preferences. Our Final Thoughts on Improving WordPress Security on Linux Webservers At the end of the day, WordPress, running on one Linux variant or another, is and will continue to be the backbone of the Internet. However, it's incumbent upon every WordPress website owner to do their part to keep their sites safe from exploitation. With knowledge of the most common vulnerabilities and the best practices to mitigate them, securing your WordPress site is easier than you think! With a bit of effort and vigilance, running a secure WordPress website is well within reach of even a beginner web admin. Have additional questions? Reach out to us @lnxsec - we’re here to help! . Safeguard your Linux-based WordPress platform by adhering to optimal strategies regarding firewalls, malware defenses, and regular software maintenance.. WordPress Security Best Practices, Linux Server Protection, Web Threat Mitigation. . Duane Dunston
Dec 17, 2024
•
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
security advisoryEnGarde Secure Linuxfirewall configurationEnGarde Secure Linux: Implement PSAD for Active Network Scan Detection
Having a great defense involves proper detection and recognition of an attack. In our security world we have great IDS tools to properly recognize when we are being attacked as well as firewalls to prevent such attacks from happening. However, certain attacks are not blindly thrown at you - a good attacker knows that a certain amount of reconnaissance and knowledge about your defenses greatly increases the chances of a successful attack. How would you know if someone is scanning your defenses? Is there any way to properly respond to such scans? You bet there is... . Eckie S. The Port Scan Attack Detector (psad) is an excellent tool for detecting various types of suspicious traffic, including port scans from popular tools such as Nmap, DDoS attacks, and other efforts to brute force certain protocols on your system. By analyzing firewall logs, psad can not only pick up on certain attack patterns, but even manipulate firewall rules to properly respond to suspicious activity. This article will walk the reader through an EnGarde Secure Linux implementation of psad, from the initial iptables rules setup to the deployment of psad on the server side. By the end of the article, the user will be able to detect certain Nmap scans and have psad respond to these scans by blocking the source. Prerequisites +---------------------------------------------------------------------------You will need: - A machine with EnGarde Secure Community 3.0.18 or above installed to do your development on. These commands should NOT be run on a production server since psad will eventually deny any type of access from the remote scanning machine! - A separate machine on the same network with Nmap installed on it. You will be running certain scans on the server from this machine. Once you have all the above you may log in as root, transition over to sysadm_r, and disable SELinux: [psad_server]# newrole -r sysadm_r Authenticating root. Password: [psad_server]# setenforce 0 Throughout the HowTo, the server will be referred to as psad_server and the Nmap scanning machine as nmap_scanner. Install psad +---------------------------------------------------------------------------EnGarde Secure Linux makes the installation of psad a breeze due to its Guardian Digital Secure Network (GDSN). You can install the package through the command line: [psad_server]# apt-get install psad ...or login to WebTool and download the package from the package manager interface. We shall get around to the setup of psad after we configure the firewalls on psad_server to log packets: iptables Rules Setup +---------------------------------------------------------------------------Since iptables is installed out of the box on EnGarde Secure Linux, you only have to run two simple commands to start logging packets with iptables: [psad_server]# iptables -A INPUT -j LOG [psad_server]# iptables -A FORWARD -j LOG From here on out incoming packets (especially those of Nmap scans) will be logged. Let's see if we can start detecting such scans by setting up psad to do so. psad Configuration +---------------------------------------------------------------------------On psad_server, use your favorite editor to modify the /etc/psad/psad.conf file. We're interested in the following tunables: EMAIL_ADDRESSES HOSTNAME SYSLOG_DAEMON ETC_SYSLOGNG_CONF The EMAIL_ADDRESSES should be whichever email addresses you wish to have psad send feedback to. This feedback includes error messages and alerts of potential dangerous scans depending on danger levels which can be fine-tuned for your purposes. - The HOSTNAME tunable will be the hostname of the psad_server machine. - The SYSLOG_DAEMON refers to the logging daemon for the machine. For EnGarde Secure Linux, this should be set to 'syslog-ng'. - The ETC_SYSLOGNG_CONF refers to the direct path of the syslog-ng daemon's configuration file. For EnGarde Secure Linux, this should be set to '/etc/syslog-ng.conf'. - Once you've properly configured those tunables, you can start the psad daemon: [psad_server]# /etc/init.d/psad start [ SUCCESSFUL ] psad Daemons Note: As far as danger levels are concerned, these range from one to five and are assigned to the IP addresses from which an attack or scan is detected. They are assigned based on the number of packets sent, port range, the time interval of the scan, whether or not the signatures of the packets match up with psad signature attacks, and the IP address where the packet originated from. Depending on the number of such packets, a level is assigned as per the configuration file. For more information on danger levels and ideas for fine-tuning them, please refer to the resources at the end of the article. psad - Active Detection +---------------------------------------------------------------------------We will now use psad to detect certain Nmap scans. On the Nmap scanning machine, run a TCP connect() scan by executing the following: [nmap_scanner] nmap -sT 1.2.3.4 Replace 1.2.3.4 with the IP address of your psad_server. If we check the /var/log/psad/fwdata file on the psad_server, you will find the following: Feb 2 11:58:11 psad_server kernel: IN=eth0 OUT MAC=00:0c:29:78:22:73:00:0c:76:4b:f6:3e:08:00 SRC=5.6.7.8 DST=1.2.3.4 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23609 DF PROTO=TCP SPT=49021 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0 We can see that SRC will have the IP address of the nmap_scanner machine, and DST will have the address of the psad_server. Also note that PROTO=TCP, showing that the attack was a TCP connect() scan. If you had previously configured psad to send email alerts, you will begin receiving emails concerning this scan showing lots more data than these log messages can ever produce. There are configuration tunables in the /etc/psad/psad.conf file to limit and even disable email: EMAIL_LIMIT ALERTING_METHODS EMAIL_ALERT_DANGER_LEVEL EMAIL_LIMIT defines the maximum number of emails a configured user will receive for a given IP address. ALERTING_METHODS can be set to noemail, nosyslog, and ALL, depending on whether you want only syslog-ng messages, email alerts, or both. EMAIL_ALERT_DANGER_LEVEL is the minimum danger level that must be hit in order for psad to send email alerts concerning a detection. The default setting is one, so you can expect lots of emails for this tutorial's purpose. Here is an example email showing psad output of the previous Nmap scan: Subject: [psad-alert] DL2 src: nmap_scanner.yournetwork.com dst: psad_server.yournetwork.com Danger level: [2] (out of 5) Scanned UDP ports: [32772: 1 packets, Nmap: -sU] iptables chain: INPUT, 1 packets Source: 5.6.7.8 DNS: nmap_scanner.yournetwork.com OS guess: Linux (2.4.x kernel) Destination: 1.2.3.4 DNS: psad_server.yournetwork.com Overall scan start: Mon Feb 2 11:57:19 2008 Total email alerts: 2 Complete TCP range: [64-49400] Complete UDP range: [32772] Syslog hostname: unknown Global stats: chain: interface: TCP: UDP: ICMP: INPUT eth0 40 1 0 [+] TCP scan signatures: "P2P Napster Client Data communication attempt" dst port: 5555 (no server bound to local port) flags: SYN sid: 564 chain: INPUT packets: 1 classtype: policy-violation As you can see, psad does a wonderful job of taking packet data from logs, analyzing it and producing useful information on the type of scans used. psad - Active Defense +--------------------------------------------------------------------------- One ofthe more prominent features of psad is its active defense implementation - being able to detect Nmap scans is nice, but how do you respond? Let's configure psad to automatically block the source of such scans upon detection. Before implementing this feature, it is obvious for certain security veterans who are reading this article that there is a definite tradeoff for enforcing an active response policy. Although malicious traffic will be blocked, there is always the risk of blocking out valid traffic. Certain attackers can exploit active defenses and turn it against the target by attempting to spoof valid addresses, thus blocking out otherwise harmless traffic. This only happens in cases where the active response system has been configured to respond to nearly ALL types of potentially harmful traffic, including port scans or port sweeps. This also applies to traffic which does not require bidirectional communication with the target. A better strategy to employ is to only respond to traffic where bidirectional communication is required i.e. TCP connections. Even then, one must take care to tailor their active response to certain types of TCP connections, such as attempted SQL injection attacks, etc. Please be sure you are absolutely positive of how your detection scheme is working before deploying an active defense. Using your favorite editor, modify the /etc/psad/psad.conf file. We're interested in the following tunables: ENABLE_AUTO_IDS AUTO_IDS_DANGER_LEVEL ENABLE_AUTO_IDS should be set to 'Y' to enable the automated IDS response. AUTO_IDS_DANGER_LEVEL, for this HowTo's sake, will be set to '3'. This danger level is customizable and the setting we use in this HowTo is for demonstration purposes only. Restart the psad on the psad_server: [psad_server]# /etc/init.d/psad restart [ SUCCESSFUL ] psadwatchd Daemon [ SUCCESSFUL ] psad Daemon [ SUCCESSFUL ] kmsgsd Daemon [ SUCCESSFUL ] psad Daemons From the nmap_scanner machine, we'll run an Nmap SYN scan along with the '-P0' switch - this type of scan uses noping and does not fully complete a TCP connection, resulting in fast scans. This usually requires root privileges, and is considered more of a dangerous scan - just the type of scan that psad detects at a higher danger level. [nmap_scanner]# nmap -sS -P0 -n 1.2.3.4 Replace the '1.2.3.4' with the IP address of your psad_server machine. psad will detect the SYN scans, and since the danger level of this scan is 3, it manipulates the iptables rules to block the source of the scans. This can be verified on the psad_server by running the following command: [psad_server]# psad --fw-list [+] Listing chains from IPT_AUTO_CHAIN keywords... Chain PSAD_BLOCK_INPUT (1 references) pkts bytes target prot opt in out source destination 820 36080 DROP all -- * * 5.6.7.8 0.0.0.0/0 Chain PSAD_BLOCK_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 5.6.7.8 Chain PSAD_BLOCK_FORWARD (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 5.6.7.8 0 0 DROP all -- * * 5.6.7.8 0.0.0.0/0 You will even receive an email alerts that inform you of the scan detection, as well as an email informing you that iptables rules have been added to auto- block the nmap_scanner! Wrapping It All Up +--------------------------------------------------------------------------- Congratulations, you've successfully implemented psad to actively detect and respond to signature Nmap scans! Keep in mind this is one of the more basic setups for psad. You can go even further and adjust danger levels to suit degrees of paranoia, put psad into forensics mode, incorporate the software with DShield, and even manually use psad to manipulate iptables rules. A great resource for psad research is 'Linux Firewalls' by Michael Rash. Rash includes several chapters on psad covering not only theory but advanced implementation of psad from start to finish. If you wish to gain suggestions for an advanced, finely-tuned active defense setup with psad, be sure to check this bookout! Have fun implementing an active defense against those who try to scan your system! Resources +--------------------------------------------------------------------------- / https://guardiandigital.com/ 'Linux Firewalls' by Michael Rash 'Knock, Knock, Knockin' on EnGarde's Door' features/knock-knock-knockin-on-engardes-door-with-fwknop . Learn how to implement the Port Scan Attack Detector (psad) for Intrusion Detection within EnGarde Linux to detect and respond to unauthorized network scans. Port Scan Attack Detector, Network Attack Response, EnGarde Secure Linux, Nmap Detection, Active Defense Setup. . Anthony Pell
Jul 16, 2010
•
102
network securitysecurity measuresattack preventionDDoS Protection Strategies: Effective Measures for Network Security
In this article I am trying to explain what DDOS is and how it can be prevented. DDOS happens due to lack of security awareness of the network/server owners. On a daily basis we hear that a particular machine is under DDOS attack or NOC has unplugged the machine due to DDOS attack . So DDOS has become one of the common issues in this electronics world. DDOS is like a disease which doesn't have an anti-viral developed. So we should be carefull while dealing with it . Never take it lightly. In this article i am trying to explain the steps/measures which will help us defend from DDOS attack ,up to a certain extend . . What is a DDOS attack? Simply said, DDOS is an advanced version of DOS attack . Like DOS , DDOS also tries to deny the important services running on a server by broadcasting packets to the destination server in a way that the Destination server cannot handle it. The speciality of the DDOS is that, it relays attacks not from a single network/host like DOS. The DDOS attack will be launched from different dynamic networks which has already been compromised. Normally, DDOS consists of 3 parts . One is the Master ,Other the slave and atlast the victim. The master is the attack launcher ie the person/machine behind all this,sound's COOL right . The slave is the network which is being compromised by the Master and Victim is the target site/server . Master informs the compromised machines, so called slaves to launch attack on the victim's site/machine. Hence its also called co-ordinated attack. In my term, Master is said to be the Master Brain, Slave is said to be the launch pad for the attack and Victim is the target. How do they Do it? DDOS is done in 2 phases. In the first phase they try to compromise weak machines in different networks around the world. This phase is called Intrusion Phase. Its in the next phase that they install DDOS tools and starts attacking the victims machines/site. This Phase is called Distributed DoS attacks phase. What Allowed them to do it? The reasons are given below :- 1) Vulnerable softwares/Applications running on a machine or network. 2) Open network setup. 3) Network/ machine setup without taking security into account. 4) No monitoring or DataAnalysis are being conducted. 5) No regular Audit / Software upgrades being conducted. What should we do if we are under attack? First Identify if you are really under attack. If yes, follow the below steps : Check if your machines load is high and you have large number of HTTP process running. To find the load just use the command w or uptime - --- Eg: Blessen@work > w 12:00:36 up 1 day, 20:27, 5 users, load average: 0.70, 0.70, 0.57 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT --- To find if there is large number of HTTP process running use the command " ps -aux|grep HTTP|wc -l " Eg: -- [root@blessen root]# ps -aux|grep HTTP|wc -l 23 -- In a heavy server , the number of connection will go above 100. But during DDOS attack, the number will go even higher and thats when we need to find out from which all networks are these attacks coming. In DDOS the host machine doesn't have much importance. Its the network which is of importance here because, an attacker will use any machine on the compromised network or even will use all the machines in the network. Hence network address is of importance while fighting with the attack. If you have high load (say 5 or more ) and you have large number of HTTP process then i would request you to do the following 1) At command prompt execute the below command bash#netstat -lpn|grep :80 |awk '{print $5}'|sort 2) Check each block of ips. Like let me say , that you have more than 30 connection from a single ip. Under normal cases there is no need for that many number of connection requests from a single IP. Try to identify suchips/networks from the list you get 3) If more than 5 host/ip connects from the same network then its a clear sign of DDOS . 4) Block that ips/networks using iptables /Apf iptables -A INPUT -s -j DROP If you have apf then just add the ips which you want to block in the file /etc/apf/deny_hosts.rules 5) Keep on continuing this process untill the attack on the machine gets reduced. There is no complete or perfect solution to DDOS . The logic is simple, NO softwares or measures could handle attacks from multiple servers say from 50 - 100 servers all at a time . All that can be done is to take preventive measures . How can we prevent or defend ourselves from these attacks? Like said, Prevention is better than cure. Its very much true in the case of DDOS . In my Introduction, I had mentioned that DDOS happens because of vulnerable softwares/applications running on a machines in a particular network. Attackers use those security holes to compromise the servers in different network and install the DDOS tools (eg trinoo -DDOS tool ) To prevent DDOS in future, follow the below steps which has 12 major steps Setup machine / network keeping security in mind (Implement Good Security policy) Setup a firewall which does Ingress and Egress Filtering at Gateway Eg: Steps to Install AFP ---- bash# wget https://rfxn.com/downloads/apf-current.tar.gz bash# tar -zxf apf-current.tar.gz bash# cd apf- bash# ./install.sh Notes: Go through the Document in the Apf and configure it for your needs. All configuration is set at conf.apf which is normally located at /etc/apf/conf.apf Enable Anit-DOS mode in Apf (ie in conf.apf) . Also make sure that your root's cron has an entry like the one below */8 * * * * root /etc/apf/ad/antidos -a > > /dev/null 2> &1 ----- Install IDS on your gateway/hosts to alert you when someone tries to sniff In. Eg:AIDE ---------- (a) Wget (b) Untar it tar -zxvf aide-0.7.tar.gz (c) cd aide-0.7 (d) Then execute ./configure -with-gnu-regexp (e) Final steps to install make;make install (f) Now the main step..To configure AIDE.AIDE stores all its rule sets in the file called aide.conf. Lets populate it get more details of how to configure and all from man aide.conf (g) Here I am taking an example .See below Here is a sample short aide.conf: Rule = p+i+u+g+n+s+md5 /etc p+i+u+g /sbin Rule /usr/local/apache/conf Rule /var Rule !/var/spool/.* !/var/log/.* In the above configuration listed , a rule called "Rule" is set to check permissions (p), inode (i), user (u), group (g), number of links (n), size (s), and md5 checksum (md5). This rules are applied to all files in /bin, /sbin, /var, and /usr/local/apache/conf because they should rarely if ever change. Files in /etc are checked for changes in only permissions, inode, user, and group because their size may change, but other things shouldn't. Files and directories in /var/spool and /var/log are not checked because those are folders where maximum updation takes place. (h) After configuring AIDE should be initiated with all these rules. For that execute aide -init ---------- Conduct regular Audits on each host on the network to find installation of DDOS tools / Vulnerable applications. Use tools like RKDET(vancouver-webpages.com/rkdet),RKHUNTER() and CHKROOTKIT(www.chkrootkit.org) to find if any rootkit has been already installed and to locate the effected binaries in the machine, if any. Please find a simple Audit check List below to be done on a Hosts Eg: Audit Check List --- A quick checklist: * Software Vulnerabilities. * Kernel Upgrades and vulnerabilities. * Check for any Trojans. * Run chkrootkit. * Check ports. * Check forany hidden processes. * Use audittools to check system. * Check logs. * Check binaries and RPMS. * Check for open email relays. * Check for malicious cron entries. * Check /dev /tmp /var directories. * Check whether backups are maintained. * Check for unwanted users, groups, etc. on the system. * Check for and disable any unneeded services. * Locate malicious scripts. * Querylog in DNS. * Check for the suid scripts and nouser scripts. * Check valid scripts in /tmp. * Use intrusion detection tools. * Check the system performance. * Check memory performance (run memtest). --- Enforce and Implement Security Measures on all hosts in the network. Machines new or old should only be allowed to run on your network, if your Security Admin or DSE (Dedicated Security Expert) member approves it with status ``OK-to go live' after auditing the box. All Host in the network should be checked on a regular basis by your DSE team to make sure that all hosts are uptodate and can fight any attacks. Audit network on a regular basis to see if your network is vulnerable to attacks Use Open Source Tools like NESSUS(https://www.tenable.com/ ,NMAP(www.insecure.org/nmap),SAINT( (www-arc.com/sara/sara.html)for auditing a network to find its vulnerabilities. Create a DSE (Dedicated Security Expert ) Team for your company. Collect your networks and hosts data . Analysis them and study them to see from where and what kind of attacks are coming into the network. This step will help us to understand what kind of attacks we are facing and will help us to strengthen the preventive measures. Let me tell you this move is worth the money you spend,for sure. Implement Sysctl protection against DDOS Eg: ---------- bash# vi /etc/sysctl.conf add the below code: # Enable IP spoofing protection, turn on Source Address Verification net.ipv4.conf.all.rp_filter = 1 # Enable TCP SYN Cookie Protection net.ipv4.tcp_syncookies = 1 Add the below code in /etc/rc.local and restart network for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > done echo 1 > /proc/sys/net/ipv4/tcp_syncookies ---------- Install Mod_dosevasive to your apache. Mod_dosevasive is module for Apache to perform evasive action in the event of an HTTP DDoS attack or brute force attack. Please find the installation step of mod_dosevasive in DSO mode below Eg: Install Mod_dosevasive ------ bash# wget bash# tar -zxvf mod_evasive_1.10.1.tar.gz bash# cd mod_evasive_1.10.1 bash# $APACHE_ROOT/bin/apxs -iac mod_evasive.c Dont get scared by the variable ``$APACHE_ROOT' . Its nothing, but a simple variable which stores the location of the apache installation (eg $APACHE_ROOT =/usr/local/apache) bash# vi /usr/loca/apache/conf/httpd.conf After this add the below code in httpd.conf DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 10 bash# /usr/loca/apache/bin/apachectl restart ------ Install Mod_security . Since DDOS normally targets http. Its always good to have a filtering system for apache . So that the request gets analyzed before web server handles it. Please find the installation step of mod_security in DSO mode below Eg: Installation Steps ------ bash# https://github.com/owasp-modsecurity/ModSecurity bash# tar -zxvf modsecurity-apache-1.9.2.tar.gz bash# cd modsecurity-apache-1.9.2 bash# /usr/local/apache/bin/apxs -cia mod_security.c Create a file named mod_security.conf under the folder /usr/local/apache/conf bash# vi /usr/local/apache/conf/mod_security.conf Create the rule with reference to the linkhttps://github.com/owasp-modsecurity/ModSecurity and add it in the mod_security.conf file. Add the location of mod_security.conf to httpd.conf bash# vi /usr/local/apache/conf/httpd.conf Add the string below Include /usr/local/apache/conf/mod_security.conf bash# /usr/local/apache/bin/apachectl stop bash# /usr/local/apache/bin/apachectl start ------- Best solution to fight DDOS to a certain extend will be to setup load balancer for your services. Creating awareness on Security This is the most important part. People should be Security conscious. Then only they will understand the importance of Security measures . Server owner's and users should be made aware of the issues which can rise due to bad security measures . Conclusion DDOS can be prevented to a certain extend, if hosts and network are secure. So I advice each server owners and network owners to implement security measures on their network ,if they want to fight against DDOS. About this document ... Preventing DDOS attacks Written By Blessen Cherian Sr.Executive Team Member of Bobcares.com [ Head Of Installation,Security and Networking Department ] Poornam Info Vision Pvt Ltd . To protect your network from DDoS attacks, implement diverse strategies like traffic analysis, rate limiting, and using a CDN for enhanced security.. DDoS Protection, Network Defense, Security Guidelines. . Blessen Cherian
Mar 16, 2006
•
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