Stay Ahead With Linux Security Features
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
cloud security security monitoring Linux rootkits are old, but they never really disappeared. They just stopped attracting the same attention. . Most malware wants to execute and spread. A rootkit wants to stay invisible long enough that nobody notices the compromise until the damage is already done, and on Linux systems, that still works more often than many teams are comfortable admitting. That difference matters because modern infrastructure runs heavily on Linux underneath. Cloud workloads, ESXi hosts, telecom appliances,...
Jun 01, 2026
access control open-source A production Linux server gets rebuilt from an old image. A contractor leaves. A CI/CD job is retired. Months later, the same SSH public keys are still sitting in authorized_keys, silently trusted by root or a service account nobody owns anymore. . That is how SSH key sprawl usually happens. It rarely stems from one obvious failure. Instead, it accumulates through years of small access decisions that never expire. For attackers, those forgotten keys are not clutter; they represent silent SSH...
May 27, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 2 articles for you...
102
open source toolssecurity toolsLinux toolsTop Linux Malware Scanners for Detection and System Hardening
In this blog, we will break down the most relevant examples, so you’ll see exactly what kinds of attacks are active today and why scanning tools are necessary to catch them before they cause damage. . What Types of Malware Do Users and System Administrators Face Today? Linux isn’t immune to attacks, which is why a linux malware scanner is important. The number of linux malware families has grown in recent years. Admins deal with trojans, ransomware, worms, botnets, keyloggers, and rootkits. In some cases, zero-day exploits give attackers a way in before patches are available. Cryptojacking This attack mines cryptocurrency with stolen CPU cycles. On Linux, it often runs quietly on servers or cloud instances where usage spikes can go unnoticed. Certain cryptojacking malware goes as far as killing competing processes to maximize resource usage, a tactic that also makes detection harder — unless a linux malware scanner is in place to catch unusual patterns before they spiral. Newer approaches also use browser-based mining techniques, such as WebAssembly, so even client machines can be pulled into the operation. Xbash Xbash was first reported in 2018. Written in Python, it blended ransomware, cryptomining, and botnet features in one package. While it isn’t dominating headlines in 2025, it remains a reference point for how linux malware evolves. Its design showed early on that attackers would merge multiple techniques to maximize impact, a trend that continues in more recent campaigns and underscores why relying on a linux malware scanner is critical for visibility. XorDDoS XorDDoS is still one of the most active linux malware families. It began by brute-forcing SSH on servers, but newer builds don’t stop there. They hit Docker containers and cloud workloads, adapting to whatever environment gives them reach. Campaigns also rely on fallback servers to keep command-and-control alive, even when some nodes are blocked. The result is a botnet that’s harder to shake off and moreflexible than it was a few years ago — making a dependable linux malware scanner one of the few tools that can reliably spot its activity. The takeaway: Linux malware keeps evolving, and it becomes clearer when you look at how secure Linux is . Attackers usually succeed because of misconfigurations, not the OS. Regular linux malware analysis and consistent use of a trusted linux malware scanner are essential to detect issues early and prevent serious damage. Emerging Linux Threats in 2025 Older malware families are still active, but new names are appearing too. In mid-2025, researchers reported Plague, a malicious PAM module that hides inside authentication and gives attackers a quiet, persistent way back in. Around the same time, PXA Stealer showed up — an infostealer aimed at Linux that goes after browser data, saved passwords, and other sensitive information. XorDDoS hasn’t gone away either. What started as brute-force SSH attacks has stretched into Docker containers and cloud systems. Recent campaigns also rely on fallback servers to keep command-and-control alive even if parts of the network are taken down. Taken together, these examples show how linux malware is no longer just about rootkits or cryptominers. It’s moving toward stealthier, data-driven attacks — and catching them early means relying on a trusted linux malware scanner. The pace of rising malware threats to Linux makes a strong linux malware scanner more critical than ever. What If There's Malware? Choosing the Right Linux Malware Scanner If malware is found or suspected, running a linux malware scanner is the first step. The tools below can help audit your system and uncover traces of compromise. Lynis: Beyond a Linux Malware Scanner Lynis is an open-source auditing tool for UNIX-based systems. While not a dedicated linux malware scanner, it runs a deep security scan, testing defenses and pointing out areas for hardening. Many administrators take it a step further by setting Lynis to run automaticallyon a schedule — a process covered in our guide to automating audits with Lynis . The tool reviews system details, installed packages, and configuration issues. It also checks for weak user accounts, wrong file permissions, firewall settings, and other risks. Key uses: Security auditing – thorough checks with clear recommendations. Compliance testing – verifies systems against security standards. System hardening – practical steps to strengthen defenses. Vulnerability detection – highlights weak points that linux malware could exploit. We demonstrated a full example of this process in our article on performing Linux security audits with Lynis , where common findings and fixes are explained. Lynis works methodically, covering everything from accounts to software to firewall rules. Its reports make it a reliable linux malware scanner for administrators who want a clear view of their system’s security. To see what a full audit report looks like in practice, we broke down each stage in our guide to auditing Linux systems with Lynis . How to install via terminal: root@sage:~# dnf install lynis Note: While the basic setup is simple, there are additional audit modes and options worth knowing. Our Lynis Linux security audit tool guide walks through those details for admins who want full control over the process. How to check Lynis Commands: root@sage:~# lynis -h | grep " " This should output: [ Lynis 3.1.5 ] Lynis comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the terms of the GNU General Public License. See the LICENSE file for details about using this software. 2007-2025, CISOfy - https://cisofy.com/lynis/ Enterprise support available (compliance, plugins, interface and tools) [+] Initializing program Usage: lynis command [options] Command: audit audit system : Perform local security scan audit system remote : Remotesecurity scan audit dockerfile : Analyze Dockerfile show show : Show all commands show version : Show Lynis version show help : Show help update update info : Show update details Options: Alternative system audit modes --forensics : Perform forensics on a running or mounted system --pentest : Non-privileged, show points of interest for pentesting Layout options --no-colors : Don't use colors in output --quiet (-q) : No output --reverse-colors : Optimize color display for light backgrounds --reverse-colours : Optimize colour display for light backgrounds Misc options --debug : Debug logging to screen --no-log : Don't create a log file --profile : Scan the system with the given profile file --view-manpage (--man) : View man page --verbose : Show more details on screen --version (-V) : Display version number and quit --wait : Wait between a set of tests --slow-warning : Threshold for slow test warning in seconds (default 10) Enterprise options --plugindir : Define path of available plugins --upload : Upload data to central node More options available. Run '/usr/bin/lynis show options', or use the man page. Lynis Audit Command: root@sage:~# lynis audit system This should output: [ Lynis 3.1.5 ] ################################################################################ Lynis comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the terms of the GNU General Public License. See the LICENSE file for details about using this software. 2007-2025,CISOfy - https://cisofy.com/lynis/ Enterprise support available (compliance, plugins, interface and tools) ################################################################################ [+] Initializing program ------------------------------------ - Detecting OS... [ DONE ] - Checking profiles... [ DONE ] --------------------------------------------------- Program version: 3.1.5 Operating system: Linux Operating system name: Fedora Linux Operating system version: 42 Kernel version: 6.16.7 Hardware platform: x86_64 Hostname: sage --------------------------------------------------- Profiles: /etc/lynis/default.prf Log file: /var/log/lynis.log Report file: /var/log/lynis-report.dat Report version: 1.0 Plugin directory: /usr/share/lynis/plugins --------------------------------------------------- Auditor: [Not Specified] Language: en Test category: all Test group: all --------------------------------------------------- - Program update status... [ NO UPDATE ] [+] System tools ------------------------------------ - Scanning available tools... - Checking system binaries... [+] Plugins (phase 1) ------------------------------------ Note: plugins have more extensive tests and may take several minutes to complete - Plugins enabled [ NONE ] [+] Boot and services ------------------------------------ - Service Manager [ systemd ] - Checking UEFI boot [ ENABLED ] - Checking Secure Boot [ DISABLED ] - Checking presence GRUB2 [ FOUND ] - Checking for password protection [ OK ] - Checkrunning services (systemctl) [ DONE ] Running the lynis audit system creates two files: lynis.log and lynis-report.dat. On distributions like Ubuntu and Rocky Linux, some of the commands and paths differ — something we explained in our guide to running a Lynis security audit . The log is a record of each test the audit runs and the outcome it reports. The report is more focused, pulling out the issues it detects, listing possible vulnerabilities, and offering suggestions to harden the system. Below is an example of a lynis-report.dat file: report_version_major=1 report_version_minor=0 report_datetime_start=2025-09-22 19:34:08 auditor=[Not Specified] lynis_version=3.1.5 os=Linux os_name=Fedora Linux os_fullname=Fedora Linux 42 (Adams) os_version=42 linux_version=Fedora os_kernel_version=6.16.7 os_kernel_version_full=6.16.7-200.fc42.x86_64 hostname=sage test_category=all test_group=all plugin_directory=/usr/share/lynis/plugins lynis_update_available=0 binaries_count=4350 binaries_suid_count=/usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/chage /usr/bin/chfn /usr/bin/chsh /usr/bin/crontab /usr/bin/fusermount /usr/bin/fusermount-glusterfs /usr/bin/fusermount3 /usr/bin/gpasswd /usr/bin/grub2-set-bootflag /usr/bin/mount /usr/bin/mount.nfs /usr/bin/mount.nfs4 /usr/bin/newgrp /usr/bin/pam_timestamp_check /usr/bin/passwd /usr/bin/pkexec /usr/bin/sg /usr/bin/staprun /usr/bin/su /usr/bin/sudo /usr/bin/sudoedit /usr/bin/umount /usr/bin/umount.nfs /usr/bin/umount.nfs4 /usr/bin/unix_chkpwd /usr/bin/userhelper /usr/bin/vmware-user /usr/bin/vmware-user-suid-wrapper /usr/sbin/grub2-set-bootflag /usr/sbin/mount.nfs /usr/sbin/mount.nfs4 /usr/sbin/pam_timestamp_check /usr/sbin/umount.nfs /usr/sbin/umount.nfs4 /usr/sbin/unix_chkpwd /usr/sbin/userhelper binaries_sgid_count=/usr/bin/locate /usr/bin/lockdev /usr/bin/plocate /usr/bin/screen/usr/sbin/lockdev binary_paths=/var/lib/snapd/snap/bin,/usr/bin,/usr/sbin,/usr/local/bin,/usr/lib64/ccache vm=2 container=0 systemd=1 plugins_enabled=0 hostid=95d4692a387be7f441ca6e1213a446e9ae6e0bde hostid2=0936e5cd8a0702ef829eaf6c24e715cfb0b335c6a96c0ec19fe69c00c59ecbe5 running_service_tool=systemctl running_service[]=abrt-journal-core running_service[]=abrt-oops running_service[]=abrt-xorg running_service[]=abrtd running_service[]=accounts-daemon running_service[]=alsa-state running_service[]=atd running_service[]=auditd running_service[]=avahi-daemon running_service[]=bluetooth running_service[]=chronyd Chkrootkit Rootkits are hard to detect and often give attackers hidden access to a system. Chkrootkit is a lightweight script that scans binaries for tampered commands and known signatures. It’s still useful, but since it depends on a fixed signature set, it can miss newer or more advanced threats. Some administrators address this gap by pairing Chkrootkit with AIDE, a file integrity monitor that spots unexpected changes in system files. How Does Chkrootkit Protect You from Rootkits? Detection: It scans system binaries for signs of rootkits, checking for tampered commands and known malicious signatures. Simplicity: Chkrootkit’s use of basic commands makes it accessible for beginners, reducing the learning curve typically associated with security tools. This tool is precious for its targeted approach, focusing on one of the most elusive types of malware. Pairing it with integrating AIDE with Chkrootkit extends its coverage to file integrity monitoring as well. How to install via terminal: root@sage:~# dnf install chkrootkit How to check Chkrootkit Commands: root@sage:~# chkrootkit -h Usage: /usr/lib64/chkrootkit-0.58/chkrootkit [options] [test ...] Options: -h show this help and exit -V show version information and exit -l show available tests and exit -d debug -q quiet mode -x expert mode -r dir use dir as the root directory -p dir1:dir2:dirN path for the external commands used by chkrootkit -n skip NFS mount points -T fstype skip mount points of the supplied file system type Chkrootkit Running: root@sage:~# chkrootkit ROOTDIR is `/' Checking `amd'... not tested Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `crond'... not infected ... Chkrootkit with Grep: root@sage:~# chkrootkit | grep -E "INFECTED|not infected|not tested|nothing found|Vulnerable" ROOTDIR is `/' Checking `amd'... not tested Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `crond'... not infected ... These are the messages Chkrootkit prints during its tests: INFECTED – the command was likely modified by a known rootkit. not infected – no known rootkit signature was found. not tested – the test wasn’t run, often because the command isn’t available. nothing found – the command to be checked doesn’t exist on the system. Vulnerable but disabled – the command is infected but not active (not running or disabled in inetd.conf ). Chkrootkit in Expert mode: root@sage:~# chkrootkit -x Searching for suspicious strings in binaries... /usr/bin/awk: not infected /usr/bin/ls: not infected /usr/sbin/sshd: not infected ... Chkrootkit in Expert mode with Grep: root@sage:~# chkrootkit -x | egrep '^/' /usr/bin/awk: not infected /usr/bin/ls: not infected /usr/sbin/sshd: not infected ... The parameters in chkrootkit -x | egrep '^/' run Chkrootkit in expert mode. This tells it to include pathname strings in system commands, which can reveal suspicious patterns in the binaries. Since Chkrootkit relies on a fixed signature set, this option gives it a bit more reach. Rootkits are still a real problem. They letattackers hide access through weak spots or misconfigurations, making effective Linux rootkit detection and prevention critical for long-term security. Chkrootkit isn’t perfect, but used with a linux malware scanner, it can flag signs of compromise and point you toward cleanup. Linux Malware Detect (LMD): A Dedicated Linux Malware Scanner Linux Malware Detect is a free, open-source linux malware scanner. It pulls in threat data from intrusion detection systems and uses that to build signatures, so it’s aimed at catching malware that’s actually active in the wild. Why consider LMD? Active monitoring –the signatures are updated often, so this linux malware scanner doesn’t fall behind on new threats. Broad coverage – it can scan for many kinds of linux malware, which makes it useful as a general tool. For admins who want something simple but effective, LMD is a solid option. It keeps up with the threat landscape without adding much overhead. How to install via terminal: root@sage:~# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz HSTS in effect for www.rfxn.com:80 Saving 'maldetect-current.tar.gz' HTTP response 200 [https://www.rfxn.com/downloads/maldetect-current.tar.gz] maldetect-current.ta 100% [=========================================================> ] 1.58M --.-KB/s [Files: 1 Bytes: 1.58M [6.65MB/s] Redirects: 0 Todo: 0 E] Linux Malware Detect has to be downloaded from the R-fx Networks – Linux Software & Blog website. We use the command wget rfxn to get the download and save it in our current working directory. How to extract the download (LMD): root@sage:~# tar -zxvf maldetect-current.tar.gz maldetect-1.6.6/ maldetect-1.6.6/files/ maldetect-1.6.6/install.sh maldetect-1.6.6/README maldetect-1.6.6/LICENSE maldetect-1.6.6/CHANGELOG maldetect-1.6.6/conf.maldet ... root@sage:~# cd maldetect-1.6.6 We use the tar -zxvf maldetect-current.tar.gz command to extract the tar file.After extraction, you’ll see a new folder, usually named maldetect-1.6.6. After extraction, you’ll see a new folder, usually named something like maldetect-1.6.6 (the current release as of 2025). The version number may be different if a newer release is available, so adjust the command to match what you see with cd maldetect-1.6.6. Run the Install Script: root@sage:~/maldetect-1.6.6# ./install.sh ./install.sh sh /path/to/install.sh Doing this should output: Created symlink '/etc/systemd/system/multi-user.target.wants/maldet.service' → '/usr/lib/systemd/system/maldet.service'. Linux Malware Detect v1.6.6 (C) 2002-2023, R-fx Networks ; (C) 2023, Ryan MacDonald ; This program may be freely redistributed under the terms of the GNU GPL installation completed to /usr/local/maldetect config file: /usr/local/maldetect/conf.maldet exec file: /usr/local/maldetect/maldet exec link: /usr/local/sbin/maldet exec link: /usr/local/sbin/lmd cron.daily: /etc/cron.daily/maldet maldet(1533069): {sigup} performing signature update check... maldet(1533069): {sigup} local signature set is version 20250225482944 maldet(1533069): {sigup} new signature set 202509223097979 available maldet(1533069): {sigup} downloading https://cdn.rfxn.com/downloads/maldet-sigpack.tgz maldet(1533069): {sigup} downloading https://cdn.rfxn.com/downloads/maldet-cleanv2.tgz maldet(1533069): {sigup} verified md5sum of maldet-sigpack.tgz maldet(1533069): {sigup} unpacked and installed maldet-sigpack.tgz maldet(1533069): {sigup} verified md5sum of maldet-clean.tgz maldet(1533069): {sigup} unpacked and installed maldet-clean.tgz maldet(1533069): {sigup} signature set update completed maldet(1533069): {sigup} 17638 signatures (14801 MD5 | 2054 HEX | 783 YARA | 0 USER) After installation, let’s edit the configuration file: root@sage:~# vi /usr/local/maldetect/conf.maldet Using the vi /usr/local/maldetect/conf.maldet command, we can update the configuration file of maldet toedit some settings. Email Alerts: email_alert="1" email_addr="
Sep 24, 2025
•
102
Linux securityopen source toolsrisk mitigationEnhancing Linux Security with Breach Simulation Techniques
Cybersecurity threats have reached a new level of prevalence and sophistication, and innovative methods and tools are urgently needed to protect sensitive information. Recent statistics are eye-opening: According to Statista, 2,365 recorded cybersecurity attacks in 2023, a surprising 72% growth compared to 2021. . As these attacks become increasingly advanced, traditional security measures must be more robust. Organizations must know the latest forensic Linux distro updates and adopt advanced security protocols that protect them from data breaches and operational disruptions. Breach and attack simulation, or BAS, is emerging in this domain as one of the best modern protection methods. In this article, we will discuss BAS, why it is so essential for Linux environments, and some of the most well-known open-source tools available. What is Breach and Attack Simulation? Breach and Attack Simulation , BAS, is a cybersecurity mechanism conducted to act much like real-world attackers. BAS permits an organization to identify the weak points of its security frameworks by simulating controlled cyberattacks. According to MarketsandMarkets, the BAS market is expected to grow at a CAGR of 22.1% during the forecast period, reaching $3.5 billion by 2032. BAS offers essential insight into an organization's security posture by emulating cybercriminal tactics. It provides a balance sheet of strengths and weaknesses, offering an overall perspective on the capability of security measures to withstand real cyberattacks. In this dynamic world of cyber threats, BAS is earmarked as one of the pivotal weapons in the cybersecurity armory. Why is BAS So Important in Linux and Open-Source Systems? Linux and open-source environments are a dream for an attacker, both because of widespread enterprise usage and due to some inherent vulnerabilities that might persist within the code contributions that occur in open-source. With BAS, organizations can stay one step ahead of cybercriminals by discovering what maygo wrong in the security framework before it happens. It is integral to proactive risk mitigation against data breaches , regulatory fines, and reputational damage. By emulating a range of attack vectors using comprehensive feeds of up-to-date data on emerging threats, organizations get to shore up the gaps in their defenses before those gaps can be leveraged. Most Famous Breach and Attack Simulation Open Source Tools for Linux BAS is a fundamental approach to cybersecurity improvement, and several open-source tools make implementing it possible. The following are some of the most well-known BAS tools for Linux: Metasploit Framework Metasploit Framework is generally regarded as among the most advanced open-source tools for penetration testing and security validation. It consists of tools intentionally developed to mimic actual attacks and assess a security posture. Its immense repository of publicly available exploits permits users to deliver various attack vectors against the exploited systems by crafting custom-made payloads. Critical capabilities of Metasploit include: Post-Exploitation Modules: Such modules provide post-exploitation information gathering, privilege escalation, and access maintenance. Automation Capabilities: It allows users to run scripts, increasing efficiency in security testing and information-gathering processes. Vulnerability Scanning: Metasploit is usually used to exploit any known vulnerability on a Linux system and to test the effectiveness of the available security controls. Start with Metasploit. Install it on any Linux system, open the framework, and use auxiliary modules for vulnerability scanning . Then, look for exploits, identify them, and launch them, using meterpreter to post-exploit. Infection Monkey Another well-known open-source BAS tool is Infection Monkey by Guardicore. This tool emulates various attack techniques to test the security of a data center or cloud environment from cyber threats. It identifies weakspots, misconfigurations, and gaps in an organization's security posture. Key Features of Infection Monkey: Lateral Movement Simulation: This feature exposes how an attacker can move inside a network after gaining initial access. Compliance Testing: Infection Monkey does compliance testing against CIS benchmarks , ensuring a system is securely configured. Customizable Attack Vectors: Users can define attack scenarios fitting for organizational needs. To deploy Infection Monkey, ensure your environment matches the system requirements. Then, clone the software from its GitHub repository , install the required dependencies, and open the user interface with a web browser, where you can create and configure attack scenarios. CALDERA CALDERA is an open-source, next-generation tool that provides automated adversary emulation, red teaming, and security assessment. It uses the MITRE ATT&CK framework to perform realistic attack scenarios and help organizations improve their security posture insights. Key Features of CALDERA include: Modularity: Caldera's modularity makes it extensible through plugins, allowing organizations to tailor simulations for threats specific to their concerns. Automation and Central Management: This is done by providing a server-side interface from which the administration of simulations is quickly done centrally. Realistic Attack Scenarios: Because its actions map to ATT&CK techniques, CALDERA helps an organization fix critical vulnerabilities in its defenses. For the use of CALDERA, target systems will need to have Python, Git, and Docker installed. A clone can be made from GitHub and placed in a virtual environment where one creates and installs the requirements to open a web interface to generate and execute attack scenarios. Understanding the Importance of Including BAS in Cybersecurity Strategies Organizations can no longer afford to implement only responsive cybersecurity measures. Proactive steps arecritical to protect digital assets. Some of the top benefits derived from integrating BAS into cybersecurity include: Enhanced Security Posture : BAS allows organizations to detect and fix vulnerabilities before attackers can leverage them. This proactive approach improves the security posture overall, lessening the chances of successful cyberattacks. Data-Driven Decision Making: BAS gives valuable insights to organizations through attack simulations, after which informed decisions can be made on investments and improvements in security. It facilitates resource optimization for them by prioritizing areas of enhancement. Improved Incident Response: BAS assists an organization in refining its incident response plan by emulating realistic attack scenarios. Teams will know where their response mechanisms are lacking and can incorporate improvements for swift and effective responses against live threats. Cost Savings: Proactively addressing vulnerabilities using BAS can save an organization millions of dollars in costs related to data breaches, regulatory fines, and damage to brand reputation. The investment made in tools and simulations can result in significant long-term savings. Our Final Thoughts on the Importance of BAS for Robust Linux Security With the increased Linux security threats, protecting digital assets requires advanced tools and techniques. For organizations to adapt to today’s evolving threats, Breach and attack simulation is necessary. BAS replicates real-world attacks to assess security postures and provide actionable insights. Tools like Metasploit Framework, Infection Monkey, and CALDERA will automatically help an organization identify weak links and thus improve security measures and incident response. Organizations must stay current on emerging threats and the tools required to mitigate them. Equipped with BAS at the forefront of their cybersecurity strategies, they are better set to navigate this complex world of cybersecurity successfullyand defend against an expanding array of attacks. In other words, adopting BAS is not an option but a necessity for organizations committed to robust security postures in this digital age. Are you using BAS to improve your cybersecurity strategy? We'd love to hear about it! Reach out to us on X @lnxsec, and let's discuss it. . As cyber threats grow sophisticated, organizations must adopt breach simulation techniques and tools to improve Linux security.. cybersecurity, threats, reached, level, prevalence, sophistication, innovative. . Dave Wreski
Oct 31, 2024
•
102
open source toolscontainer securitysupply chain attackComprehensive Overview Of Emerging Tools In Container Security
Containers are among the many recent inventions of modern computing. They have emerged as the cornerstone of software development and deployment. They isolate applications and their dependencies into a closed environment, enabling efficient and consistent deployment across different infrastructures. . There are plenty of reasons behind the shift to containerization, the key being the widespread adoption of DevOps practices and cloud-native innovations. However, despite the unmatched convenience and efficiency, containers bring various security challenges that traditional security measures can’t fully address. As this new technology proliferates across production environments, securing them should be a priority for all organizations. Unlike traditional devices, containers share the hosts’ OS kernel, which is beneficial but exposes it to potential vulnerabilities. This means businesses should re-evaluate their security strategies throughout the container’s lifecycle. Similarly, the future of container security depends on several emerging innovations. The increasing shift towards Zero Trust models is especially relevant to containerized environments. This model assumes no inherent trust within the network and enforces stringent authentication measures for access. The shift-left security option, which integrates security practices from the development lifecycle, is also beneficial. This strategy helps developers detect and mitigate vulnerabilities before production, significantly reducing attack surfaces. Various open-source tools, including Trivy, lead the pack in ensuring these developments. Below is a detailed guide on container security and its future. Read on! The Current State of Container Security With the rise of the adoption of containers, there’s a need to understand the current state of container security. While containers offer significant benefits, they introduce significant security challenges. It is prudent for organizations and businesses to know some of theexisting threats and common attack vendors before adopting them. They Include: Vulnerable code is the most important security risk of containerized applications. As mentioned, containers package applications alongside their dependence. This often includes insecure or outdated libraries that attackers can exploit. Compromised images: Containers rely on images containing apps and their dependencies. Unfortunately, some may have insecure components that expose the entire network to security risks. A compromised container image serves as a perfect entry points for attackers. Insecure working: Containers communicate through internal networks. Poorly secured networks become excellent vectors for attacks. Lack of encryption and insufficient segmentation often lead to data breaches. Container escape: This severe threat occurs when attackers break out of container isolation and access the host system, compromising the host and other containers running on it. While these risks are dire, container environments have various built-in security measures that mitigate these vulnerabilities. These features are built on Docker and Kubernetes but have some limitations. For instance, Docker uses namespaces to isolate containers and host systems. This significantly prevents unauthorized access and denial-of-service attacks and reduces the attack surface. However, Docker’s default features are slightly insufficient. Simple issues like using untrusted images can bypass its security setup. Kubernetes also provides perfect built-in security features for container environments. It enhances container security by implementing RBAC, which controls access and empowers network segmentation. Unfortunately, configuring Kubernetes securely often proves challenging. Wrong settings expose containers to vulnerabilities. However, this doesn’t mean containers are entirely insecure. Organizations can leverage various open-source container security tools to address these issues that exceed the capability of built-insecurity measures. These tools include: Trivy and Clair for image vulnerability scanning Kube-bench and Kubescape for configuration and compliance issues. Falco and Sysdig for enhanced runtime security Cilium and Calico will address network security issues. Open Policy Agent and Kyverno to sort policy enforcement issues. Dex and Keycloak for identity verification and access management. Sealed Secrets and HashiCorp Valut for secrets management. They enhance the security of stored sensitive information. Grafana Loki and Prometheus for better incident responses. Collectively, these tools provide targeted solutions that enhance container security in different aspects of the container lifecycle. Emerging Trends in Container Security With the expanding use of containerization, the security realm surrounding these environments keeps evolving in response to emerging threats. Below is a breakdown of top trends shaping the future of container security: Exploitation patterns and attacks targeting containerized environments Attackers now use sophisticated techniques to exploit vulnerabilities present in these systems. Some of the recent trends in exploitation patterns include: Supply chain attacks : Malicious persons compromise container images and dependencies, ultimately affecting the supply chain. They can inject malware into private or public repositories. Lateral movement: Attackers attempt to move laterally to access other containers after successfully accessing a container. Resource hijacking – malicious individuals hijack resources for malicious activities. Containers with misconfigured resources are often very vulnerable. Integrating security into the CI/CD pipeline This practice is a perfect response to the dynamic nature of container deployments. Also called shift-left security, it focuses on identifying and mitigating vulnerabilities earlier in the container development lifecycle. Various tools, including automated vulnerability scanning andsecurity testing, are integrated into CI/CD workflows before containers reach final production. Automated checks are also conducted to ensure containers have the necessary security structure before deployment. The use of software bills of materials Containers heavily rely on third-party components and dependencies. Using SBOM has become crucial for tracking and managing all components. It provides a detailed inventory of all components in the container image, including frameworks, libraries, and dependencies. Doing this is beneficial in many ways. For starters, it helps in vulnerability management. Organizations can easily identify and address threats in third-party components. SBOMs also provide vital information during incident response. Knowing the components makes it easy to identify the origin of the compromise. Adoption of policy as code practices Policy as Code is a practice of defining security policies enforceable through code. This approach aligns perfectly with shift-left practices, embedding security policies directly into the container development lifecycle. Adoption of these practices helps organizations achieve consistency and automation. Administrators define and automate policies, significantly reducing the risk of misconfiguration and human error. These policies also enhance collaboration between development and security teams. Adoption of AI and ML 
Artificial intelligence and machine learning have transformed container security in the following ways: Threat prediction: ML models analyze patterns and historical data to predict potential threats. This proactive approach helps anticipate and mitigate vulnerabilities before they materialize. Behavior analysis: Al-powered tools analyze container patterns to identify anomalies that indicate security threats like resource usage or unexpected connections. Automated responses: Automatedtools provide faster and accurate responses to arising incidents. Integrating AI with incident response workflow allows organizations to streamline threat mitigation and minimize the impact of breaches. Adoption of service mesh architectures Organizations have increasingly adopted service mesh architectures to secure communication between containerized environments. This practice enhances traffic control and policy enforcement. Service meshes like Istio provide more control over network traffic, enhancing confidentiality and data integrity. Service meshes also allow organizations to monitor traffic patterns and detect anomalies. Such visibility is crucial for identifying and responding to threats in real time. However, meshes introduce some complexities. Organizations should carefully balance these security advantages with resource demands. Spotlight on Open Source Security Tools Securing these environments becomes important as containerization becomes the cornerstone of modern app deployment. Open-source tools can help organizations address various challenges. Some of the top open-source tools to consider include: Trivy Trivy is an open-source tool from Aqua Security that offers excellent vulnerability scanning for container images and file systems. This tool stands out for its comprehensive vulnerability scanning ability, which makes it a must-have tool in business container security sets. Key features of Trivy include: Wide vulnerability coverage: The tool scans various vulnerabilities in container images. It also supports various languages and package managers, broadly covering potential threats. Ease of use: The command-line interface is straightforward and requires minimal setup. Community and support: As an open-source project, Trivy benefits from contributions from a vibrant community of developers. This collaborative environment ensures that it remains up-to-date. Hadolint This is another open-source linter that helps developers write secure Dockerimages. Hadolint evaluates Docker files, ensuring they adhere to best practices like minimal image size, reduced number of layers, and more. These practices enhance the performance and security of container images. Hadolint also provides security recommendations for improving Docker Files' security. For instance, it can suggest using the “latest” tag, which has potential security vulnerabilities. The tool allows users to define custom configurations and rules to suit their requirements. Organizations can also benefit from Clair, Grype, Syft, and Kube-Bench. These tools play a crucial role in improving the container security landscape. Future of Open Source Container Security Tools 
The container security landscape continues evolving, with applications becoming more complex and new threats emerging. Open-source tools like Trivy will also likely undergo significant advancements to meet emerging challenges. As containerized environments become sophisticated, Trivy will expand its detection abilities. Its threat detection abilities will include supply chain attacks and new exploitation techniques. Trivy will also evolve to adapt to the needs of modern architectures, especially hybrid and multi-cloud environments. On the other hand, Hadolint will feature advanced limiting rules and a deeper integration with the container ecosystem. Hadolint will feature sophisticated features that address emerging performance and security issues in Docker Files. However, the fast-paced culture of this environment will necessitate a community-driven approach to open-source tool development. Open-source communities allow for rapid response to emerging threats, leveraging collective expertise and resources. Similarly, integrating open-source security tools into comprehensive security platforms is very possible. Integration ofthese tools will focus on enhancing interoperability and automation. This will require standardization of APIs and data formats to allow smooth data exchange and communication of these tools. Lastly, new tools will emerge tailored to address specific vulnerabilities associated with evolving container technologies. These tools will likely focus on specific areas, like serverless security. New tools will also help organizations navigate complex compliance requirements. For instance, they will automate compliance checks and provide detailed reports to ensure containerized apps adhere to legal provisions. Challenges and Considerations for the Future Maintaining robust security becomes challenging as containerization becomes more disrupted and dynamic. The main issues are: Securing dynamic and distributed environments: This requires tools that adapt to diverse deployment environments, including on-premise data centers, edge devices, and multiple clouds. Balancing agility and usability: Focusing overly on agility leads to misconfiguration, while stringent security practices hinder usability. Finding the perfect balance is key. Legal and regulatory issues: Open-source tool development should adhere to a complex legal landscape. Compliance with data protection laws, software licensing and other legal issues becomes challenging. Addressing these challenges requires collaboration and continuous innovation. Keep Learning About Container Security Container technologies offer great flexibility and scalability. However, they come with unique security challenges that necessitate innovative solutions. Fortunately, open-source tools play a crucial role in enhancing security. Their capabilities, ranging from vulnerability scanning to runtime monitoring, help secure container environments. However, developers and professionals still need to contribute to enhancing the security of these projects. Participating in open-source communities helps shape the future of container security and ensuresthese tools meet the demands of modern applications. Learn about Container Security basics Secure Docker Containers with These Data Management Software Options Open Source Vulnerability Assessment Tools & Scanners . Investigating developments, technologies, and threats influencing the next phase of container protection and its transformation.. Container Security, Open Source Tools, Shift Left Security, CI/CD Pipeline, Runtime Monitoring. . Dave Wreski
Jul 13, 2024
•
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
network securityDoS attackopen source toolsPull The Plug: Community Driven Growth and Security Training
Five years after our original interview with Brian Gemberling, founder of PullthePlug.org, we catch up with Daniel Alvarez and the rest of the site's administrative management. Its structured management and focus on the community will ensure many years of continued success. You're asking, what is pull the plug? Read more to find out... . LinuxSecurity.com: Please explain again for our readers what Pull the Plug is about. What is the concept? How does it work? Who can participate? PullthePlug.org: The concept of PullThePlug has always been to provide an arena for like minded individuals to discuss, train, and learn about computer security and associated technologies. The primary focus of PullThePlug as a community is to deliver information and resources on computer security to a wide range of audiences. Some services we currently offer are war-game machines (vortex, semtex, catalyst, blackhole), mailing lists, IRC channels, and live lectures ( ) and repository/web hosting for research efforts ( ).. As a result of PullThePlug being community driven (by the community for the community), anybody can participate in some way or another. More often then not, new talents are seen when participating in our wargames or contributing to mailing lists, and people are also free to join the IRC and discuss any topic of interest, or provide ideas or services which help in furthering the community driven learning experience. LinuxSecurity.com: Daniel, how did you get involved with Pull the Plug? What is your current role with the site? PullthePlug.org: I first became interested in PullThePlug in 2001 when a co-worker showed it to me. Eager to learn about network security, I visited the site frequently, reading documentation, and playing war-games. Near the end of that year the organization was running short on resources and the servers being used to run the war-games were shut down. By 2003 I became really involved in the project when I helped create the first new war-game since the lastones were shut down (vortex.labs.pulltheplug.org). A friend, Kurtis Meyers, and I donated a server to run the new war-game and Andrew G. Administered it. The initial founder of PullThePlug, Brian Gemberling, was happy to rack our server and provide the necessary bandwidth. The new war-game led to a large increase in traffic and more interest than Brian could manage by himself, so Brian gave me the responsibility of handling the day to day management of PullThePlugs resources. Since then we have continued to increase our traffic and interest quite a bit. A management team has been created to organize PullThePlug. This group includes Andrew Griffiths, Samy Al Bahra, Daniel Hudson, and myself. Together we make all of the decisions and work allocations related to PullThePlug. LinuxSecurity.com: What happened to Brian Gemberling (founder)? Is he still involved with the project? PullthePlug.org: Brian keeps himself busy with his newly made business PullThePlug Technologies LLC (), located in Aushburn, Virginia. His business offers secure collocation, rack space, and a variety of Internet services with an emphasis on security. Initially PTPTECH only offered services to private parties, but on June 13 his services became available to the public. He provides bandwidth and rack space forour servers. Brian is no longer involved in the everyday operation of PullThePlug, However, he still donates bandwidth, rack space, and time. LinuxSecurity.com: How has the project changed since our original interview? (June 26th 2000) How much has it grown? How many people are now involved, and how many hosts do you currently maintain? PullthePlug.org: The management of PullThePlug has changed hands from Brian to a four person management team created from outstanding community members. Other people who are not a member of the management team still take part in many of the administrative services such as managing the IRC chat rooms and the war-games. We moved from PullThePlug.com to PullThePlug.orgsince PullThePlug is on it's way to becoming a non-profit. PullThePlug.com is now part of PullThePlug Technologies owned and operated by the founder of PullThePlug, Brian. The staff has changed a lot. Many of the old crew wanted PullThePlug to remain private, while others wanted to grow and acquire/provide new resources to the public. Many people left as PullThePlug got too big for their tastes. The old war-games are gone and a whole new breed of them are up, including vortex, semtex, catalyst and blackhole. Vortex resembles mainsource which is a level based wargame focusing on learning security concepts such as buffer overflows, format strings and some encryption stuff. Blackhole is also level based and focuses on remote exploitation of overflows, format strings etc. Semtex is much more "Down to earth" it doesn't focus on vulnerabilities - instead - it's purpose is to allow players to hone their network programming skills. Catalyst is for those looking to play around with binaries and hone their "binary analysis" skills. Technology has changed a lot in 4 years and we try to keep up with all the "latest and greatest". We've also pioneered new things like Live Tutorials ( ). Basically, people can choose a topic to 'lecture' on and choose a medium such as irc, silc, voip or even teleconferences and physical meetings. Listeners can login to suntzu and see what's being explained real time. Allowing for the observer to actually see with his/her own eyes what's being discussed. We also have a Development machine which provides SVN/CVS services to various projects. Some of the projects we host include kerneled (, home to many popular FreeBSD ports and various software patches), which includes quite a subset of software and other various private projects. Our size: Currently we have 4 "master" (physical) machines and over 8 virtual servers. How many People are involved now? 4 people in management team about 8 total people just helping out Including wargame administrators like"aton" - who runs semtex.labs.pulltheplug.org and Ken Davies who helps us out whenever our servers go down by going to the datacenter and fixing stuff. Both of which have been with us for quite sometime. We receive 250 300 visitors to our site per day on average. As well as an average of 80-90 people on our IRCD and over 60 people on our mailing list. LinuxSecurity.com: How often are your systems compromised? What have you learned from the process? How has it benefited your skill set personally? PullthePlug.org: Oddly enough PullThePlug does not receive an excessive amount of hacking attempts, but we have experienced several Denial of Service (DoS) attacks against the wargame machines, and other services we provide (such as the live lectures). The management team have always been swift in their response to these incidents. There has been no known successful compromise of the PullThePlug network. We believe our war-games provide a unique challenge to the security community, and thus much more challenging than a simple dotslash. As a learning curve, we have realised the benefits in network monitoring, securing systems, patch management, and other such day-to-day administrative activities. This has taught most of the staff how to look for and identify interesting event patters (most of the data on the PullThePlug network is logged and managed remotely), in addition we use complex filters on the upstream router to block out traffic to hosts which we deem sensitive. We utilize virtual servers extensively as well. This creates an environment that minimizes possible exposure to the rest of the systems and also segregates "trouble" machines, effectively cutting off any chance of total compromise. We also use grsecurity kernel patches ( grsecurity ). Not only from a security perspective, but administering the network has always provided a unique challenge to staff and as such is constantly teaching us new things. LinuxSecurity.com: Although everyone who attempts to compromise a machine usesdifferent techniques, have you noticed any common patters (methods) that are used across the board? Please describe the anatomy of a typical attack. PullthePlug.org: We simply don't leave machines open to attack - instead we close off the machines and leave 'conduits' for attacking, which are levels. An attacker must then work their way up through the levels with increasing difficulty. This provides a unique challenge that turns out to be very rewarding in the end. Another benefit from doing this method is that if people are unfamilar with some aspect, they'll need to learn it before progressing, which encourages people and exposes them to new stuff. One interesting effect of the level based wargames we provide is that people are constantly suprising us with new and innovative ways to approach certain levels. With semtex, one user submitted an solution developed with Microsoft Excel, while another user has reverse engineered linux binaries (on catalyst) under the Windows platform. Typically the most common approach to the wargames is the most obvious, and people will compromise the levels via standard stack smashing techniques, format strings, heap exploitation and so on. Though I state the "standard" techniques are used, there is no definative approach people are taking. This is primarily due to the challenges being different to all other wargames we have seen - they all provide the opportunity for exploitation, but there is always that slight twist to make it all the more interesting, challenging and rewarding. As for the PullThePlug network being attacked, we often see portscan attempts followed by brute forcing - occasionally an exploit against a service we don't provide (which we usually consider to be worm traffic). If we were to class the most common attack scenarious, it would probably be due to worm traffic, and involves probes against particular port's (to determine whether or not a service is provided), followed by multiple malicious payloads sent to that service. LinuxSecurity.com: After being involved in this project, what have you learned to be the single most important step in keeping a linux/unix system secure? PullthePlug.org: The single most important step is trusting in the abilities of the people who are protecting your assets. If you cannot trust them. Then you cannot Trust the security of your systems and networks. For small environments where they don't have the funds available to do a any serious security stuff, their most important step would be ensuring machines are kept up to date, along with anti-virus signatures, and perhaps some basic end-user training. In larger environments, you'll need to have skilled administrators who know their field inside out, who will keep abreast of security issues, will look at and examine methods of improving the security of the systems, and hopefully designing away various security issues. In huge environments, you'll generally have duty seperation, and teams of people handling various facets, such as people who write policies, the people who implement them, the people response for monitoring the security of systems, and so fourth. In this case, its nessesarcy that people work together on achieving the required level of security. Problems will generally be approached by doing a risk analysis and attemtping to remove or mitigate high risk / high impact and working down. To solve the problems though, you'll need to have the appropriately skilled people with the backing of the company. To bring this back to pulltheplug, a lot of the stuff we do involves minimizing exposure while trying to make the appropriate systems accessible by people. A example of minimising exposure would be seperating various services we provide from people's shell accounts, and only providing the files needed to make that service work as expected. LinuxSecurity.com: Pull the plug is a slightly different concept from a honeynet. While the goals are similar, are the results different? Explain the advantages of operating openly asopposed to covertly like the administrator of a honeynet would. PullthePlug.org: Pulltheplug is pretty much completely different from a honeynet. We aim to help people understand applied security concepts, rather than setting up boxes for random people to compromise. We do get the joy of observing some of the more interesting exploit's against challenges when people wish to tell us about them, but there is a significant difference between that and a honeypot. We differ not only in terms of goals, but also strategy. The games are not setup to observe peoples actions, and are not setup as bait to understand new exploit strategies. All levels are generally left un-moderated, which allows participants to choose whether or not to share information with the rest of the community (this could be an exploit technique, or idea's for new challenges etc). Because participants have this freedom, it also builds a strong level of trust within the community, and provides people with a safe zone to experiment and broaden their ideas without penalty. Community members and new comers alike - see our community as a place to share ideas without the ego's that plague many other communities. Some say we are the next best thing before being a totally private community. LinuxSecurity.com: For those readers interested in system monitoring, what open source tools would you recommend? Would you mind providing the names, a short description, and the URLs to several of your favorite host and network monitoring tools? PullthePlug.org: These are tools we recomend overall. grsecurity grsecurity - grsecurity is a kernel patch which provides a comphrensive approach to increasing the security of a system. grsecurity provides detection, prevention, and containment, which is useful on a couple of the systems Pulltheplug runs. openwall kernel patch Openwall - bringing security into open computing environments - The openwall kernel patch allows us to provide an increased level of security that isn't asextreme as grsecurity. This is used to allow people to learn such things as bypassing non-executable stacks for example. syslog-ng syslog-ng - Log Management Solutions - Secure replacement to syslog. We utilize syslog-ng to monitor our network and facilitate remote storage of logs. stunnel stunnel: Home - We utilize stunnel to provide secure encrypted means of transporting logs and other streamed data across the network and internet. Linux VServer Project Linux-VServer/ - Linux Virtual Servers provides the means for complete segregation of server processes allowing us to minimize exposure in the event of a successful attack. They also allow us to extend the value of our limited resources by running several modularized Linux Distributions under the same linux kernel. TrustedBSD Security Extensions TrustedBSD - Home - "The TrustedBSD project provides a set of trusted operating system extensions to the FreeBSD operating system, targeting the Common Criteria for Information Technology Security Evaluation (CC)." We utilize many of the extensions on our development hosting server. LinuxSecurity.com
Jul 05, 2005
•
102
security practicesopen source toolssecure codingInterview With Wietse Venema: TCP Wrapper and Postfix Security Insights
Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit or "TCT". He is currently working at the Thomas J. Watson Research Center and he has gratiously agreed to allow us to catch up with him and and see what he's been up to lately.. Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit or "TCT". He is currently working at the Thomas J. Watson Research Center and he has gratiously agreed to allow us to catch up with him and and see what he's been up to lately. Linuxsecurity.com: Thanks for taking the time to interview with us. How you doing these days? The most we hear from you is when Postfix is updated, the mailing lists, or something like that. What are you up to? Wietse: I have been finishing things, so that I can start work on new projects. After a major documentation rewrite for the Postfix mail system, I finished the manuscript for a book on computer forensic analysis with Dan Farmer. When I finish something, I normally start reading everything that I can lay my hands on and then inspiration comes. Linuxsecurity.com: On your website you mentioned you go bike riding, weather permitting, how's the weather been where you are this year? Wietse: It has been fairly typical here in southern New York state. We dig ourselves out from the snow a few times in January and February. Once the snow is gone in March, we spend quality time walking up a hill or riding a bike. Many several former railroads are/were converted into trails, and riding them is fun. Unlike Europe, where I grew up, the roads in southern New York state are notreally safe for riding a bicycle. Linuxsecurity.com: You have a suite of tools available on your website. Any new ones coming out that address basic fundamental security practices that still aren't followed or are you going to add any new functionality to your existing programs? Wietse: Some tools such as TCP WRAPPER are complete, and adding more features does not make them more useful. I would update them only so that they survive changes in operating systems, language compilers and/or network protocols. Some tools such as SATAN have served their purpose, and now have historical value only. Linuxsecurity.com: Does the continued success of TCP Wrapper surprise you? If so, why is that? What does TCP Wrapper have that makes it so valuable today. Perhaps the biggest virtue is that tcp_wrappers works as expected. This means that not only the software is relatively error free, it is also possible for human beings to install, configure, and forget tcp_wrappers without getting into trouble. It does not matter how well software is written when people can't figure out how to use it, or when it has sharp edges that make it unsafe to use. Being safe and secure is hard enough with software like tcp_wrappers that spans only a few thousand lines of code. With a 10 times larger system such as Postfix, even relatively error-free software contains a number of errors, and one has to build additional safety features into the architecture to prevent accidents from happening. Just like elevators have safety brakes that prevent them from crashing into the basement, Postfix has safety brakes that most people never notice until they are needed. Linuxsecurity.com: Postfix is a really good Mail Transport Agent (MTA), I've been using it for a long time and I set it up for someone any chance I get. Why did you decide to write a new MTA instead of scaling down an existing MTA? :-) Wietse: Indeed, why would anyone spend so much time writingyet another UNIX-based mail system, when Sendmail and qmail already existed? When I was looking for a programming project, neither mail system was a desirable option for me, and enough people felt the same way. Writing a new mail system from scratch was a change from previous projects. Normally I would retrofit security features almost invisibly, either by replacing an existing server such as portmap by a hardened version that was 100% compatible, or by adding a very thin layer such as tcp_wrappers. In the case of the Postfix mail system, there was no way that the changes could be made in an invisible manner. Linuxsecurity.com: What is your take on spam and the role the MTA plays in helping to prevent it? Wietse: Stopping email that contains spam is not fundamentally different from stopping email that contains viruses. In both cases, complex content analysis is better done outside the mail system. That allows people to choose the best mail system and the best spam/virus software for their environment. And in both cases, a lot of spam or viral email comes from systems that have no business sending email directly across the Internet. These are often PCs on residential networks that have been compromised via some worm of virus, and that are under remote control by criminals that use those systems to send spam and/or to infect more systems. These rogue systems can often be recognized by the way they implement the email protocols wrongly, if not by their residential IP address. Blocking direct mail from rogue systems is best done by the ISP that hosts those systems, but that happens rarely. The next best solution is to block direct mail from rogue systems at the receiving end, and that is where Postfix can help. Linuxsecurity.com: In one article, I wrote about how attackers are still breaking into computer systems using well-known exploits. Any ideas on how to help instill basic security practices in administrators andvendors? Wietse: I think that learning by example is a good way to bring the point across. This is what Dan Farmer and I attempted years ago with our white paper on improving the security of your system by breaking into it. I have the same experience when explaining how to build more secure software. People just don't see that there is a problem until you can show good examples of software that does not do the things that it obviously was meant to do. Security problems happen when there is a mismatch between expected behavior and actual behavior. Linuxsecurity.com: How did you get into the forensics side of computers? Wietse: The initial motivation for getting involved with computer forensics was to reconstruct computer break-ins, so that I could prevent them from happening again. An amazing amount of information can be found after an incident. As computers become more complex, humans have less control over when and where information is stored, and how that storage is recycled when information is discarded. Because of this it is practically impossible to erase all information about an incident from a disk, without physically destroying the hardware. Erasing all memory is difficult too, if you don't want to draw attention by crashing the system. How much reconstruction is possible depends only on the amount of skill and effort you're willing to put in. Linuxsecurity.com: You and Dan Farmer still work on The Coroner's Toolkit (TCT). What research, seminars, or open source programs you working on in forensics? Wietse: We just finished a manuscript for a book on computer forensic analysis that we hope will come out this year. In this book we write about things that we learned after we released the TCT. For some experiments we used the TCT, and for other measurements we wrote a few new tools. When this book is published I will be happy to turn my attention to other projects. Linuxsecurity.com: We just wanted to catchup with you and see how things were going. Can you please give us a final statement about keeping our systems secure? Wietse: You don't make a system secure by patching the holes - if the system wasn't built to be secure then it never will be. Linuxsecurity.com: Wietse provided this quote: "As long as there is support for ad hoc fixes and security packages for these inadequate designs and as long as the illusory results of penetration teams are accepted as demonstrations of computer system security, proper security will not be a reality." Roger Schell et al., Preliminary notes on the Design of Secure Military Computer Systems, 1973. Archive of seminal security papers at https://seclab.cs.ucdavis.edu/projects/history/seminal.html Linuxsecurity.com: Okay one last thing, where were you and who drew that caricature on your website? Wietse: The caricature was drawn, by an artist whose name I do not know, at a conference dinner in 1997 when the Forum of Incident Response and Security Teams (www.first.org) met for its annual conference in Bristol, UK. I have supported this organization for many years, and I even had the privilege of spending more than the maximal time as its chair. Duane Dunston is an Information Technology Specialist (Security) for the National Climatic Data Center. He was previously a contractor for STG Inc. for the same organization. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS . Hey, Ann Curry! . Wietse Venema explores how TCP Wrapper and Postfix continue to influence modern security strategies in the current landscape.. Wietse Venema, TCP Wrapper, Postfix Mail Agent, Computer Forensics, Security Practices. . Duane Dunston
Jul 09, 2004
•
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
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Explore top 10 tips to secure your open-source projects now. Read More