Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×
Stay Ahead With Linux Security Features
security advisory update A large volume of Linux security updates and advisories this week across major distributions once again, but it wasn't just the volume that was the story. Where maintainers and security teams focused their attention was evident in the concentration of fixes targeting Linux kernel updates, identity services, DNS infrastructure, and internet-facing software. . Instead of looking at each advisory in isolation, administrators gain more value from the general trends they reveal about Linux security...
Jul 23, 2026
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
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 0 articles for you...
218
open source softwaresecurity challengescommunity trustExploring Open Source Security Challenges Benefits for Developers
Open-source security sits right in the middle of how we build software now. Most teams grab code from public repos, plug it in, and move fast. That’s fine until something deep in the stack breaks or turns out to be risky. Transparency helps, but that value depends on the people behind it. . At its core, open-source security is about keeping track of what you’re using and how safe it really is. It’s not just patching when a CVE drops. It’s knowing your dependencies, watching for abandoned projects, and spotting weak code before it becomes a bigger problem. We’ll go through the tradeoffs. Why open-source stays essential, where it trips people up, and what the community’s learned from real incidents. Then we’ll get into how teams can keep using open code without opening the door too wide. Overview & History of Open-Source Security When community-driven code-first took off, the real meaning of open-source security began to take shape. Early open-source projects made transparency and collaboration the basis of how software was built and maintained. Code stayed open for review, changes visible to everyone, which helped surface flaws faster and build trust in the process. The rise of projects like Linux, Apache HTTP Server, and OpenSSL set the pattern for community trust and faster patching cycles. Linux showed what a distributed review could look like. Apache built a governance model that kept collaboration organized. OpenSSL reminded everyone what happens when critical code runs without enough resources or oversight. Together, these projects shaped how we think about open-source security today. Key Milestones in Open-Source Security Year Event Security Significance 1985 Free Software Foundation founded Established the principle of peer-reviewed, open development. 1989 GNU General Public License introduced Ensured transparency and shared rights to audit code. 1990s–2000s Linux, Apache, OpenSSL projects grow Pioneered collaborative patching and community-based response models. 2025 Open-source software (OSS) reports highlight ubiquity and governance shift The 2025 OSSRA report found that 97% of audited codebases include open-source components. The findings pushed organizations toward tighter governance and better tracking of supply chain risk. Advantages of Open-Source Software Open-source has always been about shared visibility. Anyone can read the code, test it, and fix it. That openness is what gives open-source security its edge. Problems don’t hide for long when thousands of developers use the same libraries every day. Teams also stay in control. They patch when they need to, not when a vendor releases a fix. With the right application security tools, open code becomes a living system that adjusts faster than most commercial software ever could. Transparency Accelerates Detection When code is public, mistakes surface fast. People test, report, and correct issues as part of their daily work. Linus’s Law still applies: “Given enough eyeballs, all bugs are shallow.” That pace is visible in the Linux community. Researchers and maintainers watch the same codebase, often catching small flaws before they reach production. Collaboration Builds Stronger Defenses The best-known application security tools — OWASP ZAP, SonarQube, ClamAV — were built the same way. Openly, by distributed teams that review each other’s work. That rhythm of contribution and critique shortens patch cycles and improves testing coverage. Each project benefits from another. A detection rule refined in one tool shows up somewhere else. Regular security patches and updates keep the loop active. Transparency Prevents Malicious Code It’s hard to hide something malicious when everyone can read the diff. Public review doesn’t stop every bad actor, but itlimits how long bad code can stay unnoticed. That visibility builds quiet trust. Contributors know their work can be checked by anyone. Auditing becomes a habit, not a policy, and trust builds one review at a time. Forking and Independence Preserve Longevity Projects don’t have to die when interest fades. Forking lets them keep moving under new hands. It’s one of the quieter strengths of open-source security, driven by community. LibreOffice carried forward from OpenOffice when updates slowed. LineageOS did the same for Android, keeping security patches alive for devices long past official support. Forking maintains, not just running, which is the difference between old code and abandoned code. Challenges and Limitations of Open-Source Open-source survives on steady maintenance, not just good code. When those people stop, things slow down fast. A lot of projects run on volunteers or small teams with no budget. If they get busy or lose interest, patches stall and bugs linger. That’s the real problem in open-source security, not the code itself, but keeping enough hands on it to stay current. When teams know a project is slowing down, they usually add backups. They’ll deploy network security tools like Snort or Suricata to monitor traffic and flag anything suspicious. It’s a safety net, not a fix. Vulnerability scanning tools help too — Nessus, OpenVAS, whatever you’re running — but they can only point out what’s broken. If no one’s maintaining the code, nothing gets patched. That’s the real gap with open-source. The problems are visible; the question is whether someone’s still there to fix them. Case Studies: When Open-Source Security Failed Open-source works because people stay involved. When they don’t, things slip through. Open-source security depends on steady attention, and that doesn’t always hold. Heartbleed and Shellshock showed what happens when code outlives its oversight. The 2025 supply chain attacks proved it’s not just oldbugs anymore — attackers now go straight after the systems we use to share code. Heartbleed Bug (OpenSSL) The Heartbleed bug hit OpenSSL in 2014. It had been sitting in the code for years, missed by everyone. A few volunteers were keeping the project afloat with almost no funding. When the flaw came out, it forced emergency patching across most of the internet. It was a turning point. After that, companies began investing real money in the projects they relied on. Open-source security stopped being something everyone assumed “just worked.” Shellshock (Bash) Shellshock surfaced a few months later. The bug had been in Bash for decades, hiding in plain sight. People trusted it because it was old and familiar. Once exposed, it spread fast and forced admins to rethink what “stable” really means. The takeaway was simple. Even legacy code needs structured testing and reviews. Age doesn’t equal safety. 2025 Supply Chain Attacks (NPM, PyPI, Docker Hub) In 2025, attackers went after the source instead of the code. They got into developer accounts on NPM, PyPI, and Docker Hub , then pushed poisoned updates straight into trusted packages. Some of those updates had millions of downloads before anyone caught them. That changed how people handle releases. Teams started locking down who could publish, signing builds, and tracking dependencies tightly. It made everyone realize open-source security isn’t just about fixing bugs — it’s about securing the path that code takes to production. What These Incidents Changed Transparency helps, but only if people stay engaged. Legacy code carries risk just like new projects do. Funding and structured review matter more than trust. Supply chain defense is now part of everyday maintenance. Strengthening Open-Source Through Better Management Most teams learn the same thing the hard way — staying secure isn’t just about code. It’s about process. Good open-source security comes from maintaining updates,regularly scanning, and restricting access to what is needed. A few habits make the biggest difference. Automate what you can. Tools like Ansible and Puppet handle repetitive updates faster than humans ever will. Automation maintains systems and closes the gap between patch release and deployment. Run regular scans. Use application security tools such as OpenVAS or Nessus to identify weak spots early. These scans detect configuration drift and outdated dependencies before they become incidents. Layer your defenses . Pair those scanners with network security tools and continuous monitoring. Each layer catches what the others miss, such as traffic anomalies, misconfigured endpoints, and unpatched services. Tighten access. Role-based access control and least privilege go a long way toward security. Fewer admin rights mean fewer attack paths. It’s basic, but it works. It’s steady management, the kind that holds the rest of your security together. Global Initiatives Strengthening Open-Source Security The push to improve open-source security has gone global. Groups like the OpenSSF now fund audits, education, and full-time maintainers for critical projects. Bug bounty programs pull in fresh eyes, and training helps developers spot problems before they commit them. CI/CD systems play a significant role as well. Integrated testing and automated release checks keep patches moving fast through CI/CD pipelines , closing gaps before they reach production. Together, these efforts are turning open-source maintenance into a shared responsibility — not just for communities, but for the entire software ecosystem. Takeaway: The Future of Open-Source Security Open-source has always worked because people care enough to maintain it. Someone still has to patch, test, and manage the flow of updates. When that slips, so does open-source security. The path forward’s pretty simple. Keep the collaboration, but add structure. Fund the projects you rely on. Make maintenanceroutine, not a side task. That’s what keeps the ecosystem healthy and predictable. We’ll keep depending on open-source; that’s not changing. The question now is whether we’ll keep supporting it the way it needs. Do the benefits of OSS outweigh the risks? Connect with us @lnxsec . . Explore the challenges and benefits of open-source security, emphasizing the need for community involvement and effective management.. open source software security, collaborative development, software risks, community trust. . MaK Ulac
Nov 03, 2025
•
102
security auditssecurity challengesbug bountyOpen Source Security: Addressing Challenges and Embracing Benefits
Open-source software (OSS) adoption has increased dramatically over recent years due to its flexibility and cost-cutting benefits, but whether or not OSS is completely safe is often controversial. Due to its open and collaborative nature, this type of software presents unique advantages and security challenges. . In this article, we will explore both sides of OSS security: its notable advantages and potential drawbacks. We will examine real-life examples of security problems faced by OSS projects and proactive measures being implemented to enhance their protection. By considering both sides, our objective is to give developers and Linux administrators a more holistic understanding of the risks and rewards associated with Open Source. Let's begin by examining some advantages and challenges of adopting OSS. Overview & History of Open-Source Security Open source software (OSS) has long been an essential element of the digital ecosystem, providing transparency and collaborative development to enhance software quality and security. Open Source has its roots in computing history since 1985 when Richard Stallman established the Free Software Foundation and the subsequent creation of the GNU General Public License . Transparency of source code permits thorough security audits by the global community, speeding up the identification and resolution of vulnerabilities faster than closed-source models. Community involvement has increased the adoption of open-source software (OSS) solutions within enterprise environments. Security has always been at the core of open-source software adoption. By permitting anyone to inspect, modify, and improve source code directly, open-source projects utilize global developer communities as an invaluable resource to quickly detect bugs and vulnerabilities in their source code. Open auditing increases trustworthiness and effectiveness in security measures employed by widely used software such as OpenSSL, Linux, and Apache HTTP Server. Open Source also facilitatesfaster responses to security threats, as evidenced by prompt patches and updates in response to exploits. This proactive approach starkly contrasts with proprietary software, where vulnerabilities often remain concealed for far longer. Furthermore, Open Source provides an effective defense strategy against security risks by harnessing its user base's collective knowledge to build robust and resilient systems. Pros of Open-Source Software (OSS) Open Source Software (OSS) offers numerous advantages, making it a popular choice among developers and users. By adhering to principles like transparency, community participation, and adaptability, OSS creates an environment where software can become more secure, resilient, and tailored precisely to its diverse user base. Pro: Anyone May Access and Implement This Code One of the key advantages of open source software (OSS) is its readily accessible source code. However, this opens it up for anyone to inspect. While this allows potential hackers to examine it for vulnerabilities quickly, this transparency enables engineers and developers worldwide to identify and address them swiftly. Hackers often discover vulnerabilities before company engineers do. Conversely, many eyes on open-source software often expedite the detection of security flaws faster. Community-driven monitoring ensures that vulnerabilities are patched quickly. Companies like Mozilla have taken full advantage of this by opening up their source code to community scrutiny. Linus's Law states, "Given enough eyeballs, all bugs are shallow." This phenomenon illustrates one key security advantage of open-source software (OSS). It indicates how openness and transparency allow a large community of developers and users to quickly analyze code, identify vulnerabilities, and provide patches more rapidly than proprietary systems. This collective review process further enhances the security posture of OSS, as bugs are usually caught and fixed faster than bugs in proprietary code. This phenomenonprotects widely used projects like Linux, Apache, and OpenSSL from exploits. Closed-source software takes a "security by obscurity" approach that relies on concealing its source code from public view in the belief that keeping it hidden reduces vulnerabilities from being discovered by malicious actors; however, this method relies heavily on internal teams identifying and patching issues, leaving software exposed and vulnerable. While security by obscurity provides some level of defense through concealment, critics have frequently noted it gives a false sense of security without the community validation that is vital to open source projects' resilience. Pro: Community Participation and Collaboration Open-source software thrives within a collaborative ecosystem where users can provide feedback on fixes, improvements, and new features - an aspect of software development unparalleled in proprietary systems. Mozilla Firefox, an open-source web browser, derives excellent value from its community. Users are encouraged to report bugs, suggest added features, or contribute code directly. Such collaboration helps develop more secure software as users are incentivized to keep it as safe and functional as possible. Pro: Transparency Protects from Malicious Code Hidden Within Frameworks Another significant advantage of open source software (OSS) is that it prevents malicious code from being hidden within software applications. Since all code is readily available for inspection, harmful elements will likely not go undetected and cause harm. With proprietary software, companies have been caught misusing user data. For instance, even when Incognito mode was active, Google was recently exposed for collecting Chrome browsing data. Such practices are difficult to hide when dealing with open-source software, making it more trustworthy. Furthermore, its transparency ensures users understand exactly what their software does, while experts can audit its code for any potentially illicit activities. Pro: Forkingis Used to Rescue Abandoned Projects Software abandonment is a perennial problem. Developers may stop updating and maintaining their programs due to various circumstances. With Open source, "forking" comes to the rescue: taking an existing project and altering it in some way to form new opportunities. LibreOffice was forked from OpenOffice and continues to thrive today. Forking ensures that even if its original developers leave behind an abandoned project, its community can maintain and improve it while addressing security vulnerabilities. Pro: Independent of Any One Company OSS does not depend on a single entity. In contrast, proprietary software relies on an organization, and users who stop receiving support may find themselves without options. With Open Source, even if its original creators abandon their project, the community can take over and continue developing it. LineageOS is an operating system that extends the lifespan of Android devices by offering security updates even after their manufacturer has discontinued support, thus assuring users continue receiving security patches and updates. Cons of Open-Source Software Open Source Software (OSS) offers many advantages, yet it can also have drawbacks that threaten its sustainability and security. Limited resources and community support may hinder OSS' consistency and reliability compared to its proprietary alternatives. Con: Limited Resources While open-source communities are vibrant and vital, many operate with limited resources. Many developers and maintainers work for free out of passion rather than profit. Research indicates that 60% of OSS creators and maintainers are unpaid, and many considered quitting due to financial pressures. Limited funding can negatively impact security updates without adequate resources to maintain and secure open-source software in parallel with proprietary products from well-funded corporations. Con: Risk of Abandonment Though forking provides an escape hatch, project abandonmentremains a real danger. Not all open-source projects can attract enough of a community capable of revitalizing or maintaining them. Smaller projects, particularly, may become obsolete if their original developers lose interest or time supporting them. Abandonment can leave security vulnerabilities unpatched, creating a considerable threat for users who rely on these smaller open-source projects. Con: Dependence on Community for Security OSS security relies heavily on community engagement. While larger communities can help identify and address security issues more quickly, smaller projects or those with lesser appeal might not receive as much consideration, leaving potential vulnerabilities unchecked and the software vulnerable to possible attacks. Examples of Security Concerns in Open-Source Software Although open-source security offers many advantages, it still has vulnerabilities that should be managed carefully. Perhaps most infamously, the Heartbleed bug in the OpenSSL cryptographic library affected millions of systems worldwide for two years before its discovery. Shellshock , a series of security bugs in the Unix Bash shell, also revealed the risks associated with open-source software. Both incidents highlighted how vulnerabilities exist despite the software's open nature. The Critical Role of Responsible Management in Open-Source Security The secure management of open-source projects is crucial for Linux admins and developers. Proactive strategies help reduce risks associated with known vulnerabilities or exploits in OSS. One essential practice is regularly reviewing and applying security patches and updates . Open-source projects benefit from global community vigilance, and updates for vulnerabilities typically become available quickly. Still, timely implementation of patches is vital to ensure systems don't become vulnerable to attacks leading to compromise. Automated tools such as Ansible or Puppet can make this process faster and provide consistent and efficientdeployment of security updates across multiple systems. Regular security audits and vulnerability assessments using tools like OpenVAS or Nessus are also vital to keeping systems secure. They can assist in rapidly detecting vulnerabilities that exist within your systems. Another crucial best practice involves employing role-based access control (RBAC) and adhering to the least privilege (PoLP) principle to limit access to critical components and data. Proper configuration management and inventorying of all open-source components within your environment is key to providing oversight and quickly responding to emerging security threats. You can increase open-source infrastructures' security posture and resilience by embedding these practices into daily operations. Measures & Initiatives Being Taken to Increase Open-Source Software Security Several measures have now often been implemented to strengthen open-source software security. One such measure is regular security audits experts conduct to detect and mitigate vulnerabilities before hackers can exploit them. Furthermore, bug bounty programs incentivize community members to find security issues by offering financial rewards. Popular projects such as Mozilla Firefox and Linux have utilized bug bounty programs effectively to address numerous security problems. Integrated code review processes are another effective strategy. They employ multiple experts to examine each contribution before it is merged, ensuring higher code quality and security. Automated testing frameworks further boost this effort, running thorough security checks on every code change to detect potential vulnerabilities early. Continuous Integration/Continuous Deployment (CI/CD) pipelines also strengthen open-source software security by continually testing and deploying code without the risk of introducing new vulnerabilities into development pipelines. Ongoing education and security training for developers and the community also play an integral role in strengthening thesecurity of open-source software. Many open-source communities offer regular training sessions, webinars, and workshops on secure coding practices to keep users up-to-date. By educating our users on best security practices, we can strengthen the overall security posture of open-source software. Financial support is also crucial to protecting open-source software projects. Initiatives by the Open Source Security Foundation (OpenSSF) offer resources that help maintain and improve open-source security projects. Corporate sponsorships and grants allow developers to devote more resources to improving software security. Our Final Thoughts on the Benefits & Drawbacks of Open-Source Software Open-source software presents both unique advantages and challenges when it comes to security. The openness and transparency of open-source projects play a crucial role in their protection by swiftly identifying vulnerabilities. Unfortunately, other issues, such as limited resources, risk of abandonment, and community support, cannot be ignored when considering security. Although OSS security incidents remain a significant threat, ongoing efforts such as regular code audits, bug bounty programs, automated testing, educational initiatives, and better funding are considerably improving. Furthermore, its collaborative nature continues to transform the landscape, making OSS an attractive and increasingly secure choice for developers and end-users. When managed and supported correctly, open-source software can provide a safe and dependable option, embodying its collaborative spirit at its core. In your opinion, do the security benefits of OSS outweigh the risks? Connect with us @lnxsec and share your thoughts! . Open Source Software security offers transparency and community support but poses challenges like inconsistent quality and compliance risks. Proactive measures boost safety.. Open Source Security, Community Engagement, Bug Bounty Programs, Security Audits, Proactive Measures. . Brittany Day
Dec 04, 2024
•
102
network threatssecurity challengesopen source securityAnalysis of Linux Security Trends and Future Predictions
Linux security is anything but stagnant. Cybercriminals are exploiting the growing popularity of the OS and its powered high-value servers and devices by utilizing new and evolving attacks in network security. Despite the reputation Linux has earned, that of being secure and stable against all forms of network security issues, Linux malware is on the rise. The number of new Linux malware variants reached a record high in the first half of 2022, as researchers discovered nearly 1.7 million samples during this period. . In this article, we will cover a wide range of Linux Security topics, such as current cybersecurity trends, technologies, and policies that are set to shape the next five years of security software and the ever-evolving landscape of open-source security. To gain insights from top experts in the field, we had a seat with Vali Cyber Threat Intelligence Analyst Nathan Montierth and Vali Cyber Co-Founder and CTO Austin Gadient. Gadient is the primary author of Vali Cyber’s product, ZeroLock - the world’s first Linux security product that combines portability, performance, and efficacy into one easy-to-use system. He is also the creator of SecurityPerf, an open-source cloud security framework that determines the impact of security software on production Linux workloads. Before starting Vali, Gadient was an officer in the United States Air Force and developed secure software architectures for America’s satellite infrastructure. Montierth’s work focuses on behavioral identification, technical analysis of modern malware, and offensive methodologies used to develop defensive solutions. He was a cyberwarfare officer in the US Air Force for five years, had extensive cyber operations training, graduated from the AF-Basic Operator Course, and spent three years on the keyboard in operations. LinuxSecurity: Can you speak a bit about the current state of Linux security and your predictions for the future? Specifically, what growing trends have you noticed in malware? Whattechnologies or policies are most important for security software over the next five years and why? Nathan Montierth (NM) : One key security trend I’ve noticed is that Linux network security threats have become more like Windows concerns. The outdated notion that Linux is more secure than other OSes is primarily based on “security through obscurity,” which isn’t much of a valid defense. That entire premise hinges on the idea that less attention is paid to the target. This is increasingly not the case with Linux, so we now see techniques that were previously applied predominantly to more user-centric OSes. Ransomware, bots, and backdoors all seem to be multiplying in the Linux environment. The causality of these cyber security trends could probably be connected to several potential directions, such as the rise of the cloud, increased digitization overall, and higher levels of virtualization. I don’t see these network security issues going anywhere. In the future, I believe that these network security threats will apply to any other OS family that uses Linux. Looking at Linux malware specifically, modern malware campaigns seem much more “business-minded” and systemic. Ransomware strains provide robust real-time “support” to victims, walking them through paying the ransom and hypothetically restoring files. Some services help victims improve their security posture after the ransom is paid and even describe themselves as “consultants.” However, they are arguably more predatory than most who use that title. Perhaps more interesting is the security trend I’ve begun to notice, which is that malware authors seem to focus more on portability. The diverse nature of current hardware and software probably makes it more challenging to engineer effective malware targeting a wide swath of vulnerable devices. We will continue to see malware use victim-native commands and tools rather than newly compiled code. To combat the increasing number and variety of network security threatstargeting Linux, I see the broad adoption of physically based multi-factor authentication becoming one of the best defenses against traditional attacks in network security. The more we can effectively pair traditional authentication methods with authentication based on a physical “thing” in the account holder’s possession, the more widespread remote attacks struggle to find footholds. Of course, this assumes correct implementation. At an organizational policy level, organizations will benefit immensely from routinely role-playing cloud security breaches and incidents in a “fire drill.” Since attacks only seem to be increasing, ensuring that personnel understand and know how to use policies, procedures, and network security toolkits will pay dividends when the incidents happen. Doing this will keep teams from becoming complacent or inexperienced and should reduce the overall impact of attacks on network security. LS: What's your favorite open-source tool and why? Austin Gadient (AG): I am a massive fan of MITRE Caldera . Caldera enables repeatable, measurable efficacy testing to determine how different network security toolkits perform while detecting adversary behavior across the MITRE ATT&CK framework. Another tool I love is SecurityPerf . Of course, I am very biased since I am the creator. However, I love SecurityPerf for the same reasons I love MITRE Caldera. While Caldera provides a repeatable, measurable efficacy test, SecurityPerf provides a performance test. Using SecurityPerf, we’ve found many issues in the performance of different security products and system configurations that would have caused problems in protecting data and network security. LS: What are some of the most significant flaws in existing Linux security tools? NM: The most significant flaw is that Linux endpoint security solutions lag behind the latest Windows endpoint data and network security solutions. The focus hasn’t been on Linux. Existing solutions rely on signatures for detection, whichis the traditional malware detection method, and it requires a person to certify a software signature as malicious. Additionally, the most influential Linux solutions have a very costly resource overhead. Your processing power will take a massive hit for the added efficacy, which at the end of the day, will be a business expense of its own, reducing the product's value. SecurityPerf is a great way to validate this and evaluate the value of any given security system versus any network security issues that could head your way. LS: eBPF is all the rage. What are your thoughts on the technology from a defensive security perspective? AG: eBPF was initially developed as a diagnostic tool. It provides excellent access to low-level kernel event information in a more performant way than other methods such as auditd. However, eBPF is very easy to circumvent from an attacker’s perspective. Even an unprivileged attacker can bypass eBPF-based system call information by overloading the maps used to communicate between an eBPF program and userspace. Furthermore, the eBPF verifier has vast numbers of CVEs against it, making enabling the feature a risk to data and network security. eBPF is an excellent tool for diagnostics but has significant drawbacks when used in security products. LS: How is Vali Cyber revolutionizing Linux security? AG: Vali Cyber provides three primary offerings to the Linux security market. The first and foremost is ZeroLock , a novel runtime detection and response system that combines high portability, efficacy, and performance into one application. The second is SecurityPerf, an open-source network security toolkit that allows organizations to determine the performance impact of a security solution on their workloads. We have used SecurityPerf extensively in PoCs to show customers how their existing solution is causing massive performance impacts, significantly increasing their computing costs. Finally, Vali Cyber is pioneering the concept of self-protecting containersthrough work with the United States Air Force and Space Force. Every deployed container should have some level of runtime security associated with it. ZeroLock provides that protection natively and embeds it directly into container images to ensure they are always protected against the latest network security threats while deployed. ZeroLock's protection extends from desktop Linux systems to LAMP stacks targeted by WordPress web shells. We are actively securing WordPress security vulnerabilities, messaging queues, and other high-volume applications. LS: What does ZeroLock do for the Linux security market? What are the real-world and cost impacts? AG: ZeroLock provides the only Linux security solution that combines portability, performance, and efficacy into a single package. ZeroLock can deploy on any Linux system if the kernel version is 3.5+. Additionally, ZeroLock has unparalleled performance and significantly reduces memory and CPU usage. These claims are easily verifiable with SecurityPerf, an open-source tool we’ve developed to measure system performance that is freely available on GitHub . ZeroLock does not rely on signatures to detect attacks in network security. Instead, ZeroLock uses Artificial Intelligence and Machine Learning behavioral detection out of the box. This approach makes ZeroLock’s detection far more future-proof than the adjustments attackers make to their malware through obfuscation. LS: I see you have a podcast together. Tell me about your podcast. What led you to start it? Where can people listen to your podcast? NM: Yes! Our podcast is called ROP Lobsters, and you can listen on Spotify. Austin and I pool our knowledge and experience to give nuanced takes on information security news, current events, and other cybersecurity trends. We cover hacker techniques and tools, recent attacks in network security, and public policy decisions. We love cybersecurity and enjoy talking together about it. You can find our podcast on Spotify today! Keep Learning AboutLinux Security With attacks in network security on the rise and targeting Linux in recent years, robust Linux security has never been more critical for individuals and organizations. While Linux is heralded for its high levels of data and network security and stability, it is by no means a “silver bullet” in digital security. As previously mentioned, the OS must be correctly and securely configured, and sysadmins must practice secure, responsible administration to prevent further network security issues. Staying informed of the latest cyber security trends and solutions is vital to protecting Linux environments against attacks that could lead to compromise. We hope the information and insights provided in this article have given you a better understanding of the evolution of Linux security, what to expect in the coming years, and the type of protection required to secure against malware and other persistent and dynamic network security threats Linux users face. Learn about the history of Linux malware and what’s being done to stop it. Get tips and advice for securing your Linux system. Learn about open-source vulnerability assessment network security toolkits and scanners to help improve your vulnerability management strategy. Learn about container security considerations and best practices in our Linux Container Security Primer. Have a question that wasn’t covered in this interview? Connect with us on social media, and we’ll provide you with the information you seek! Twitter | Facebook | LinkedIn . Investigate key perspectives on Linux cybersecurity patterns, hurdles, and forecasts from specialists concerning the landscape of network protection.. Linux Security Trends, Cybersecurity Analysis, Malware Insights, Open Source Security. . Brittany Day
Aug 02, 2023
•
102
open source toolsautomationsecurity challengesAddressing API Security Challenges With Automation and Open-Source Tools
Thank you to Anastasios Arampatzis for contributing this article. With web and API security becoming an increasingly important aspect of software development, “shift left” is gaining wide acceptance as a best practice to ensure security integrates with development early. More and more cybersecurity companies are releasing relevant products and capabilities, and the practice is becoming almost de facto for engineering teams. . However, the software industry has begun to realize that simply “shifting left” is not enough for a continuous delivery world. High velocity development teams are embracing a security approach where security is addressed starting from the first line of code. This means product security isn’t just delivered by the developer team but is rather owned by them. Balancing security with development is easier said than done. Many challenges are impeding the process. Developers in communities talk about these challenges and it is wise to listen to them. Challenges of API Security Agile Development and Short Lifecycles “The biggest challenge is that development is agile, and they are using small lifecycles,” says Yiannis Koukouras, Managing Director at TwelveSec. “Developers have a sprint of two weeks to deliver the product with very little time to spend on security. I have seen apps being finished in just eight days and then they only have two days to test the finished product,” explains Koukouras. “You just don’t have time to build secure systems,” admits stemid85 on Reddit. Businesses are always pushing the boundaries to meet time to market demands, and developers are forced to “do the bare minimum so you can move on to the next task.” Lack of Perception and Understanding Many developers do not speak security. Lack of understanding the risk environment ends up on security oversight, resulting in flawed products. Understanding how to build a secure architecture to support your development is the number one challenge according to faisent .“Production resources should be secure AND scalable AND highly available,” adds robindownes. However, the same individual agrees that “all of my developers seem to think that this is a ‘spin the bottle and pick one’ sort of choice.” Authentication and Secrets Management With highly automated deployments, understanding what an API gateway is becomes critical as it helps manage and secure API traffic alongside secrets management and tight access controls. Secrets may include API tokens, SSH keys, privileged account credentials, etc. Containers, services, employees might use these, and many more entities. API gateways are pivotal in ensuring these secrets are not exposed and remain secure from attackers. “Unfortunately, these critical passwords and keys are often poorly managed (exposed) and are frequent targets of attackers,” notes Joy Winter . Poor secrets management ends up in secrets sprawl, limited visibility into your inventories, opening thus the door to malicious actors to literally log into your app and compromise sensitive data. The Human Factor Behind every software project are humans. We need to empower our people to embrace a security culture, and we need to provide them with the tools that can really help them apply security effectively and effortlessly at every step of the pipeline. How Can Security Teams Spend Less Time on API Security? The solution to all these challenges is to automate all security decisions, centralize API security management and eliminate the human factor. Instead of having a human to identify and decide on every single case, AI and machine learning can be leveraged to keep track of the fast pace of web API changes. Once security teams deploy automated, sophisticated, and centralized mechanisms they can gain insights to the problem rather than looking for a pattern. “The best approach will be to do threat modeling, so you know beforehand what kind of security your developers need to implement,” says Yiannis Koukouras. Partnering DevOps andthreat modeling makes business and strategic sense because of the data-rich, gated, and iterative development framework that DevOps offers. The Threat Modeling Manifesto starts with four questions that apply to DevOps projects and all phases of the DevOps lifecycle: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Embedding security within the team can also reduce the time required to secure apps and APIs without slowing down the developers’ pace. “The approach of having a security champion within the team that will take care of questions they have regarding security will help them a lot,” admits Koukouras. Security champions can enforce secure configurations by monitoring the code through automated means. The Power of Open-Source Tools Selecting the right tools for your developers is a crucial decision. Open source security tools are a great addition to the team’s arsenal, since they help them address most of the challenges discussed before. However, not all tools are created equal, and there are quite a few open source security tools that are friendly for the hectic pace of software development, but also provide much-needed security controls early in the development cycle. One of the greatest benefits of open source tools is that they are free to use. You can try a tool out locally without having to commit to it. Instead of lengthy selection processes, you can simply try it out and see how you like it. In addition, and this is particularly critical for security tools, they provide you access to the entire codebase, so that you have full visibility into the features and the actions the tool is performing when running it in your environment. As a concluding thought, while friendly open source security tools offer great benefits, there is a need to shift existing mindset of tackling the security challenges of API security. We should embrace a mindset of automated orchestration so that developers can own product securitywithout compromising velocity. About the Author Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years’ worth of experience in managing IT projects and evaluating cybersecurity. During his service in the Armed Forces, he was assigned to various key positions in national, NATO and EU headquarters and has been honoured by numerous high-ranking officers for his expertise and professionalism. He was nominated as a certified NATO evaluator for information security. Anastasios’ interests include among others cybersecurity policy and governance, ICS and IoT security, encryption, and certificates management. He is also exploring the human side of cybersecurity - the psychology of security, public education, organizational training programs, and the effect of biases (cultural, heuristic and cognitive) in applying cybersecurity policies and integrating technology into learning. He is intrigued by new challenges, open-minded and flexible. Currently, he works as a cybersecurity content writer for Bora Design. Tassos is a member of the non-profit organization Homo Digitalis. . Explore the urgent issues surrounding API protection and discover how leveraging automation alongside open-source resources can optimize workflows.. API Management, Open Source Security, Automation in Development, Web Application Security, Security Best Practices. Anastasios Arampatzis. Brittany Day
Jun 30, 2022
•
102
security advisorynetwork securityopen source toolsFrank van Vliet Interview on Linux Security Challenges and Solutions
Frank van Vliet is the author of AuditFile, many security advisories, and recently pointed out configuration errors on apache.org.. We thought our readers would be interested in an interview with Frank van Vliet because of the recent paper he and Peter van Dijk released outlining the steps they took to compromise apache.org . Their paper does not point out any new vulnerabilities, it merely shows how simple configuration errors can leave a system susceptible to attack. In this interview Frank explains how he audits a systems security, major pitfalls administrators fall into, and how he attempts to uncover bugs. We believe that everyone can learn something from this interview. Note: Frank uses the alias {} LinuxSecurity: When and how did you gain interest in security? How did you gain your security knowledge? Frank: When I finally switched from Windows to Linux, I spent a lot of time studying the Linux kernel source. When I finished that one I knew C enough to start coding on my own. I started working on my first security project called Auditfile. A kernel patch making it possible to restrict file access per process or per binary. This enabled me to run my apache webserver only allowing it to read default libraries (/lib/*, /usr/lib/*), read its configuration files, htdocs (wwwroot) directory, and only allowing it to write to logfiles with no further access. At the same time I took over control of the security focused group RooT66 and I joined ShellOracle . I spent hours reading various texts and joined Buffer0verfl0w security I also got involved with projects like SecNet http://irc.secnet.org (not finished when writing this). I have done some freelance security jobs for small webhosters LinuxSecurity: When attempting to audit a systems security, what procedure do you follow? Where do you begin? How do you normally gather information? What comes next? Frank: My approach changes as I gain more knowledge. Currently when checking the security of a system, Istart checking the file system (what files are sundown or suidgroup, what files are accessible for what groups, what files are world writable, are their any files with nonpublic information world readable). Next, I try to find out what processes are running as root. Of course the suid root processes are but there are also crontabs or administrators around running binaries so I wrote some tools live monitoring the processes running as root. When having a list of binaries ran as root, I start checking every binary. Are there any known security flaws in it? Are its configuration files and data files accessible by nonroot? If nothing and I am really in the mood and the binary isn't too big I would download the source of it (I really love open-source) and read it to see if I can find any bugs in it. LinuxSecurity: What are some of the major pitfalls Linux Administrators fall into? Frank: It is never enough to download all patches and updates and run latest versions of your software. The group Buffer0verfl0w Security I am in is constantly searching for new bugs in software. Most admins play with things themselves and forget permissions on files or other configuration faults. These things can be like the following backup script: #!/bin/bash for file in /home/* do tar -czf `echo $file | sed -e 's/\/home\///'`.tar.gz $file mv $file.tar.gz /verysecuredirectory/backups done Which means every home directory will be compressed into targz files in the local directory then they got moved to the /verysecuredirectory/backups. But because most umasks aren't set to make new files 600 and most of the times it makes new files world readable, an attack can gain all directories in /home if it just scans most common directories the root is in for .tar.gz files and very fast copies most of it to his own directories before the scripts move it (most of the time this is while it is still compressing into that tar.gz file and it is already readable. Besides those race condition bugs like theprevious ones, there are also administrators that store backups in world readable. And there are always the 'can I trust my network' things. Man in the middle attacks are not very common but are very easy to perform, especially when at the same network segment as the box you attack (could be some other way more insecure box previously hacked). In worst case an attacker on the same segment could broadcast arp who-has packets with the ip of the nameserver the attacked box is using has the MAC address of my NIC. That would mean when the attacked box would try to access the nameserver, it will instead contact the box of the attacker and send its name resolving questions. Then the attack can just reply normally except for the kernel.org domain and have those names resolve to the ip of the box of the attacker. Then have it set up just the same ftpserver as on any other ftp kernel.org box and have it search trojaned Linux kernels and then just wait for a new Linux kernel to be published. LinuxSecurity: Have you exposed any other vulnerabilities, or written any programs related to security? Frank: Well, I wrote auditfile (still working on a newer version, as always) I mentioned in the beginning of this interview that is at . I found a bug and wrote an exploit for bugzilla https://bugzilla.mozilla.org:443/ and working on some other exploits and tools at the moment. LinuxSecurity: How do you normally approach finding security vulnerabilities and writing code to exploit them? Frank: Every language has it's own sets of common bugs the programs can have. For C/C++ are mostly buffer overflows. The only way to find them is to check every buffer in the program and search for any functions done on that buffer and check everything if there is a possibility to exploit it. I wrote some perl scripts to automate a part of this task which I normally use to find the buffers, sizes of those buffers and possible insecure functions (like strcpy and sprintf) done on thosebuffers, saving me a lot of time finding normal overflows. The tricky ones require reading from line 1 to like $ (last line). For perl it are most of the time system or open functions that can be used to execute commands (like system(finger $user) or open($user) where the attacker can set the $user variable). So I normally search for all open, system (system, exec, `, and so on) functions and check arguments to them. Also database functions can be insecure. I know people sending random feeds to their sendmail deamon and catch crashes then backtrace to see what feed caused it and then work there way back from there to the bug. Perhaps someday when I am that desperate to find a bug in some high profile software I would do a thing like that, until then I just read and most of the time you also learn by reading. LinuxSecurity: What do you feel is the most important step in keeping a network secure? Frank: The integrity of the network can be spoiled if only one of the boxes on the network got compromised by a nontrusted person. Most networks get compromised because only one insecure box was on the network. Administrators may want to consider an Intrusion Detection System to monitor all machines on a network. The most important step to keep a network secure is to keep all host secure, this can be done by restricting as much as possible from outside to the network (like only http connections to the httpserver and only ftp connections to the ftpserver and so on) and having and IDS monitoring network traffic. LinuxSecurity: What do you think the most common Linux security vulnerability is? How would you recommend an administrator fix this? Frank: The possibility of easy exploiting of buffer overflows. Most buffer overflows can be stopped by patches like the nonexecutable stack Linux kernel security hardening patch from the Openwall Project and packetstorm to see my 2.3.99-pre5 version of it) patch for the Linux kernel and compiler addons like stackguard. LinuxSecurity: Do you think open-source software has the potential for being more or less secure than closed-source software? Frank: There are two sides to this story, if the same program was available in both open and close sourced version. They are insecure at the same rate. But because you get the source code of the open-source program it is very easy to search for bugs. Then two things happen. The bugs get reported and exploits are made for those bugs. This makes the open source program having less bugs then the same closed source program but also there are more exploits around and there will be more bugs to be found in the future. This doesn't say it is impossible to disassemble the closed source program and find the bugs in that one too. Then the same happens for the close source version but at a slower rate because the source is harder to get and to read (would be ASM instead of easy C or some other fancy language). Open source software is more secure than closed source because good coders can use disassembling techniques on closed source programs to find vulnerabilities. I would rather have the open source version so it can compiled with stackguard. LinuxSecurity: What do you think motivates "black hats" to damage/destruct systems? Frank: It is the kick of gaining access and power motivating the "black hats" to hack systems. The damage and destruct is most of the times done in 2 parts. One part is to make sure they keep their full access and so most binaries are Trojan and so on. This can be because they are mad at the company they just hacked(they wouldn?t pay them for revealing the security bugs they exploited or some other in my opinion lame reason) or just because they really don't care and just want to show off (like the recent DDS attacks). LinuxSecurity: How do you feel about the mass-media's portrayal of 'hacking'? Frank: Most media focuses on the things done by stupid kids mass attacking big servers with DDS networks or doing otherstupid things. This does take the heat off the real hackers. The real hackers that don't hack and don't want to be disturbed at their work of endless coding and tracing through programs. It was because Hardball and I wanted to make a statement about consideration of configuration. The media got us a little attention, we would still be unknown doing endless coding. LinuxSecurity: What do you see is in the future for information security? Frank: I would love to see administrators think twice before installing things on their boxes. Also, having kids on your company network is the last thing you want, especially when they try to trojan your sshdeamon and mess up making some boxes even unusable and forcing to full reinstall of everything because you don't know what was trojanned and what was not. LinuxSecurity: We would like to take a moment to thank Frank for taking time out of his busy schedule to share some of his experiences with us. If you have any questions reguarding this interview, please feel free to drop us an email . As always, if you have any ideas for other interviews, or any suggestions, please let us know. We want to serve you! . We thought our readers would be interested in an interview with This email address is being protecte. frank, vliet, author, auditfile, security, advisories, recently, pointed, confi. . Brittany Day
May 30, 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!