Whether your system is running in a local office or remotely in a data center, security is vital to any environment. Unfortunately, there are often considerable security concerns associated with Linux servers. More and more systems become compromised on a daily basis. And vast amounts of users are unaware that proactive server security measures are required to thwart exposure. It is essential to comply with best practices for Linux security to protect your servers from vulnerabilities and threats.
The lifecycles of computer hardware and software are considerably limited. And businesses may be forced to upgrade due to vulnerabilities posed by the end of life (EOS) products. Finding it hard to move on and make a change, many continue using EOL software and expose themselves to numerous threats and risks.
Most cyber-attacks are financially motivated, so attackers constantly come up with new ways to breach data. While the amount and sophistication of such attacks are constantly increasing, most of them are based on memory-corruption vulnerabilities—a problem that has been persisting over the last four decades. To better fight against cyber-attackers, administrators who understand memory corruption can leverage this knowledge to proactively defend infrastructure. This guide will provide administrators with information to help them better understand memory corruption and the aftermath should an attacker exploit the vulnerability.
Meeting System and Organization Controls (SOC) 2 compliance is more than just a simple process implemented once to pass an audit. Permanent procedural changes are tedious and time-consuming but are necessary to ensure that the organization can pass a SOC 2 audit. It’s more than simply supplying a paper trail to a CPA. You must have the right controls and tools in place to maintain compliance permanently or risk violating compliance standards. Losing SOC 2 compliance isn’t an option for most organizations, but the right tools will keep you compliant and help facilitate continual compliance in future audits.
Since the beginning of KernelCare+ Beta testing, we've been working hard on the automation of the trial and purchase of live patching for shared libraries. Today, we are glad to announce the availability of KernelCare+ Trial and Purchase functionality in CloudLinux Network (CLN). Now you can try KernelCare+ for 7 days and purchase it instantly, through your CLN account.
Google security researchers recently found a flaw in the way the Linux kernel’s Bluetooth implementation handled L2CAP packets with A2MP CID. A remote attacker in range could use this flaw to crash a targeted system causing a denial-of-service or potentially execute arbitrary code on the system by sending a specially crafted L2CAP packet. All Linux distributions are affected, but the exploit is only possible if you have devices connected via Bluetooth to your infrastructure.
No downtime or non-compliant? That is the question for companies that do not use automated patch services. There is no middle ground when it comes to the security of your clients and the well-being of your business. Especially now, when live patching is available not only for Linux kernels but also for Glibc and OpenSSL. KernelCare+ patches shared Glibc and OpenSSL libraries without service restarts or server reboots — and it has already been tested!
With the Linux open-source community, you have the power of developers adding to its codebase improving features and performance. The downside to this approach is that hackers also have access to source code and any vulnerabilities that they find can be used against Linux-based devices including critical servers. Known vulnerabilities are reported to a centralized NIST vulnerability database where vendors, developers, and users can be aware of exploits that affect specific software versions. A Common Vulnerabilities and Exposures (CVE) report is your cue to patch software including the Linux kernel when an issue is found. Note: Not every Linux patch gets a CVE, but you can stay up-to-date with latest updates on kernel.org.
Last year, a CVE-2019-19126 vulnerability was discovered in glibc, where the LD_PREFER_MAP_32BIT_EXEC environment variable is not ignored when running binaries with the setuid flag on x86_64 architectures. This allows an attacker to force the system to utilize only half of the memory (making the system think the software is 32-bit only), thus lowering the amount of memory being used with address space layout randomization (ASLR). This week, an update for glibc has become available for Red Hat Enterprise Linux 7 from the RHEL. But for the update to take effect, all services linked to the glibc library must be restarted, or the system rebooted. We are currently preparing rebootless patches which will be ready for distribution next week.
Every month, the KernelCare team strives to help you never miss a critical patch. This September, we worked extremely hard to swiftly release CVE-2020-14386 patches for your Proxmox 5 & 6 and Ubuntu 16.04 as well as for newer versions. There are also several new useful guides and articles that can help boost the security of your servers in seconds. Sounds like something you can benefit from? Keep on reading for more details!
