Explore top 10 tips to secure your open-source projects now. Read More
×
Stay Ahead With Linux Security Features
identity management security tactics For years, we secured our Linux infrastructure by building walls: VPCs, security groups, and hardened SSH configurations. We treated the cloud like a virtual data center, assuming that if we kept the "bad guys" out of the network, our workloads were safe. . That model is no longer sufficient. Today, one of the most common paths from an initial compromise to a major cloud breach is the identity assigned to your Linux workload. When an attacker gains code execution on a Linux instance—through a...
Jul 17, 2026
security practices patch management Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange...
Jul 14, 2026
Linux security cyber attacks Every Linux server in your fleet produces thousands of events every minute. From journald logs and auditd records to kernel-level eBPF hooks, your systems are constantly talking. Most of that noise is just the mundane churn of system services, CI/CD runners, or routine administrative automation. But among that noise, an attacker might be establishing a foothold, moving laterally, or setting up persistence. The challenge for any security team is: how do you separate the routine from the...
Jul 13, 2026
open-source infrastructure risk Security scanners flag exposed API keys in public repositories every day. The initial response is usually predictable: delete the commit, revoke the credential, and move on. That’s a mistake. . In a real Linux environment, an API key never stays in one place. By the time it hits a public repo, it’s already everywhere. It’s in the CI/CD pipeline. It’s in your container registry. It’s in the build logs. It’s in the backups. Git makes this worse because the history never dies. Deleting a file in...
Jul 11, 2026
open-source rootkit Most of us think of Linux rootkits as ancient history—the stuff of 90s hacking forums and clunky malware that would crash your system if you looked at it the wrong way. But if you think they’ve gone away, you’re mistaken. They’ve just gotten smarter. . Modern attackers aren't using the noisy tools of the past. Today’s threats are surgical. Many of today’s most advanced Linux rootkits operate at the kernel level or abuse legitimate system features to blend in with normal traffic. They’re...
Jul 09, 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
Should Linux servers automatically install security updates?
Loading...
Explore Latest Linux Security features
We found 3 articles for you...
102
security practiceskernel securitysystem hardeningEssential Guide for Securing the Linux Kernel Environment Effectively
With the support of the open-source community and a strict privilege system embedded in its architecture, Linux has security built into its design. That being said, gone are the days when Linux system administrators could get away with subpar security practices. Cybercriminals have come to view Linux as a viable attack target due to its growing popularity, the valuable devices it powers worldwide, and an array of dangerous new Linux malware variants that have emerged in recent years. . It has become apparent that most attacks on Linux systems can be attributed to misconfigurations and poor administration - and failure to properly secure the Linux kernel is often at least partially to blame. Kernel security is a key determinant of overall system security, as the Linux kernel is the foundation of the Linux OS and the core interface between a computer’s hardware and its processes. Luckily, the Linux kernel possesses an assortment of effective built-in security defenses - namely, firewalls that use packet filters built into the kernel, Secure Boot, Linux Kernel Lockdown, and SELinux or AppArmor - that administrators should take full advantage of. In this article, we'll examine the importance of robust kernel security and explore various measures you can take to secure the Linux kernel and protect your systems from malware and other exploits. How Secure Is the Linux Kernel? Kernel security is an ongoing concern for Linux system administrators, and securing the kernel is one of the most complex aspects of securing a Linux system. Even though the Linux kernel undergoes constant scrutiny for security bugs by the “many eyes” of the vibrant, global open-source community, kernel vulnerabilities remain a persistent and serious threat. Flaws are inevitable in any OS, and many Linux kernel bugs present potential security issues, often resulting in privilege escalation or denial-of-service (DoS) attacks. Critical kernel vulnerabilities can often be exploited by remote attackers - withoutrequiring that the victim take any actions. Some of the most notorious Linux kernel security bugs discovered and fixed in recent years include: CVE-2017-18017: This critical vulnerability, which resides in the netfilter tcpmss_mangle_packet function, is highly dangerous due to its central role in filtering network communications by defining the maximum segment size that is allowed for accepting TCP headers. Without these controls, users are susceptible to overflow issues and DoS attacks. The flaw impacts kernel versions before 4.11. CVE-2016-10229: This udp.c bug, which also affects kernel versions before 4.5, allows a remote attacker to execute arbitrary code via UDP traffic, triggering an unsafe second checksum while executing a recv system call with the MSG_PEEK flag. CVE-2016-10150: This use-after-free vulnerability, which impacts kernel versions before 4.8.13, could be exploited by hackers to gain privileges and launch DoS attacks. CVE-2015-8812: This severe vulnerability, which was discovered in the Linux kernel drivers, impacts kernel versions prior to 4.5 and enables a remote attacker to execute arbitrary code or cause a DoS (use-after-free) attack via crafted packets. CVE-2014-2523: This serious netfilter vulnerability, which impacts kernel versions through 3.13.6, is attributed to the incorrect use of a DCCP header pointer. The flaw allows a remote attacker to cause a DoS (system crash) attack or to execute arbitrary code via a DCCP packet that triggers a call to either the dccp_new, dccp_packet, or dccp_error function. Tracking advisories is critical in protecting against kernel vulnerabilities and maintaining a secure, updated system. Subscribing to our weekly Linux Advisory Watch newsletter is an easy, convenient way to stay up-to-date on your Linux distribution's latest advisories and updates issues. What is Kernel Self-Protection, and Why Is It Important? Linux kernel-self protection , or the design and implementation of systems andstructures within the Linux kernel to protect against security flaws in the kernel itself, is an excellent way of adding another layer of security to the Linux kernel. It includes defense methods such as attack surface reduction, memory integrity, probabilistic defenses and the prevention of information exposure. Let’s examine some tips and best practices for securing the Linux kernel by implementing these defense methods to protect your users, your systems and your data. Practical Advice for Securing the Linux Kernel Securing the Linux kernel requires a proactive, multi-layered defense strategy. Practical measures you can take to secure the kernel against vulnerabilities and exploits leading to compromise include: Apply Kernel Security Patches The Linux kernel is patched frequently to mitigate the latest security vulnerabilities discovered and, albeit monotonous, staying on top of kernel security updates is imperative to maintaining a secure Linux system. The most straightforward method of updating the Linux kernel is tracking distribution security advisories and applying the latest updates available directly from your Linux distribution. There are three other methods for updating the kernel: on the command line, with kexec, or with a rebootless live kernel patching tool . Updating the kernel from the command line is the method that is most likely to be covered in your distribution’s documentation. However, a major disadvantage of patching the kernel on the command line is that you will need to suffer the downtime of a system reboot. Administrators can quicken rebooting process by using the kexec system call. However, this method is risky, as it can cause data loss and corruption. The third method - updating the kernel automatically using a rebootless live kernel patching tool such as Livepatch , Ksplice , Kpatch , Kgraft is generally administrators’ method of choice, but is not a replacement for full kernel upgrades, as it only applies patches for security vulnerabilities orcritical bug fixes. Enable Secure Boot in “Full” or “Thorough” Mode UEFI Secure Boot is a verification mechanism for ensuring that code launched by a device's UEFI firmware is trusted. The feature is designed to prevent malicious code from being loaded and executed before the OS has been loaded. By enabling UEFI Secure Boot in “f ull” or “thorough” mode, administrators can decrease the attack surface on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Thus, no unsigned drivers can be loaded for hardware on systems with UEFI Secure Boot enabled in “full” or “thorough” mode. This makes it far more difficult for an attacker to insert a malicious kernel module into a system and for unsigned rootkits to remain persistent after reboot. However, administrators should be aware that enabling Secure Boot comes with some potential drawbacks. For instance, it requires manual intervention any time a kernel or module is upgraded. Using Secure Boot also activates "lockdown" mode, which disables various features that can be used to modify the kernel. We will cover this in more depth in the following section. Use Linux Kernel Lockdown Linux Kernel Lockdown is a kernel configuration option developed to provide a policy to prevent the root account from modifying the kernel code by strengthening the divide between userland processes and kernel code. Thus, in the event that a root account is compromised, having Lockdown mode enabled will make it far more difficult for the compromised account to compromise the rest of the OS. Although Lockdown was not introduced until the release of kernel version 5.4, work on this feature began over a decade ago, and was spearheaded by Google engineer Matthew Garrett. Lockdown support can be activated to experience Linux Kernel Lockdown benefits with the lockdown= kernel parameter. The module has two modes: “integrity” mode and “confidentiality” mode. It is generally advised to use the “integrity”mode, and to only use the “confidentiality” mode for special systems that contain sensitive information that even root shouldn't be permitted to see, such as the EVM signing key which can be used to prevent offline file modification. Using confidentiality mode blocks access to all kernel memory, preventing administrators from being able to inspect and probe the kernel for purposes such as troubleshooting, development and testing and verifying security measures. Setting lockdown=integrity will block kernel features that allow user-space to modify the running kernel, while setting lockdown=confidentiality will block user-space from extracting sensitive information from the running kernel. Administrators have the option of permanently enforcing either the integrity or the confidentiality lockdown mode via SECURITY_LOCKDOWN_LSM_EARLY . All of these configurations are controlled through the Kconfig SECURITY_LOCKDOWN_LSM option for enabling the module and experiencing Linux Kernel Lockdown benefits. Administrators should be aware that using Lockdown prevents various features and modules that can be used to modify the kernel from loading. For instance, Lockdown disables: Loading kernel modules that are not signed by a trusted key, such as out-of-tree modules including DKMS-managed drivers. Using kexec to start an unsigned kernel image. Hibernation and resume from hibernation. User-space access to physical memory and I/O ports. Module parameters used to set memory and I/O port addresses. Writing to MSRs through /dev/cpu/*/msr. The use of custom ACPI methods and tables. ACPI APEI error injection. Enable Kernel Module Signing & Module Loading Rules The Linux kernel supports digital signatures on loadable kernel modules , ensuring that only known and valid modules can be loaded and decreasing a system’s attack surface with this requirement. Kernel module signing must be enabled in the kernel with settings in CONFIG_MODULE_SIG. Administrators can configure the kernelto require valid signatures, enable automatic module signing during the kernel build phase and specify which hash algorithm to use. Local or remote keys can also be used. In addition, limited module support can be enabled by default using the sysctl kernel.modules_disabled=1 command. Sysctl is a way for administrators to communicate directly with the kernel to control how it functions. These functions can also be configured in the /etc/sysctl.conf file. We explain how administrators can harden this file in the following section. Disabling modules completely can drastically reduce a system’s attack surface, but is only practical in special use cases. Harden the Sysctl.conf File The sysctl.conf file is the main kernel parameter configuration point for a Linux system. By using secure defaults, your whole system will benefit from a more secure foundation. With /etc/sysctl.conf you can configure various Linux network and system settings to improve security by: Limiting network-transmitted configuration for IPv4 Limiting network-transmitted configuration for IPv6 Turning on execshield protection Protecting against syn flood attacks Turning on source IP address verification Securing a server’s IP address against spoofing attacks Logging suspicious packets such as spoofed packets, source-routed packets and redirects Enable SELinux or AppArmor Modern Linux systems include the Mandatory Access Control (MAC) security enhancement systems AppArmor or SELinux (depending on the distribution) installed by default to protect against threats such as server misconfigurations, software vulnerabilities and zero-day exploits - which could potentially compromise an entire system without these controls in place. SELinux is installed and enabled by default on CentOS and RedHat Enterprise Linux OSes, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems. These security enhancement systems allow for granular access control with securitypolicies, providing an additional layer of security throughout a system. SELinux defines access controls for the applications, processes, and files on a system, using security policies to enforce these access controls. When an application or process - known as a “subject” - makes a request to access an “object” such as a file, SELinux checks with an access vector cache (AVC), where permissions are cached for subjects and objects. If SELinux is unable to make a decision about access based on the cached permissions, the request is forwarded to the security server, which checks for the security context of the subject and object from the SELinux policy database. Permission is then either granted or denied. If permission is denied, an "avc: denied" message will be available in /var/log/messages. For typical use cases, we recommend that administrators set SELinux to permissive mode . By operating in permissive mode, policy is not enforced and the system remains operational. In other words, SELinux does not deny any operations, but only logs AVC messages, which administrators can then use for troubleshooting, debugging, and policy improvements. Like SELinux, Apparmor isolates applications and processes from each other with per-program profiles built into the kernel, as well as any profiles that an administrator has generated. AppArmor can be set to either enforce these profiles or to complain when profile rules are violated. AppArmor is less complex than SELinux, but in turn offers less control over how processes are isolated. It is unfortunately quite common for administrators to disable SELinux or AppArmor when they encounter an issue as opposed to learning how to fix the issue with these services enabled. This is a poor administration and security practice, and can detract significantly from a system’s overall security posture by leaving the system susceptible to the very attacks that SELinux or AppArmor are designed to prevent. Implement Strict Permissions When all kernelmemory is writable, it’s easy for attacks to redirect execution flow - making it imperative that kernel memory is protected with a tight set of permissions. Permissions should be as strict as is practical in a given environment. Administrators should begin by ensuring that executive code and read-only data is not writable. The CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX configurations, which seek to make sure that code is not writable, data is not executable, and read-only data is neither writable nor executable, are the default options for the majority of Linux architectures. If these settings are user selectable, an administrator can select ARCH_OPTIONAL_KERNEL_RWX to enable a Kconfig prompt. CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT determines the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled. It is critical that function pointers and sensitive variables, which the kernel looks up and uses to continue execution, are read-only—not writable. Many such variables can be made read-only by setting them “const” so that they reside in the .rodata section instead of the .data section of the kernel. Permissions should always be configured to enforce the segregation of kernel memory from userspace memory. These rules can be enforced either via hardware-based restrictions or via emulation. Blocking userspace memory forces attacks to operate entirely in kernel memory. Use AuditD for Ongoing System Monitoring Carefully monitoring the Linux kernel enables administrators to discover security bugs, breaches or policy violations, allowing them to mitigate potential damage caused by these threats and verify the security of their systems. Using the Linux Auditing System (AuditD) is a popular and effective method of monitoring the events that occur on a system. AuditD is a native feature of the Linux kerne l, installed by default in most distributions and runs automatically, that collects information on system activity, such as file permissions modifications, services being enabled ordisabled, and network events, to facilitate the investigation of potential security incidents. It logs information according to its ules and any custom rules an administrator has added. The kernel is uniquely suited to perform these functions because only the kernel can access a system’s devices and memory. Here’s an example of the type of information the AuditD audit daemon provided. It shows users running specific commands like /usr/bin/sudo and ssh generating a new session key. type=USER_CMD msg=audit(1611763205.568:1621017): pid=1829220 uid=991 auid=4294967295 ses=4294967295 msg='cwd="/" cmd=2F7573722F6C6962363 exe="/usr/bin/sudo" terminal=? res=success'UID="nrpe" AUID="unset" type=CRYPTO_KEY_USER msg=audit(1611762843.231:1620894): pid=1825289 uid=0 auid=0 ses=49526 msg='op=destroy kind=server fp=SHA256:d7:c2:5a7 direction=? spid=1825289 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' UID="root" AUID="root" SUID="root" Here’s an example of “aureport” being used to generate a summary report of events on the system. [root@myhost ~]# aureport Summary Report ====================== Range of time in logs: 01/23/2021 04:54:03.379 - 01/27/2021 11:36:05.388 Selected time for report: 01/23/2021 04:54:03 - 01/27/2021 11:36:05.388 Number of changes in configuration: 67 Number of changes to accounts, groups, or roles: 0 Number of logins: 1457 Number of failed logins: 6249 Number of authentications: 1461 Number of failed authentications: 178 Number of users: 4 Number of terminals: 7 Number of host names: 661 Number of executables: 7 Number of commands: 1 Number of files: 0 Number of AVC's: 0 Number of MAC events: 65 Number of failed syscalls: 0 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 45395 Number of integrity events: 0 Number of virt events: 0 Number of keys: 0 Number of process IDs: 25064 Number of events: 136817 [root@myhost ~]# aureport -x --summary ExecutableSummary Report ================================= total file ================================= 71421 /usr/sbin/sshd 22796 /usr/sbin/crond 17905 /usr/lib/systemd/systemd 12344 /usr/bin/sudo 290 /usr/libexec/ipsec/pluto 26 /usr/bin/crontab 24 /usr/bin/su AuditD must be properly configured and hardened to ensure optimal security and effectiveness. Administrators should check that AuditD’s configuration is immutable using the control option “-e 2” and confirm that logs are stored in a centralized, secure location—ideally, a server dedicated to accepting remote syslog events. AuditD does have some weaknesses that should be considered - namely, bugginess, excessive overhead, lack of granularity, missing container support, and demanding output. Our Final Thoughts on Improving Linux Kernel Security Linux is becoming an increasingly attractive target among cybercriminals due to its growing popularity and the high-value devices it powers worldwide. Effective security is contingent upon defense in depth, and kernel security is a key element of overall system security that cannot be overlooked. After all, the kernel is the foundation of a system, and if the kernel is not secure, then nothing on the system is secure. Thus, Linux system administrators must prioritize kernel security and remain vigilant about implementing the tips and best practices discussed in this article to protect against security vulnerabilities and prevent exploits. Do you have questions about securing the Linux kernel or want to discuss the topic more? Reach out to us @lnxsec . We're here to help! . Attacks on Linux systems arise from misconfigurations; explore effective kernel security measures against threats.. support, open-source, community, strict, privilege, system, embedded, architec. . Brittany Day
Jan 22, 2025
•
102
system hardeningsoftware managementsecurity auditLynis: Installation Guide and Security Assessment Overview
running processes, configuration files, and more to determine what areas throughout a system need fixing to improve security posture. Such tools even offer information on how to go about such adjustments. . Lynis is an open-source auditing tool that performs extensive system health scans that support system hardening and compliance testing. Lynis supports Unix-based Operating Systems (OS), like Linux, and oversees a system for general information, vulnerable software packages, and configuration issues. This tool can detect cybersecurity vulnerabilities and provide in-depth auditing for continuous improvement, unlike other auditing tools that do not offer such information. The Lynis auditing tool assists with configuration, asset, and software patch management, as well as system hardening, pentesting , and intrusion detection. Lynis hopes to reach audiences, including system administrators, auditors, security officers, pen-testers, and security professionals, who may need help deploying hardening for web application security vulnerabilities, running daily scans for network security threats, demonstrating how to adjust security patching, and locating exploits in cybersecurity. This article will discuss Lynis installation, how to run the auditing tool and read reports, and the various testing options available through the service. Auditing Steps Lynis scans systems in a modular and opportunistic way by testing found components. Scans and audits will be more extensive if Lynis finds more, though network security toolkits do not need installation for Lynis to complete a scan. The nine steps to Lynis audits are as follows: Initializing Performing basic checks Determining Linux Operating System and tools Searching for available software components Checking the latest Lynis version Running enabled plug-ins Testing security in each category Executing your custom tests (optional) Reporting the status of the security scan to the user “lynis.log” will store all informationonce found. A separate file, “lynis-report.dat,” contains suggestions and warnings. Installation & Running First, install Lynis and start with the following codes: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C80E383C3DE9F082E01391A0366C67DE91CA5D5F sudo apt install apt-transport-https echo "deb stable main" | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list apt update apt install lynis Lynis show version The last code lets you know how upgraded Lynis is before using it on your system. To code Lynis for running, perform the following codes: cd lynis /lynis lynis audit system “/lynis” will ask you to pick an auditing option, and “lynis audit system” will execute the checks through your entire system. Here are a few other options to choose from: lynis audit system remote lynis audit dockerfile lynis --forensics lynis --pentest Remote security scan Analyze docker files Forensics on running/mounted system Pentesting Furthermore, you can set up cronjobs to run daily scans with these codes: crontab -e 30 22 * * * root /path/to/lynis -c -Q --auditor "automated" --cronjob This code will run scans at 10:30 P.M., outputting results to “lynis.log” About the Reports Once an audit is complete, Lynis will prevent multiple outputs: Result : This could state “ok” or “warning,” “found” or “not found,” and “none” or “done” based on what command you run and the outcome of that coding. Log File : You can see the action/event times, why a test failed or skipped, internal test outpost, configuration suggestions, and threat impact scores. Report File : Information and data Lynis gathers gets produced here so you can see remarks, sections, and options/values. Lynis generates details on package installations, Debian plug-inscans, and system boot and services so that you know what network security issues exist in your system. Lynis is thorough, even presenting other test and scan results such as the following: printers and spools, software messaging and firewalls, insecure services, SSH support, SNMP support, databases, LDAP services, kernel, memory, and processes, kernel hardening , users, groups and authentication, shells, file systems, file permissions, and more. When reading screen outputs, understand the colors, which make reading the files simpler: Green: Your system is exemplary, and any issues are disabled. Yellow: Lynis skipped a test, didn’t find a scan, or has a suggestion. Red: Somewhere in your system needs attention and is unsafe. Each section can expand the color to see the network security threat and how to mitigate cybersecurity vulnerabilities. Click on the "show details" command to get suggestions to improve security posture. Other Lynis Options Custom Tests You can choose particular tests to run on Lynis with the command “lynis show tests.” See all the options available on your OS and their descriptions to pick the best ones for the network security issues you are scanning for. Then input these commands: lynis show tests /lynis update info /var/log/lynis.lo cat /var/log/lynis.log | grep KRNL OR ./lynis -c -Q. ./lynis –tests “ These options allow you to figure out what test you want, how long it takes to run the scan, and how to set up test IDs. Lynis with Categories If you want to avoid using test IDs, run category tests. For example, type this for firewalls: ./lynis --tests-from-category “firewalls”. Our Final Thoughts on Lynis Keep your system secure and up to date using these auditing network security toolkits to ensure your system is healthy. Lynis is the best option, offering comprehensive auditing and improvement suggestions. The detailed reports cover everything in the system,making it easier to know system health and what categories need your attention. Lynis is easy to install and understand, as reports have color coding and various scanning options. Run Lynis with plug-ins and customize your scans so you stay updated on the latest cybersecurity vulnerabilities and data and network security issues . Do you use an auditing tool to maintain the health of your systems? If not, try out Lynis! We’d love to hear your thoughts - connect with us on X @lnxsec , and let’s discuss! . Lynis conducts rigorous assessments of system integrity to bolster protection measures and elevate compliance protocols.. open Source Auditing Tool, Security Checks, System Scans, Network Threat Detection, Software Management. . Zaid AlBukhari
Dec 19, 2022
•
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
network protectionsystem hardeninginformation securityInitiating Your Journey With Linux Server Security and Optimal Safeguarding
Are your Linux servers secure? No machine connected to the internet is 100% secure, of course. In the words of security guru Bruce Schneier: “Security is a process, not a product.” However, this doesn't mean that you are helpless. Although cyber attacks, hacks and breaches are sometimes unavoidable, all system administrators and users can take definitive measures to mitigate their risk online. . A Linux system is like a house. It’s easy to keep the windows and doors always closed, but controlling when and how they get opened is an ongoing challenge. And the fact that poor administration and misconfigured servers are to blame for the majority of exploits on Linux systems is evidence that many system administrators are failing to meet this challenge. This introductory guide will explore the fundamentals of information security and explain how these principles can be applied to evaluate and improve the security of your Linux servers. Linux: An Increasingly Popular Target Among Cyber Criminals Due to its growing popularity, Linux is increasingly being targeted in dangerous campaigns - despite its heralded security. Threat actors have come to view Linux servers as yet another viable target that often provides a valuable return on investment. Unfortunately, 2019 and the first half of 2020 have been filled with emerging malware variants targeting Linux servers - and a plethora of resulting security news headlines harping on how “insecure” Linux is. But if you investigate a bit, you’ll find that many of these stories are fake news, and that the underlying issue is incompetant system administrators. After all, regardless of the OS that you're running, if you’re failing at security, it doesn't matter how “secure” your OS is. For instance, the recent BootHole vulnerabilities that dominated security news coverage required admin access to exploit, making them very dangerous to an already hacked system. What was almost always overlooked in the coverage of BootHole was that ifsomeone has root access to your system, you’re already in serious trouble! The good news for Linux users is that in reality, despite the uptick in threats targeting Linux servers, Linux remains an exceptionally secure OS - especially when using a specialized secure Linux distro . The transparency of Linux source code and the constant scrutiny that this code undergoes by a vibrant global community results in the rapid detection and elimination of security vulnerabilities and potential exploits. In comparison, security flaws generally remain undetected for significantly longer in closed-source proprietary code. Malicious actors recognize and exploit this, directing the majority of their attacks at proprietary software, platforms and operating systems. That being said, the rise of Linux malware should serve as a much-needed wake up call for the security industry to invest additional resources in threat protection, detection and response. What Is a Security Framework? A security framework outlines the basic steps in the life cycle of securing a system. The following illustrates the framework needed to establish and maintain a secure system: [ Risk Analysis ] [ Business Requirements ] | [ Security Policy ] | [ Security Service, Mechanisms, and Objects ] | [ Security Management, Monitoring, Detection and Response ] ‘Risk Analysis’ is the process of identifying and analyzing potential issues that could impact the security of a system, while ‘Business Requirements’ deals with the actual requirements for conducting business. These two components address the business aspects of s security framework. The ‘Security Policy’ is the theoretical aspect of a security framework, and defines what it means to be “secure”. ‘Security Service, Mechanisms and Objects’ is the implementation aspect of security, and ‘Security Management, Monitoring, Detection and Response’ is the operational facet of security, which covers the specifics ofidentifying and reacting to a potential security breach. When looking to secure your system, there are a selection of benefits associated with establishing a security framework: Helps administrators understand the security status of their system Communicates cybersecurity requirements with superusers and users Identifies opportunities for new or revised standards Assists in prioritizing improvement activities As you can see, developing a security framework is a worthwhile investment for any system administrator looking to improve the security of his or her system. Information Security Basics: Breaking It Down Information security, or the process of protecting information against unauthorized use, can be broken down into two parts: (1) Physical security / host security and (2) Network security. Each of these components has three facets: Protection: Slow down or stop intrusions or damage Detection: Alert someone if a breach (or attempted breach) of security occurs, and quantify and qualify what sort of damage occurred or would have occurred Recovery: Re-secure the system or data after the breach or damage has occurred and, where possible, undo whatever damage was done Host Security/Physical Security This type of security involves protecting the server from unauthorized access. Physical security/host security can be achieved by password protecting the physical server with steps such as setting up a bios password, placing the box in a locked room where only authorized users have access, applying OS security patches, checking and correcting the permissions on all OS related files and reviewing logs on a regular basis for any signs intrusion or attacks. Tips for Improving Host Security: Protect your systems with strong passwords Check the file systems and set correct permissions and ownerships on all directories and files Apply security patches to vulnerable software Remove all unnecessary ttys and console logins by removingthe entry from /etc/securetty Check system logs (eg: /var/log/messages, /var/log/secure, etc.) Set a password on the boot loader Monitor the system Network Security Network security is one of the most important aspects of overall security. As mentioned above, no machine connected to the Internet is completely secure - so security administrators and server owners must always be alert and ensure that they stay informed of the latest security bugs and exploits . Failure to keep up with these vulnerabilities leaves users at risk of breaches, hacks, malware and other dangerous cyber attacks. Advice for Improving Network Security: Use custom security scripts which will send out notifications when sshing as root, creating a user with uid of 0, etc. Set up an idle timeout, so that idle users will be logged out after a certain amount of time. Restrict direct root login (comment out the PermitRootLogin login option in sshd_config). Limit user’s resources (using pam, specify the limits for each user in /etc/security/limits.conf). Hide the server details. Remove /etc/issues and /etc/issues.net, for example. Install a firewall (eg: apf and iptables) and only allow ports that the box needs for its normal functions to operate; block all other ports to prevent mischief. Deploy honeynets for intrusion detection. Restrict ssh to specific IP addresses and specific users. Use a quality VPN (like Wireguard ) to encrypt data between you and your server. Check router firmware for security vulnerabilities and eliminate potential bugs with a Linux firmware replacement . Organizations that require greater control over hardware, network segmentation, and resource isolation often deploy bare metal servers to reduce shared-environment risks and strengthen the overall security posture of critical workloads. Security is an Ongoing Balancing Act Maintaining a secure system is an ongoing process. This process is all about balancing trade offs: administratorsmust continuously weigh investments in security with the costs and potential impacts to system performance and user productivity. Optimal security is a delicate balance of cost, user experience and risk. And all of these factors are constantly changing - digital threats are ever-evolving, users’ expectations shift and growing demands of infrastructures alter the environment being secured. The challenge is to fully understand these factors, how they impact each other and how they are changing, and to determine the amount and types of security needed to best meet the expectations of all parties involved. Getting Started with System Hardening System hardening - or the process of securing a system by reducing its surface of vulnerability - is essential to establishing and maintaining a good security posture. Some methodologies and best practices for hardening your Linux system include: Keep up to date on security news by subscribing to our Linux Security Week newsletter , which summarizes the week’s most relevant open-source security news. Create a good security policy. Conduct security audits on the basis of this policy. Keep your OS updated by applying all patches. Install a custom kernel with all unwanted services removed and patched. Disable all unwanted services and harden the services you leave running. Change file and directory permissions to tighten security. Install a firewall and create good rule sets. Test and audit the server on a regular basis (covered in more detail below). Install an intrusion detection system and a log monitor. Make your partitions secure. Run a good backup system to recover data in case of an intrusion, crash or other type of destructive incident. Install a log analyzer and check your logs frequently for any suspicious entries. Install scripts to send out mail or enable notifications when a suspected security breach occurs. After a security breach, try to find out how, when and through what the breach occurred. When youfind a fix for it, document the details for future reference. Security Audits: What Should be Checked? A security audit aims to identify any vulnerabilities present in a system and suggest actions to improve these flaws. In a normal audit, the points below should be checked. A report with the results of this audit should be created. Check intrusion detection . Use chkrootkit or rkhunter for this purpose. Check for known bugs in the software installed on the server - the kernel, openssl , openssh , etc. Scan all network ports and find out which ports are open. Report the open ports that should not be open and the program that is listening on them. Check whether /tmp is secured. Check for hidden processes. Check for bad disk blocks in all partitions. Check for unsafe file permissions. Check whether the kernel has a ptrace vulnerability. Check the memory. Check if the server is an open email relay. Check if the partitions have enough free space. Check the size of the log files. It's better that the log size remains in megabytes. How To Determine if You’re Being Hacked? If you suspect that your system has been compromised, here are some very basic steps you can take to determine if you’re being hacked: Check if your performance has degraded or if your machine is being overused. Check if your server has any hidden processes running. Install an intrusion detection system (IDS) like OSSEC or Snort to detect anomalies in network traffic. Use intrusion detection tools like chkrootkit or rkhunter to check your system for rootkit infections. Check your machine’s uptime. Identify unknown processes and determine what they are doing. Monitor users’ activity using commands “w” or “who”. Check network traffic by running the command “iftop” with sudo. The Bottom Line Security is of utmost importance to a server - compromising on server security is compromising on the security of yoursystem as a whole. Hence, a solid understanding of information security is a prerequisite to successful server ownership and administration. Security is a continuous learning process - mistakes are inevitable, and can provide valuable insight for the future. Thus, it is critical that administrators take the time to fully understand both their successes and failures - enabling them to identify what is working and where there is room for improvement. The host of recent attacks exploiting Linux systems has brought both the prevalence and the impact of poor system administration to light, and has shown the importance of diligently monitoring servers for anomalies or signs of compromise. It is time for system administrator to make server security a priority. Have additional questions about securing your server? Leave them in the comments below - we’d love to help you out! . Discover the fundamental strategies to robustly safeguard Linux servers using key methodologies and essential security protocols.. Linux Server Security, System Hardening, Information Protection. . Brittany Day
Aug 31, 2020
•
102
system hardeningsecurity toolspassword managementCrucial Instruments for Safeguarding Unix-Based Systems and Platforms
System administrators are aware as how important their systems security is, not just the runtime of their servers. Intruders, spammers, DDOS attack, crackers, are all out there trying to get into people . Being able to identify tools and techniques to harden your systems is a key play on securing your systems. Moreover, choosing the right tools is a matter of experience. You should try most of them, or perhaps the ones that are popular. I chose free and open source software because, if I want to, I can check the applications source code and see for myself how did programmers wrote the software, how did they manage to keep the software easy to understand etc. Without trying to explain the networks peripherals particular importance on the security of the whole system, I will dig deep into software that check systems protocols, passwords, vulnerabilities, weaknesses, security flaws, best practices on protecting and securing your system and so on and then some important security steps any system administrator should know. I chose two popular security tools: Tiger and Lynis. Both state of the art security-auditing tools. Lynis Lynis is Unix based software and its free under the GPL and a popular security hardening solution. The advantage here is that it does not change any of your configuration files. Instead, it lists what it seas as weak or needs to change. It can scan your system in details and very extensively. Its use is straight forward, and it is OS independent, which means it will run in almost any Linux or Unix environment. You can run Lynis from USB, Cd, ext. HDD or any other media. With proper plugins, Lynis can test your databases, e-mail servers, web and what not. There are many documentations and video presentation regarding installing and configuring as well as using Lynis. I advice you to search for these and read as much as you can until you feel comfortable and start testing and using it. Latest version of Lynis as of now is 2.1.0 and can be obtained at: /downloads/lynis/ Tiger Just like Lynis, Tiger supports multiple UNIX platforms and it is free under GPL License. Besides system hardening tools, system configuration checks etc, Tiger offers host-based intrusion detection, and it is very successful at it. Its worth to note for Linux/Unix environment newcomers that, while there are lots of intrusion detection tools out there, most of them if not all are command line and offers minimal X based or GUI mode. As of now, the latest and stable version of Tiger is 3.2.3, and can be obtained at: Index of /releases/tiger/ I’ll write some Tiger scripts and their use. You are advised to check its documentation and find what interests you and what you are trying to accomplish. check_inetd – This script will check your init.d and find any misconfiguration. check_group – As its name suggests, it will check group passwords vulnerability, duplication and so on. check_accounts – This scrips will check your accounts for anything suspicious, home directories, shells, accounts with no passwords etc. check_anonftp – This checks your ftp configuration for any vulnerability. check_passwd – Checks for password configurations. Security Tips: I can’t stress enough how important it is for a Unix system to have root login disabled. This is crucial step and should be deactivated on all systems running important services, period. Besides disabling root login, it is advisable and yet very important to have X windows uninstalled. This is necessary if you’re running apache web server and you don’t need X windows. Remember, X windows are and can be vulnerable to attacks. Never use unsecured connections like telnet, ftp and so on! Use SSH, sftp instead! Set strong password policies and password expiration date, so that the user is prompted to change the password when it expires. This will ensure consistent password changes on all user accounts. I would advice to set it to three months at latest. Check file permissions periodically, this can create havocif not set properly. Close unused ports. Remove unnecessary software Check various security websites (do these daily) for security holes people and programmers found, and patch them immediately if your system is vulnerable! sysctl: an interface for changing parameters in Unix like environments. Read for sysctl and tweak the configuration the way you want it. Implement firewalls (iptables) Make daily backups! This is very important. Relocate another backup server away from the server room in case of disaster recovery etc… I could have filled this document with print screens and information on how to do all these things I explained, but I though it would be much better if you try them yourself. When you search for knowledge, I strongly believe, you will learn things much better, and sooner. You can refer to these two system hardening software and security advices, but don’t limit yourself. Try anything you can find, perhaps, look for popular software and try them on your test-machines, simulate real-life situations, configurations and so on. Remember, security measurements start with your systems version up to date! Last but not least, I would be very happy if you share some security tips with us on this post, so people can enjoy and learn more and be successful on what they do. About the Author Mr. Ibrahimi is a freelance Unix/Linux specialist and consultant with over 15+ years of experience on Open Source software. He is a regular contributor to UNIX community online as well as locally on projects involving his expertise on implementing Unix/Linux on IT infrastructures. . Being able to identify tools and techniques to harden your systems is a key play on securing your sy. system, administrators, aware, important, their, systems, security, runtime. . Dave Wreski
May 27, 2015
•
102
system hardeningsecurity managementpatch managementManaging Security in Linux 2004: Strategies and Routines for Success
This article examines the process of proper Linux security management in 2004. First, a system should be hardened and patched. Next, a security routine should be established to ensure that all new vulnerabilities are addressed. Linux security should be treated as an evolving process. . Introduction As Linux continues to gain popularity in the business world, security issues are something that cannot be ignored. In 2003, several well known Linux distributors had servers compromised. In one particular case, the vulnerability was well known in advance, but most vendors took entirely too much time to release an update. Similarly, most security problems that users face are known well in advance. As with any system, security on Linux is a process. It requires full commitment and due diligence. The secret is determining your own vulnerabilities and fixing them before anything catastrophic happens. Although Linux security is entirely in the hands of system administrators, several improvements have been made at the kernel level. With the release of kernel version 2.6, users will now be able to take advantage of the Linux Security Module allowing greater levels of security customization, modularization, and ease of management. Another thing that has changed in the past several years is that today more of us are reliant on automated software update services. Rather than download and install patches manually, it is now easier to subscribe to a trusted source and let the system manage itself. As long as the integrity of the trusted source remains strong, automated management works flawlessly. As soon as something questionable happens, it is necessary to re-evaluate. Solve the Problem Addressing Linux security is like solving any problem. It must be approached with a purpose and plan. If you have been using Linux and neglecting security, it is now time to face it head on. Although the task may seems daunting in the beginning, it will soon be apparent that securing a Linux system isactually very strait forward. In general security can be summed up into several steps. First, live by the minimum necessary rule. For example, turn off all unnecessary services, remove all programs that are not being used, and only give access when it is absolutely critical to a particular job function. Taking this simplistic approach will not only increase security, but over time will make life easier. It will eventually mean less stale-accounts to remove, less software to patch, and greater system performance. Next, keep a software inventory of all versions used. Use this information to conduct the research necessary to ensure that all have been patched appropriately. Doing this, will greatly reduce the risk of being compromised by a known vulnerability. As simple as it may sound, doing this will make the system no longer an easy target, therefore be much less likely compromised. Unless the attacker is highly motivated highly sophisticated a hardened system will not be appealing. Because most organizations have tens to hundreds of systems to manage, living by the minimum necessary rule, and establishing a security patch baseline is not always easy. The only way to approach Linux security is by developing a detailed plan. If server roles can be modularized, it may be much easier to determine what software is actually necessary for operation. Similarly, if multiple Web servers are on the network, they should all have the same basic set of software which again makes management easier. Planning for security, rather than trying to bolt it on after implementation is the key to success. Setup a Routine After a security plan is established and well underway, it also necessary to have a security routine. Security patches are released daily and your organization must have a way to deal with these. Hardening a system will only ensure a high level of security a single point in time. As time moves forward and vulnerabilities arediscovered and exploits are made public, the system will become more vulnerable each day. To address this, it is necessary to monitor mailing lists, subscribe to our newsletter Linux Advisory Watch, or subscribe to an automated patch management system. When evaluating Linux distributions, it is important to take into account the frequency, timeliness, and reliability of security updates. Unfortunately, some distributions have been known to only release updates every several months in inconsistent intervals. Others are very good and release patches very soon after the vulnerability is known. Some may wish to apply security updates daily, but it is probably more reasonable to apply them weekly. Of course, exceptions should be made for very critical updates. If production servers are going to be updated, it is advisable to first try them out in a testing environment. This is to minimize any damage that a flawed patch may cause. Also, do not forget to check the MD5 checksums of all downloaded patches. This can be done easily using the command-line tool 'md5sum.' To ensure overall system integrity, it is beneficial to a tool such as tripwire. Being the new year, it is now the best time to establish a routine. Excuses can always be made, but now is the best time to start. Determine what is necessary to keep your systems operating securely, and pick a day each week to devote to this. Time should be spent applying security patches, reviewing logs, reviewing active user accounts, and looking for anomalies. Devoting just a little time specifically security each week can make a huge difference. It is always better to address problems before they crop up. Concluding Remarks Security requires both dedication and commitment. 2004 can be a good year if you expect security problems and then develop specific plans to address each of them. After the basics have been addressed, now is the time to establish a routine thatwill ensure security is addressed on a reoccurring basis rather than waiting for problems to surface. To maintain proper Linux security, it must be a regular part of an organization's operational maintenance. Being the beginning of a new year, it is now the perfect time to establish routines that will promote greater security. Linux is a wonderful operating system and holds a huge amount of potential. Security should not be major concern as long as it is handled properly. . Master essential approaches to Linux security control, including timely updates and routine procedures, to guarantee continuous protection during 2004.. Linux Management, Security Practices, System Hardening. . Brittany Day
Jan 06, 2004
•
102
security advisorysystem hardeningLinux administrationDaniel Swan Discusses Linux FAQ: Security Solutions for Admins
Daniel Swan's tireless efforts come to fruition after many months of development of the comp.os.linux.security FAQ. LinuxSecurity.com speaks with Daniel about his FAQ and Linux security.. R ecently I had an opportunity to speak with Daniel Swan, author of the comp.os.linux.security FAQ. Daniel announces his FAQ after spending the last several months writing and researching the information necessary to provide a Linux administrator with the information necessary to secure his Linux box. LinuxSecurity.com: Why did you decide to write the FAQ? Daniel Swan: During the course of my participation in comp.os.linux.security, I saw many of the same questions being asked, questions that were often Linux specific, and not covered within other security FAQs. LinuxSecurity.com: Who are your target audience and why? Daniel Swan: The FAQ is geared towards intermediate to experienced Linux users. They are in a much better position to understand the issues discussed within the FAQ, and to properly implement the solutions necessary. There is a section geared towards those who want to harden their home box without immersing themselves in the painful details of Linux security. It essentially says "Keep your patchlevels high, and shut down unnecessary services". LinuxSecurity.com: How did you get started with Linux and security? Daniel Swan: Well, my first adult exposure to computers was AIX, while at university, which I instantly fell in love with. The combined complexity, power, and arcane feel of Unix really spoke to me. Several years later, I learned that I could have Unix at home and for free, and downloaded Slackware. After Slackware, the next step was Red Hat. My interest in security was born of necessity. My house server was remotely rooted, which really annoyed me. Determined to not let it happen again, I buried myself in Linux security for several months, reading all I could, and participating incomp.os.linux.security. LinuxSecurity.com: What are your future plans for the FAQ? Daniel Swan: Kernel 2.4 is going to open up a whole new kettle of fish, as will the recent release of dsniff. Many of the firewall configuration statements will need to be updated to include syntax for the new iptables. Things are changing so fast, it will be enough of a challenge just to keep the FAQ up to date. I also want to cover backup and mirroring methods in future versions of the FAQ. Solid backups are quintessential to the security of a system. This is painfully overlooked these days, with the focus so much on the network component of security. Also to be covered is encryption, such as PGP, GPG , or filesystem encryption. I'm not happy with these sections to date, and they were cut from the present version of the FAQ. Also covered will be logfile monitoring tools and methods. LinuxSecurity.com: What are some of the major pitfalls Linux Administrators fall into? How can your FAQ help to avoid these problems? Daniel Swan: I believe that the greatest pitfall a Linux Administrator could make is to assume that their box is completely secure, and the second greatest pitfall is to fail to keep current backups. I have been bitten by both. I also feel there is an overemphasis on the minutiae of computer security by many Linux Administrators, without understanding security in a holistic sense. My goal in writing the FAQ was to impart an understanding of some of the conceptual issues surrounding computer security, and to facilitate and encourage further learning. LinuxSecurity.com: What do you feel is the most common Linux system vulnerability? What can be done to prevent this? Daniel Swan: Well, the vulnerability du jour changes so frequently, it would be a disservice for me to suggest that readers protect themselves against a single particular sploit or vulnerability. They would be much better off to learn thepractices of good computer hygine, such as keeping patchlevels current for their distribution, minimizing network services offered, using strong passwords, etc, etc, etc. Good habits of this nature will serve not only to protect them against known threats, but also against those that have not yet made it to Bugtraq. LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix? Daniel Swan: I do. However, to make full use of this, Linux must yet come under the intense scrutiny of a collective code review of not just the kernel, but supporting applications, such as has been done with OpenBSD. I think there's room here for another Distribution which does this, which by necessity will always be a couple of steps behind the latest and greatest release, but can offer greater security in a default installation. LinuxSecurity.com: Thanks very much for the opportunity to speak with you, and wish you all the best. The comp.os.linux.security FAQ and other authoritative Linux security documents can be found in our documentation section. . Explore Daniel Swan's insights on enhancing the comp.os.linux.security FAQ to elevate Linux security awareness among system admins through effective strategies and community collaboration.. Linux Administration,System Hardening,Security Practices,FAQ,Linux Solutions. . Brittany Day
Jan 01, 2001
•
102
intrusion detectionsystem hardeningsecurity hardeningJay Beale Discusses Bastille Project: Effective Linux Hardening
Jay Beale talks about his efforts as lead developer of one of the hottest projects in the Internet security space today.. R ecently I got an opportunity to speak with Jay Beale, the Lead Developer of the Bastille Project. Jay is the author of several articles on Unix/Linux security, along with the upcoming book "Securing Linux the Bastille Way," to be published by Addison Wesley. At his day job, Jay is a security admin working on Solaris and Linux boxes. You can learn more about his articles, talks and favorite security links via . LinuxSecurity.com: Can you briefly describe the bastille-linux project? What is the goal/objective of bastille? Jay Beale: Bastille Linux is a project to harden, or "lock-down," Linux systems. It asks the user a number of questions, which it uses to provide the most comprehensive security, without removing needed functionality. We're trying to make a more secure environment for every class of user, without restricting them too much. We've been very successful so far - Bastille can stop almost every single root grab vulnerability that I know of against Red Hat 6.x. In the case of the well-known BIND remote root vulnerability, we had secured against that one before it was even discovered! LinuxSecurity.com: How was it started? Jay Beale: Bastille started about almost two years ago, when Jon Lasser began making UMBC Linux, a secure distribution that he could give out to students and faculty, without worrying that their new boxes would be quickly "rooted." While at a SANS conference, he met a number of people who were doing the same thing. Through a beer-enabled Birds of a Feather (BoF) session, they decided to stop duplicating effort, banding together to create the new Bastille Linux distribution. Fast forward a few months. As many would-be distribution makers quickly learn, this group found out that making a new distribution was very hard work, before you even tried to secure it. They shifted strategy, and instead decided tomodify the existing Red Hat distribution. This was faster and could be far more comprehensive. I joined up then, bringing a rather long Perl script with me that would turn a virgin Red Hat 6.0 box into more secure one. Jon and I became partners, Lead Coordinator and Lead Developer, and I posted a "modules wanted" sign in the form of a Spec Document for the script. At that point, we were joined by the people that make up our core team, including Pete Watkins, who brought his strong and comprehensive IPCHAINS firewall, Sweth Chandramouli, who's helping me with architecture design, and Mike Rash, who's working on Intrusion Detection. We've got a great team on board, really, with a number of people dedicated to testing Bastille and generating ideas. LinuxSecurity.com: Can you describe your background? How long have you been involved with security and Linux? Jay Beale: Two years ago, I was a mathematician with an interest in computing and physics. I became interested in computer security when I took my first sysadmin job about two years ago. Security is one of the few areas of computing that is rather complex - yet, there's an underlying structure running through the entire field. It really fascinated me from the beginning, so I read everything I could find and started tinkering at home and at work. Later on, I began working as a security admin., doing everything from writing host-based Intrusion Detection, to handling hacker break-ins, to writing hardening scripts. Bastille's main module development started as an extension of ideas I implemented for Solaris, actually. Now, I'm writing a book on applied Linux Security for Addison Wesley and writing articles for various sites, in addition to keeping up with Bastille, which is no small task. LinuxSecurity.com: Do you ever expect vendors to ship Linux in a configuration that obviates the need for such a project? Jay Beale: This really is possible, though it's a long shot... The problem is that users need theirsystems to "work" and, more and more, they don't have the time to tinker with them a great deal first. So, most vendors ship with ftp on, Apache with server-side-includes/cgi enabled, and no password on single user mode. You see, to secure a system, you'll have to remove some functionality. This is due to a basic premise of computer security: to fully secure a system, you really have to grind it into dust, scatter the pieces to the wind, and hope that Entropy does it's part. Since you can't do this, you make tradeoffs. I think things like Bastille will always be around for three reasons. First, vendors have incentives to make systems easy to use - Bastille works against this, but educates the admin/user to compensate. Second, we're going to keep researching, creating and implementing ideas before the vendors. Third, much of what we do isn't necessarily the vendor's "job" - implementing an intrusion detection system is usually a third party function. Bastille does a great deal to systems and we're about to start doing even more - we're growing beyond a simple hardening system into more facets of system security. LinuxSecurity.com: What are the most difficult challenges you've faced while developing it? Jay Beale: The toughest problems are really in the architecture, rather than features. Bastille's original goal to make a new distribution, press our own CD's and such. Then, we were still making a new distro, by installing Red Hat and modifying that directly after install. Now, we can modify a year-old system, but that took an architecture overhaul and an intense code audit to implement. This wasn't so much an added feature, as the problem was getting redefined after we implemented our first solution! Actually, another problem that we're considering over time is that as Bastille does more and more, it has to ask a lot more questions! Right now, if you read all the explanations, it takes about an hour to run through the interactive portion. It's nowhere near as bad asa Linux kernel, but it annoys some users who just want a quick fix. Rather than abandoning these users, we're making "One Shot" configurations, where they can choose a sample configuration that matches their own and deploy that. While they miss a crucial part of securing the system (Secure the Admin!) they still get a safer system... LinuxSecurity.com: What type of user would be most interested in running bastille? Jay Beale: I think Bastille is accessible to every class of user, from the newbie to experienced admins. Every class of user tends to find it more comprehensive than anything they do by hand. Newbies find it useful because it explains everything it wants to do and asks questions, so as not to break anything. Experienced sysadmins find it useful because it automates what would normally take many man-hours, especially when you scale it to hundreds of systems. Further, many experienced sysadmins haven't ever had the time to learn about or implement security on their systems. They find themselves trying to make time, in the middle of the night, right after someone "hacks" their systems. LinuxSecurity.com: What do you think of the state of security today on Linux? Jay Beale: I think Linux security is getting better, but we're in a tough arena. Given the accessibility of Linux, most crackers have it on hand and are coding exploits for it first. Using Open source makes a program that much easier to audit for holes, so people are discovering some of the vulnerabilities very quickly and not all of them are White Hats. It's also a difficult situation, in that development is moving so much faster than audits. Honestly, we've also got an amazing advantage: we've got the numbers, baby. The "Ping of Death" vulnerability was corrected in, if reports are to be believed, 1 hour for Linux. No vendor came close to that! While Linux may have had many more security vulnerabilities than Solaris in the past three years, these holes get patched a whole lot faster. KurtSeifried's report on this noted that while Sun has, on average, only six announced vulnerabilities per year, it takes then around 90 days to fix them - this doesn't even account for all the programs, like WU-ftpd or BIND 8, that you generally add to a Sun box. The thing to remember, though, is that every operating system will have holes. It is human nature to make mistakes, no matter how many geniuses work on a system. Further, there are many creative, bright people in the cracking community - they will win many battles here. LinuxSecurity.com: What features does it offer the average Linux user? Jay Beale: Bastille is very accessible to the average user. It doesn't just start securing, but instead asks permission for every step it takes. Further, it educates. This key feature came out of a design problem I faced about a quarter way through writing the first script. The average Linux user tends to install their distro with everything installed and everything turned on, because they're not sure what it all does and they don't want to miss something. Bastille was asking the user questions, like "can we disable routing daemons?" when we hadn't explained what a routing daemon was or why they shouldn't need one. Pete and I ended up writing explanations for each question, so anyone could make educated choices, whether they were a newbie or an experienced sysadmin. Bastille also has lots of other nice features: it can be re-run to keep a system secure after patches, everything it does can be undone, and it's fairly comprehensive. It tightens user account security, configures a well-tuned firewall, configures Apache, makes sane boot security choices, configures some smart PAM options, chroot's your DNS server, restricts access within your FTP server, sets better file permissions and audits your Set-UID root programs. It also configures stronger logging, locks down Sendmail a bit, and tries to turn off services and daemons that you don't need. This is really just the start,though! We're expanding this right now with new modules, including a basic network IDS system and a number of other modules under development. LinuxSecurity.com: What new features are you working on? Jay Beale: Expect some really incredible news on this in a few months. We're kicking around some great architecture ideas with the help of Yoann Vandoorselaere, from Mandrake. Sweth and others are helping us move rapidly to support far more than just Red Hat and Mandrake. We're eyeing FreeBSD, Solaris, Irix, Slackware, Debian and everything we can possibly generalize this to. LinuxSecurity.com: What do you think are the biggest security concerns with using Linux today? Jay Beale: Honestly, there aren't too many other security concerns that are specific to Linux. All of it generalizes to Unix and most of it applies to operating systems as a whole. I think too many programs run with superuser privilege. We can kludge this, the way we do with programs that drop privilege, but we can also stop making this an all-or-nothing, user-or-root game. We should think beyond the basic security mechanisms present in Unix/Linux. Let's start implementing our programs using capabilities and dropping the number of programs on the system which use root. Actually, I think computer security as a whole is a very tough problem. We're trying to make computers easier and easier to use, often at the cost of security. Cracker activity has grown immensely, as many more would-be script kiddies get Internet access. When I got my first shell account, the Internet was well known mostly among the University crowd - now, everyone's got access to the Internet and it's becoming a rougher neighborhood. I'm not saying world-wide Internet access is bad - it's an amazing resource, but one that some people are choosing to abuse. LinuxSecurity.com: Security is always about tradeoffs. What tradeoffs do you face while developing bastille? Certainly it would be easiest to just remove rlogin, telnet,and other inherently-insecure programs, but this isn't always possible. Jay Beale: Well, I think we've got a nice solution here. We're letting the user decide what tradeoffs to make and we're providing the user with the background to make that decision. Bastille is highly granular, taking many actions and asking the user about each one. In the end, the user decides whether or not to kill telnet, but we try to help them make an educated decision, by presenting facts like these: telnet is cleartext, so that someone eavesdropping can steal your account from under you - using programs like hunt, they can even steal your entire session! Educating the end-user and letting them make all the decisions was a new approach, but we felt it was the only one that worked for a community as diverse in background as the Linux community. LinuxSecurity.com: Thanks for taking the time with us today, and we wish you and your team members the greatest of success with this project! . Explore perspectives from Jay Beale regarding the Bastille Project and its significance in fortifying Linux systems against various security vulnerabilities.. Linux Hardening, Bastille Project, System Security, Jay Beale, Intrusion Detection. . Brittany Day
Jul 14, 2000
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
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!