Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×
Stay Ahead With Linux Security Features
security advisory path traversal Two newly fixed storage bugs in Kubernetes showed more than just a problem with path traversal. They found a common security flaw in the cloud: powerful parts often think that requests accepted by a higher system are safe to run. This is a simple lesson for the platform and security teams: RBAC can accept a request without showing that its parameters will stay within a certain filesystem boundary. This is clear from a new study from SentinelLabs into flaws in the Kubernetes CSI drivers for NFS...
Jul 24, 2026
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
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 6 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
network securityintrusion detectionnetwork monitoringEffective Network Intrusion Detection Guide: Snort Configuration Details
This document takes you through the basics of intrusion detection, the steps necessary to configure a host to run the snort network intrusion detection system, testing its operation, and alerting you to possible intrusion events. . Snort is a software-based real-time network intrusion detection system developed by Martin Roesch that can be used to notify an administrator of a potential intrusion attempt. The ever-increasing amount of Internet crackers, armed with "ready-to-run" exploits, as well as the sophisticated attacker that's intent on defacing your web page necessitates the use of a method to track their activity and alert you to this. Until now, intrusion detection devices were either dedicated-use commercial products, or not real-time and difficult to install. Snort is the solution for monitoring small TCP/IP networks where it is not cost-effective to deploy commercial products. Snort is an easy-to-use, "lightweight", and very functional alternative. What is Network Intrusion Detection? A Network Intrusion Detection System (NIDS) is a system that is responsible for detecting anamolous, inappropriate, or other data that may be considered unauthorized occuring on a network. Unlike a firewall, which is configured to allow or deny access to a particular service or host based on a set of rules. If the traffic matches an acceptible pattern, it is permitted regardless of what the packet contains. However, an NIDS captures and inspects all traffic, regardless of whether it's permitted or not. Based on the contents, at either the IP or application level, an alert is generated. Snort is a "lightweight" NIDS in that it is non-intrusive, easily configured, utilizes familiar methods for rule development, and takes only a few minutes to install. Snort currently includes the ability to detect more than 1100 potential vulnerabilities. Keep in mind that Intrusion Detection devices work in conjunction with other security measures, and are not a replacement for other good security practices. It is also quitefeature-packed right out of the box. Among its features include the ability to: Detect and alert based on pattern matching for threats including buffer overflows, stealth port scans, CGI attacks, SMB probes and NetBIOS queries, NMAP and other portscanners, well-known backdoors and system vulnerabilities, DDoS clients, and many more; Use syslog, SMB "WinPopUp" messages, or a file to alert an administrator; Develop new rules quickly once the pattern (attack signature) is known for the vulnerability; Record packets in their human-readable form from the offending IP address in a hierarchial directory structure. Used as a "passive trap" to record the presence of traffic that should not be found on a network, such as NFS or Napster connections; Used on an existing workstation to monitor a home DSL connection, or on a dedicated server to monitor a corporate web site Snort uses the popular libpcap library, the same library that tcpdump uses to perform its packet sniffing. Snort decodes all the packets passing by on the network to which it's attached by entering promiscous mode. Based upon the content of the individual packets and the rules defined in the configuration file, an alert is generated. Why Use Intrusion Detection? Intrusion detection devices are an integral part of any network. The Internet is constantly evolving, and new vulnerabilities and exploits are found regularly. They provide an additional level of protection to detect the presence of an intruder, and help to provide accoutability for the attacker's actions. Before Installing Snort There are a few things you should determine before you install snort. Do you have approval to run an intrusion detection device by your organization? Is the system you're installing snort on secure? The last thing you want is the feeling of that false sense of security that you get by looking at what you think is happening but really has been modified by an intruder. The use of OpenSSH is mandatory for remote access. Reading the SolarisSecurity FAQ and the Linux Security HOWTO should provide you with a starting point. Where are you going to put it? If you are simply trying to find out who is port scanning or attempting to attack your home system, it's an easy decision. However, placement in an organization may be more difficult. Is the date and time correct? Ensure the time and date are correct on the host that snort will be running on. Install the xntpd time server so you can be sure the time of the events you are recording is correct. Chances are it is included with or already installed on your system but may still need to be configured. Once you have found a suitable timeserver from the URL provided above, a root crontab entry such as the following should suffice: 00 * * * * root /usr/sbin/ntpdate -u The device may be placed outside an organization's firewall between the firewall and the external untrusted network. This allows snort to detect not only the attacks that may make it through the firewall, but also those that are blocked by the firewall. The presence of switches, routers and firewalls will all have an effect on the correct placement of the box. A decision must be made as to which network segment will catch the traffic you actually want to monitor. Placement of the NIDS on the local side of the firewall will allow the NIDS to monitor traffic that the firewall has already determined to be permissable, but not necessarily benign. This will, of course, not catch traffic that the firewall has already blocked, potentially masquerading port scans, probes and other types of attack. Single Interface The easiest configuration is a box with a single interface. The same interface that listens to the network traffic is the same one from which administration is done. Images Courtesy Network Flight Recorder This will be the typical configuration for home network users and administrators monitoring internal networks. Dual Interface In a dual-interface configuration, oneinterface is used to listen to network traffic in promiscuous mode while the other is used for remote administration. This type of configuration is used in environments where it is not possible to administrate the box from the same interface that is listening to the network traffic. In this configuration, the external interface should be well-protected and the box designed explictly for this purpose. The box should not be offering any network services except for ssh on the internal interface only. Images Courtesy Network Flight Recorder Installation of Snort The file INSTALL included with the distribution contains information on installing and configuration snort from the downloadable source code. It is very easy to compile, configure, and install. If you are a Red Hat or compatible user, a precompiled RPM file is available from . You will also need the libpcap-0.4 package which is included with all Linux distributions. The source code and other information are downloadable from . Installing the Snort Ruleset After snort is installed, you'll want to download the latest rules file. Currently there are two different rulesets that people use. A ruleset developed by Jim Forster can be downloaded from Another ruleset, developed as part of Max Vision's ArachNIDS work, is available from and updated hourly. The Max Vision ruleset is particularly nice because it follows the Common Vulnerabilities and Exposures (CVE) database, allowing people to refer to a particular vulnerability using a consistent name. From the CVE Frequently Asked Questions: "CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability databases and security tools with this "common enumeration." " If you've installed the snort RPM, the /usr/sbin/snort-update script written by Dave Dittrich can be used to download thelatest Max Vision ruleset from cron: 00 00 * * * root /usr/sbin/snort-update -q It can also be downloaded from This assumes the wget package is installed, the local box can download the file at , and it can successfully deliver mail to an administrator. The snort-update script will place the vision.conf file in /etc/snort/vision.conf.new and an email notification will be sent to the local root account with the differences from the previous version, if any. You must then rename the vision.conf.new to vision.conf . You might also consider using the snort.org ruleset in addition to the Max Vision ruleset. This can be achieved by downloading the snort.org ruleset. Information on combining these rulesets together is included below. The backdoor-lib , misc-lib , overflow-lib and other similar files are included with the source code, but are pretty dated and not typically used. Before snort can be started, a few variables must be defined. Also included in the snort RPM is a file called rules.base which was derived from Max Vision's vision.conf file. It is a short file that contains a few variables that define your internal and external networks, hosts that snort should ignore portscans from, and on which networks snort should watch for portscans. It can also be downloaded from . A portscan is defined as TCP connection attempts to more than P ports in T seconds or UDP packets sent to more than P ports in T sections. Read Martin's "Writing Snort Rules" for a full description of portscan. You'll need to supply the information for your INTERNAL and EXTERNAL networks, and from DNS servers which tend to trigger the portscan detection. The rules.base file looks as follows: # # Taken and modified from "vision.conf", part of Max Vision's # ArachNIDs work. See /usr/doc/snort-1.6/README.snort-stuff for more # information on how to use this file. var INTERNAL 192.168.1.0/24 var EXTERNAL 63.87.101.0/24 var DNSSERVERS63.87.101.90/32 63.87.101.92/32 preprocessor http_decode: 80 443 8080 preprocessor minfrag: 128 preprocessor portscan-ignorehosts: $DNSSERVERS preprocessor portscan: $EXTERNAL 3 5 /var/log/snort/portscan.log # | # Log file (path/name) ----------------------------------+ # Ruleset, available (updated hourly) from: # # # Include the latest copy of Max Vision's ruleset include /etc/snort/vision.conf # # Uncomment the next line if you wish to include the latest # copy of the snort.org ruleset. Be sure to download the latest # one from # # include /etc/snort/06082k.rules # # If you wish to monitor multiple INTERNAL networks, you can include # another variable that defines the additional network, then include # the snort ruleset again. Uncomment the two following lines. # # var INTERNAL 192.168.2.0/24 # include /etc/snort/vision.conf # include other rules here if you wish. If you are on a dialup machine, the INTERNAL setting would be your dialup interface with a /32 subnet mask, indicating the host itself. Additionally, you may need to configure syslogd to log snort and other security events to a specific log file. Edit /etc/syslog.conf to log snort alerts, then signal syslogd to re-read the /etc/syslog.conf file: authpriv.* /var/log/secure.log [root@krypton ~]# /usr/bin/killall -HUP syslogd Using Preprocessors The preprocessor directives listed above are used to examine the data flow before the intrusion detection engine applies the ruleset to the packets. This can be used to modify the contents of the packet, or to signal the detection engine to not process a particular packet. The preprocessor http_decode: directive instructs the detection engine to convert the data within HTTP URI strings into a format that defeats attempts at eluding the content analysis strings used to examine HTTP traffic for suspicious activity. Supply the ports on which a web serveris running. The preprocessor portscan: directive is used to define the host or network for which snort should watch for a portscan. The /32 appearing after the IP addresses indicates CIDR notation for a 32-bit subnet mask (the host itself). For a Class C network, use /24 . It may also be necessary to exclude some hosts from triggering the portscan detection module. Boxes that generate legitimately generate traffic on a large number of ports in a short amount of time, including NFS or DNS servers are typical candidates. More on Patrick Mullen's portscan preprocessor can be found at . The portscan-ignorehosts preprocessor is used for this, and includes the hosts to ignore as its argument seperated by spaces: preprocessor portscan-ignorehosts: 63.87.101.90/32 63.87.101.92/32 You might consider trying it without the portscan-ignorehosts directive first, as you don't want to unnecessarily disable the ability to detect portscans if it's not necessary. The minfrag preprocessor checks for fragmented packets which can be used to disguise TCP packets from IP filters used in routers and hosts. Packets less than 512 bytes do not need to be fragmented with modern networks, and packets found smaller than that typically indicate attempts to subvert a firewall or intrusion detection. You should now be able to test your configuration file and the normal operation of snort: [root@krypton ~]# snort -d -l /var/log/snort -c /etc/snort/rules.base Initializing Network Interface... User level filter, protocol ALL, raw packet socket Decoding Ethernet on interface eth0 Initializing Preprocessors! ------------------------------------------------- Keyword | Preprocessor @ -------------------------------------------------http_decode : 0x8053070 minfrag : 0x8053290 portscan : 0x8053ce0 portscan-ignorehosts: 0x8054340 -------------------------------------------------InitializingPlug-ins! ------------------------------------------------- Keyword | Plugin Registered @ -------------------------------------------------content : 0x8052050 offset : 0x8052080 depth : 0x80520f0 nocase : 0x8052160 flags : 0x8052710 itype : 0x80528f0 icode : 0x8052a00 ttl : 0x8052b10 id : 0x8052bf0 ack : 0x8052cd0 seq : 0x8052dc0 dsize : 0x8052ec0 ipopts : 0x8054420 rpc : 0x8054670 icmp_id : 0x8054830 icmp_seq : 0x8054930 session : 0x8055300 -------------------------------------------------Initializating Output Plugins! ------------------------------------------------- Keyword | Output @ -------------------------------------------------alert_syslog : 0x8054a20 log_tcpdump : 0x8054ff0 ------------------------------------------------- +++++++++++++++++++++++++++++++++++++++++++++++++++ Initializing rule chains... 255 Snort rules read... 255 Option Chains linked into 140 Chain Headers +++++++++++++++++++++++++++++++++++++++++++++++++++ Performing Rule List Integrity Tests... ---------------------------------------Alert TCP Chains : OK Alert UDP Chains : OK Alert ICMP Chains : OK Log TCP Chains : Empty list... Log UDP Chains : Empty list... Log ICMP Chains : Empty list... Pass TCP Chains : Empty list... Pass UDP Chains : Empty list... Pass ICMP Chains : Empty list... --------------------------------------- -*> Snort! 192.168.200.189:32771 TCP TTL:42 TOS:0x0 ID:5410 ***F*P*U Seq: 0x0 Ack: 0x0 Win: 0x400 00 00 00 00 00 00 ...... The corresponding syslog entry looks like: Jun 18 00:48:31 krypton snort[8757]: MISC-Attempted Sun RPC high port access: 192.168.100.189:57554 -> 192.168.200.189:32771 Several perl scripts exist to process this information intoan HTML page which can be accessed periodically to determine what is occuring on the network. The snort2html is a perl script written by Dan Swan that does a nice job of producing useable information in HTML format. If you decide to save this in a directory accessable by a web server, be sure to apply the proper authentication mechanism to prevent outsiders viewing this file. It contains a great deal of helpful information to a potential intruder. It can be used as follows: [root@krypton ~]# /usr/bin/snort2html /var/log/auth.log This will produce an HTML file in /var/log/snort-log.html that is for use with the Max Vision ruleset and creates links to the CVE definition of each intrusion attempt. This version has been modified from the original to accept the filename from the command-line. You can edit this file to save the resulting HTML file in another location. Resources Lance Spitzner shows snort in action as he tracks an intruder and performs forensic analysis on the trails of the intruder. Fyodor has put together a document that describes the snort internals The snort download page includes pointers to source code, plugins to send snort output data directly to a database, the Win32 port, and the latest rulesets. The snort.org has a wealth of helpful information and documentation. Have questions or comments about this document? We'd love to discuss them with you- please leave a comment below! . Delve into Suricata, the advanced network threat detection framework. Configure triggers and observe network breaches in real-time.. Snort Detection, Network Monitoring, Intrusion Alerts, Open Source Solutions. . Brittany Day
Jan 14, 2022
•
102
open source softwarelinux distributionsecurity toolsExplore Predator-OS 20.04 LTS: A Secure Linux Distro for Pentesters
Predator-OS - "the OS that naturally preys on others"- is a free and open-source security-centric project for penetration testing and ethical hacking that can also be used as a privacy-focued, hardened Linux distro. LinuxSecurity researchers spoke with Founder and lead developer Hossein Seilany to get insight into the unique features and benefits that newly released Predator-OS 20.04 LTS offers hackers, pentesters and privacy-conscious Linux users. . Predator-OS was established in 2021 and is maintained by Hossein Seilany. It is a free open-source community project, Free (as in freedom). The project just recently announced the release of Predator-OS 20.04 LTS. Predator-OS is well-suited for penetration testing and ethical hacking and also provides a secure, anonymized Linux OS. Predator Linux is based on Ubuntu 20.04 LTS Mini, kernel 5.10 LTS, and uses a fully customized xfce4 lightweight desktop with a special menu of tools. Predator Linux has around 1300 pre-installed tools which are split into 40 categories. These tools are imported from both Debian and Ubuntu repositories and the GitHub page. Most kernel and user configs are customized by default to prevent hacking, non-privileged access, and to reduce the attack surface. A wide array of built-in firewalls and defensive tools provide end-users with granular control over the OS. The distro can be run as Live-CD or from a USB Drive and installation mode. Operates in 9 Different Modes Predator-OS has nine different modes and operates in the following modes for easy and faster access to all tools: defensive, offensive, privacy, hardened, secured, settings, and pentesting modes. Users can switch between these modes quickly and easily. The Predator-OS distribution has its own unique features and benefits including: Easy installation and extensive hardware support Lightweight with a user-friendly interface Includes all features and tools of popular secure Linux distros - and more! Offers the ability to run Windows tools onLinux Users have the option of either booting live or installing You can view a full list of the distro’s features predator-os downloads. Predator-OS At-A-Glance OS Type: Linux Based on: Ubuntu Mini 20.04 LTS Kernel: 5.10 LTS Architecture: armhf, i686, PowerPC, ppc64el, s390x, x86_64 Desktop: Xfce Other Desktop: as soon as possible: KDE plasma, mate Category: penetration testing, security, privacy, Forensics, Live Medium, hardened, anonymized Click> predator-os downloads to download Predator-OS on your system. Are you using Predator-OS? If so, we'd love to hear your thoughts and feedback! Please share your experience in the Comments section below. . Unveil the capabilities of Viper-OS 20.04 LTS, an innovative Linux distribution tailored for security testing and safeguarding personal privacy. Explore further.. Predator-OS, Ethical Hacking Tools, Open-Source Pen Testing, Privacy Focused Linux. . Brittany Day
Jan 05, 2022
•
102
open source softwareLinux securitycybersecurityEnhancing Remote Work Security With Linux Customization And Tools
Operational security at least seemed so much easier back when traditional 9-to-5 office life was still dominant. Talk of professionals taking their work home with them was largely metaphorical, with only occasional instances of C-suite types dragging their laptops everywhere they went. Business hardware and systems would be shielded through physical security and isolated networks. One office (or office complex), one place to guard: entirely straightforward. . Now, after a year that’s seen countless businesses (some eagerly and others reluctantly) adopt the working-from-home model, there are different challenges to overcome. Teams are scattered and must share sensitive data across the internet — data to which other companies and fraudsters would love to gain access. When information gets out, reputations are destroyed and businesses (particularly those working entirely online) struggle to survive. So what can be done about this? Well, there are various steps you can take to improve cybersecurity, and in this post we’re going to consider whether the use of Linux is one of them. Can companies bolster their remote-working operations — even offline — through swapping their current operating systems for Linux? Let’s see what conclusions we can reach. What are the strengths of Linux for securing online activities? While this certainly isn’t a comprehensive account of what makes Linux great for online security, there are three long-standing benefits of Linux distributions that we should focus on here: They’re entirely customizable, removing the need to rely on third parties. Windows is updated by Microsoft, and iOS is updated by Apple. It’s possible to find unofficial and unsigned patches, but they’re always going to cause issues with support services (and that’s if they work at all). This means that those using these systems must rely on those companies to react appropriately to security threats. Because Linux is open-source software, it doesn’t rely on securityupdates from any single provider, and its ever-improving compatibility options make it a stable like-for-like replacement. If you want to run a VPN service, you’ll find that all the leading contenders support Linux — and if you want to do something like implement a system-level proxy server, you can easily load up a caching proxy like Squid through the terminal. Additionally, the fundamental transparency of Linux makes it relatively simple to review for potential security issues. If you’re willing to put in the effort to steer the ship, you can achieve far more impressive levels of security through Linux systems. They’re updated by people who care about privacy and security. Leading software companies do care about security, but largely in the sense that their profits and reputations are affected by system vulnerabilities. Linux, on the other hand, is heavily driven by passionate enthusiasts who actually care about user privacy. If you’re looking to resolve a certain issue, you can inevitably find free community support to point you in the right direction. And if you want to run a cut-down OS with none of the default telemetry services that plague all the mainstream alternatives, Linux isn’t just your best option: it’s your only practical option. Throw in superior support for things like using SSH and saving and reviewing comprehensive log files, and you have a fantastic out-of-the-box option (so to speak) that will only get better the more you work on it. They’re not high-priority targets for hackers due to their niche appeal. While it’s true that Linux servers have become very popular ( and thus attracted attention ), the same can’t yet be said of Linux desktop operating systems. Almost all attention goes towards Windows and iOS, all because it’s far more economical to target them. On top of that, you need to factor in the presence of different Linux distros. Where Windows installations will differ only marginally, systems running on Debian,Red Hat and Linux Mint can have far more substantial differences. There isn’t much motivation for a hacker to specifically target Linux Mint systems, making them much safer. How can Linux secure remote-working hardware? We’ve looked at how Linux helps to secure online operations, but what about offline activity? Remote-working hardware still poses a threat, after all, and needs to be kept in line. Well, just as it supports plenty of online security services, Linux also offers a tremendous array of at-home security solutions that allow extensive configuration. For businesses that still want to use office spaces (or those determined to monitor their remote-working employees extremely closely, however much that seems like a bad idea), there’s open-source monitoring software like Zoneminder . For network user authentication (key for all remote-working companies, and often managed through cloud systems like Azure Active Directory), there’s the free Kerberos protocol. And for those who need to keep their business hardware secure on the go (despite lockdowns, there are still workers who need to travel), it’s easy enough to take advantage of tools like the Yubico Pluggable Authentication Module (PAM). The PAM makes it convenient to use hardware dongles for user authentication, ensuring that lost laptops don’t present major weaknesses. Linux can shield smart technology from threats by offering a robust and customizable security framework capable of combating a wide array of cyber vulnerabilities. What is the value of tech comprehension in cybersecurity? User error is the one thing that even the most tightly-secured systems can’t fully move past. This is why social engineering is such a popular endeavor for fraudsters. Hacking an up-to-date system is complicated and risky, while convincing a poorly-trained employee to volunteer their login details under false pretences can provide quick success. Due to this, ensuring that your employees have strong awareness of security basics willdo much to make your operation stronger — and though Linux still has an intimidating learning curve, it’s sufficiently approachable that you could make it your main operating system without asking more of your workers than they can reasonably provide. It certainly helps that so much is done through browsers at this point. If someone can use a Chromebook, they can get to grips with a Linux distribution, and learning more about how Linux works (and how it treats something like admin authentication) will slowly but surely leave them less likely to make basic security mistakes. Wrapping up, the answer to the titular question is a strong yes. Less likely to be attacked than other systems, built with security and flexibility in mind, and equipped with rich compatibility features that make it easier than ever to swap from Windows or iOS, Linux is a mature solution that every modern business should consider using. About the Author Elliot Mark is a senior writer at Ecommerce Platforms with a deep curiosity for all things digital and the changing world of ecommerce. He’s helped create a number of unique online stores, providing content and marketing support to help people grow their own ecommerce biz. Connect with him on Twitter @EcomPlatformsio. . In today's remote work environment, Linux emerges as a strong OS that enhances organizational security with its built-in features and community support. Remote Work Security, Linux Customization, Cyber Tools, Open Source Solutions, Cybersecurity Best Practices. . Brittany Day
Apr 19, 2021
•
102
network securityopen source softwarecyber defenseImplementing Geolocation For Nftables: A New Era In Firewall Security
What if you could block connections to your network in real-time from countries around the world such as Russia, China and Brazil where the majority of cyberattacks originate? What if you could redirect connections to a single network based on their origin? As you can imagine, being able to control these things would reduce the number of attack vectors on your network, improving its security. You may be surprised that this is not only possible, but straightforward and easy, by implementing geographic filtering on your nftables firewall with Geolocation for nftables . . Geolocation for nftables is a simple and flexible Bash script released in December of 2020 designed to perform automated real-time filtering using nftables firewalls based on the IP addresses for a particular region. In a recent interview with LinuxSecurity researchers, the project’s lead developer Mike Baxter explained the mission of Geolocation for nftables, “I hope this project is beneficial to those who may not have the IT budget or resources to implement a commercial solution. The code runs well on servers, workstations and low-power systems like Raspberry Pi. The script has the built-in ability to flush and refill geo filtering sets after a database update without restarting the firewall, allowing servers to run uninterrupted without dropping established connections.” This article will examine the concept of geo filtering and how it could add a valuable layer of security to your firewall, and will then explore how the Geolocation for nftables project is leveraging Open Source to provide intuitive, customizable geo filtering on Linux. What Is Geo Filtering? Geo filtering is a firewall technology that filters and blocks both incoming and outgoing network connections based on geographic location using IP addresses. Geo filtering technology enables a computer firewall to compare the source or destination IP address of a network packet to a list of location specific IP address ranges, which can be found in freelyavailable geolocation databases such as db-ip.com . Firewall rules can then determine what to do with each packet - accept, reject, redirect to a server with localized content, drop, or simply count the packet - based on the location of its origin or destination. How Can Geo Filtering Enhance Firewall Security? Geographic filtering enables administrators to mitigate threats to their network by blocking IP addresses associated with countries or locations where the majority of cyberattacks originate, or that they have no reason to allow traffic from. If you have no reason to accept incoming online communications from certain countries, then implementing whole-country Geo filtering on your firewall may make sense. However, keep in mind that if you’re using software or online services from other countries, you may have to accept communications from these countries. Cutting off entire countries is quick and effective, but in many cases it makes sense to use more sophisticated IP filtering settings to either block only certain IP addresses, ranges of IPs or lists of IPs known to be malicious, or to create rules in your firewall that make exceptions and allow trusted IP addresses to access your systems. Geo filtering is a valuable security feature, but does have some limitations. For instance, the technology could potentially block legitimate online traffic, and isn’t able to prevent targeted attacks, as criminals can easily hide their location by using servers or compromised computers in different locations to launch attacks. Implementing Geo filtering on your nftables firewall can add a valuable layer of security to your network by reducing its attack surface and helping to protect against malware and other dangerous, persistent threats - but it should not be viewed as a cybersecurity cure-all. Baxter emphasizes the importance of implementing this technology as part of a comprehensive, defense-in-depth approach to cybersecurity: “Geo filtering is one layer of security that can help to reducethe number of attack vectors on a computer or network, but it’s not a silver bullet. There are ways around every type of computer security, so it’s important to do security in layers.” Geolocation for nftables Leverages Open-Source Development to Make Filtering by Country Seamless, Easy & Effective Geolocation for nftables makes implementing real-time geographic filtering on your nftables firewall simple, convenient and effective, while offering granular control over network traffic. The Bash script converts the 400,000 lines of IP address ranges and country codes in its database to a format that Linux nftables firewalls can access with firewall rules. The script automatically generates country-specific nftables address range sets, and automatically determines the installed version of nftables and recommends the correct "include" statements for an administrator’s ruleset. User settings are conveniently stored in a standard configuration file, as opposed to using command line arguments. The geographic database is automatically downloaded from db-ip.com in real-time, keeping nftables Geo Filtering sets up-to-date. This is critical, as the IP address ranges assigned to each country change over time and geographic databases must be updated regularly in order to remain accurate and effective. Geolocation for nftables also has the unique ability to automatically run an nftables script to flush and refill IP sets with new data after a database update, allowing servers to run uninterrupted - without dropping established connections. Geolocation for nftables is an open-source project, and offers users an array of unique benefits that can be attributed to its use of Open Source - namely, enhanced security and a high level of customization. The script is easy to set up, configure and tailor to meet your specific needs with open-source code that is heavily vetted by the community. The “many eyes” reviewing this code on an ongoing basis results in rapid identification and elimination ofvulnerabilities and security issues. The global community input that the project receives fosters innovation by offering ideas, feedback and programming expertise. Geolocation for nftables source code is heavily commented on, making it easy to understand and customize. This selection of benefits comes at no cost to the end user as, in the words of Baxter, open-source development is “just people helping people”. Geolocation for nftables seamlessly integrates with other firewall applications by allowing multiple matches per firewall rule, so matches can be combined with matches from other sources to determine how a network packet is handled. For instance, an administrator can accept a packet with an IP address that’s on his or her IP “allow” list, but not on his or her Fail2ban “block” list with a single firewall rule. Geo Filtering for nftables has a small memory footprint and offers flexible configuration, making the script ideal for any system - even those with limited RAM. Key feature and benefits of Geolocation for nftables include: A script written for the widely used Bash shell that automatically generates country-specific nftables address range sets Easy to implement, configure and customize with heavily reviewed open-source code Small memory footprint and flexible configuration makes the script run well on systems with limited RAM User settings are conveniently stored in a standard configuration file rather than using command line arguments Packets can be filtered by geography with a single nftables rule rather than two rules to mark and match packets Automatically determines your installed version of nftables and recommends the correct "include" statements for your ruleset Creates "include-all" files to allow you to include all geographic IP sets with a single reference on older versions of nftables that don't support include wildcards Offers a User Guide which explains how to define all element definitions for Geolocation sets in one file, eliminating thechance of having out-of-sync definitions in multiple files when flushing and refilling sets with new data Simplified directory structure to shorten "include" path names Creates ~500 IPv4 and IPv6 set files from the geographic database in about 10 seconds on a low power quad-core 2200ge server with SSD storage Tested on Ubuntu Server , Fedora Server , and Raspberry Pi OS Key Takeaways Geographic filtering is a valuable layer of defense that you should consider adding to your nftables firewall to reduce the attack surface on your network and help secure your system against malware and other serious, prevalent threats. Geolocation for nftables provides Linux users with a simple, flexible and automated way to implement real-time geographic filtering on their nftables firewall. Visit the project’s Github page to learn more about Geolocation for nftables and how you can install the script on your system. Please reach out to us if you have an open-source security project you would like us to cover in a future LinuxSecurity feature article! Connect with us on social media: Twitter | Facebook . Enhance your network security using Geolocation with nftables, a versatile Bash script designed for live geo-filtering on Linux firewall systems.. GeoFilter, NftablesSecurity, BashScript, FirewallEnhancement, LinuxSecurity. . Brittany Day
Feb 09, 2021
•
102
security practicesopen source softwarecommunity contributionThe TANSTAAFL Price and Developer Burnout in Open Source Projects
Open-source projects can become victims of their own success. What can developers do to secure their open-source software? . One of the reasons behind the popularity of Open Source is the volunteer communities improving and updating code. It’s what software developer and author Eric Raymond called Linus’s Law in action: with many eyes looking at code, “all bugs become shallow.” A Purdue University study showed that Linus’s Law does work. Open-source communities regularly issue patches faster than their proprietary software counterparts. But Linus’s Law only works when there are enough eyes on the code. And there’s no guarantee that the community behind any given open-source project will continue maintaining the code. Of the 1,200+ codebases examined for the 2020 Open Source Security and Risk Analysis (OSSRA) report , 88% contained open-source components that had had no development activity in the last two years. OpenSSL, Heartbleed, and Developer Burnout OpenSSL, an open-source encryption protocol, secures a substantial portion of the web: as much as two-thirds of all active websites, plus hundreds of thousands of email servers, chat servers, and VPNs, as well as the network infrastructure of various military, government, and financial institutions. In 2011, a programming bug that allowed an attacker to intercept information secured by OpenSSL was introduced into the code, where it remained undiscovered for almost three years before being reported by a Google developer. Within 24 hours of its disclosure, the vulnerability, dubbed “ Heartbleed ,” was used to break into a major corporation and steal taxpayer data from the Canada Revenue Agency, according to a report in The New York Times . Although a patch was quickly issued, Heartbleed still lives on in hundreds of thousands of devices, with Shodan—an Internet of Things search engine—reporting over 91,000 instances of the vulnerability as of late 2019. Steve Marquess, the former CEO of the OpenSSLFoundation, noted in a blog post that the coding error leading to Heartbleed was partially attributable to developer burnout. In 2011 there was only one overworked, full-time developer on the OpenSSL project. “There should be at least a half dozen full-time OpenSSL team members, not just one,” Marquess wrote. And that developer should be “able to concentrate on the care and feeding of OpenSSL without having to hustle commercial work.” Things have improved somewhat in 2020. There are now 18 contributors listed on the OpenSSL site and their work is funded through at least 2021, thanks to a grant from the Linux Foundation Core Infrastructure Initiative, a project dedicated to distributing resources to open-source projects that are critical to the security of the Internet. But the Heartbleed bug is what happens when people ignore the TANSTAAFL price. The TANSTAAFL Price In the early 19 th century, “free lunches” were a popular saloon promotion. Patrons still had to buy a beer or other drink in order to wash down whatever food the barkeep offered, and that was the catch. Profits on whiskey and beer sales more than compensated the saloon for putting out the free lunch spread, which often was little more than soup, crackers, and problematic pickled eggs. Coined by science fiction author Robert Heinlein, TANSTAAFL (“There ain’t no such thing as a free lunch”) reminds us that things always have to be paid for, whether the price is evident or not. With popular open-source code, the TANSTAAFL price has been the increased pressure on its maintainers—the people who handle bug reports, feature requests, code reviews, and code commits for their “free” software. Increasingly, as open-source software grows in popularity, the TANSTAFFL price has been developer burnout and their open-source projects being abandoned. It’s the tragedy of the commons in action—a resource growing so much in popularity that it can’t remain viable unless the community shifts to sustenancerather than exploitation. Witness the Twitter thread started by James M. South, creator of several popular open source solutions, who bemoaned the fact that, “#ImageSharp passed 6 million downloads this weekend and I’m a lot less happy about it than I probably should be.” Why? South goes on in several follow-up tweets, “Over 5 years of development there have only been 98 collaborators, 23 of which have made more than 10 commits…. it’s not about money, it never was and never will be, it’s about sustainability.” Several other developers chimed in with their experiences: “…a similar story for #FluentValidation. Over 41 million downloads … 140 contributors, but only 1 has made more than 10 commits.” “Same with ReportGenerator… 15 million downloads but not a single sponsor.” Too few people—and their organizations—who rely on open-source software are contributing to the projects whose open-source software they use. If you’re a developer and have a favorite open-source component, you can contribute to its development through development, sharing your modifications, bug reporting, crowd-funding, letting the developers know how you are using it, and helping others get started. That last may be the most important thing you can do for any open-source project—helping build a user community large enough to sustain the project. While development support is important, it’s not necessarily just about the code. Whether you’re a writer, translator, designer, or information security or legal specialist, the chances are good that you too can help support the community in some fashion. About the Author Fred Bals is a researcher and senior technical writer at Synopsys . This post originally appeared on the Synopsys Software Integrity blog . . Open-source projects can thrive sustainably by building inclusive communities and prioritizing developer well-being, which reduces burnout and encourages flexibility. Open Source Contributions, DeveloperCommunity Support, Secure Open Source, Software Project Maintenance, Community Engagement. . Brittany Day
Sep 22, 2020
•
102
open source softwaresecurity insightscyber defenseDefcon 26 Highlights on Cyber Defense And Open-Source Security
Defcon 26 provided individuals and organizations with valuable tips and insight on security and the latest and most effective defenses. Here are some security-related highlights from the event.. Defcon 26, a high-profile hacking conference that recently took place in Las Vegas, offered a multitude of predictions and implications regarding changes and trends in the field of cyber security. Although Defcon is an event that is mainly attended by ethical hackers who are aiming to learn how to better protect the systems they are responsible for, everyone can gain knowledge from the experts who spoke and the activities and contests that took place at Defcon 26. With cyber threats becoming increasingly prevalent and dangerous, cyber security is an issue that affects all individuals and organizations. According to CSO, cyber crime damage costs are expected to hit $6 trillion annually by 2021 (CSO Online). Email is an extremely popular attack vector used by cyber criminals, so effectively securing email accounts is becoming increasingly important. Here are two highlights from Defcon 26 and a summary of what they suggest in the context of today’s cyber threat landscape: 1. NSA Brings Nation-State Details to Defcon: “Spot the Fed” has been a longstanding tradition at Defcon, but the task was extremely easy this year. Rob Joyce, senior advisor for cybersecurity strategy at the NSA, discussed the latest details on nation-state hacking and defense. He suggested that there are four actors that are most concerning in regard to nation-state hacking: Russia, China, Iran and North Korea. In terms of defense strategies, Joyce emphasized that the transparency provided by public hacking is critical in finding and fixing flaws that nation-state hackers could exploit. He also referred to cybersecurity as a “team sport”, suggesting that the government and private enterprises should share information on vulnerabilities and attacks. Finally, Joyce reminded the audience that basic security measures, such as software patchingand multifactor authentication, should not be overlooked. (DarkReading) 2. Tesla Plans to Open-source Security Software: Following Defcon 26, CEO of Tesla Elon Musk announced that Tesla is planning to open-source its security software to other automakers for free. Musk feels that doing this will decrease the risk of cyber criminals hacking self-driving vehicles. Tesla has a good relationship with security researchers and whitehat hackers, whose work has led to the rapid fixing of various vulnerabilities in the past. Open-sourcing security software will likely encourage more security researchers to search for and identify vulnerabilities, making Tesla cars even more secure. (Electric) These are just two of many security-related highlights of Defcon 26. The schedule was packed with speeches from experts in the field of security, hacking-related activities and contests and Q & A sessions. As expected, Defcon 26 proved to be a hub for innovation in the field cyber security and advancement in the practice of ethical hacking. With the evolution of cyber crime and email-related threats, it is crucial that businesses and individuals stay informed and implement the latest and most advanced defenses and protection strategies. . Defcon 26, a high-profile hacking conference that recently took place in Las Vegas, offered a multit. defcon, provided, individuals, organizations, valuable, insight, security. . Brittany Day
Sep 06, 2018
•
102
network securityopen source softwareconfiguration managementExploring SCC: An Exclusive Interview with Siem Korteweg Uncovered
In this interview we learn how the System Configuration Collector (SCC) project began, how the software works, why Siem chose to make it open source, and information on future developments.. Introduction : Have you ever noticed changes on your departmental server, but couldn't quite pinpoint what exactly happened? How many times have staff forgotten to make an entry in the log-book, or the entries made were not detailed enough? Administrators are faced with these problems on a day-by-day basis. The System Configuration Collector (SCC) project attempts to automate this process. Rather than depending on staff to keep accurate records, SCC enables a system to record all changes taking place. Additionally, the software has the functionality to send all configuration data to a central server so that it can be analyzed when needed. System Configuration Collector Project Website: LinuxSecurity.com : Please tell us about the SCC project and how it began. When did it start, and who are some of the key contributors? Siem Korteweg : In 2001 a younger colleague asked whether it was possible to automatically track the changes that were made to the configuration of a system. I told him that was impossible due to variable nature of the output of the commands we have to use to show the configuration of a system. Being a much younger colleague he accepted this answer. But I did not like to say it was "impossible" and it kept nagging me. I thought that when I could split the variable and fixed parts of the output of system commands, I would be able to track changes. I started a small, hobby project by collecting configuration data and preceding each line with "fix:" or "var:". After some time I was able to detect some changes made to configuration. But when a kernel parameter was changed, all I saw was a change from 128 to 256. I had to search in the snapshot to find out what part of theconfiguration had changed. Therefore I extended the fix-var classification with a hierarchy of keywords indicating the nature of the data. The development continued and the customer where I was developing the software, was wondering how to maintain this software without hiring me indefinitely. By that time I realized that this software also could/should be used by others. I talked to the manager of the customer and to the manager of the company I am working for and suggested to make SCC a GPL project. They both agreed and from then on, SCC was an Open Source project. To extend the collection of configuration data I looked at the code of cfg2html and check.sh (HP specific) and the FAQ's of several newsgroups. At the customer site where I started developing SCC, we deployed the software on some 300 systems. This gave us a great opportunity to tune the "fixed" and "variable" parts of the configuration to avoid unnecessary changes. The first versions of the software collected configuration data and converted the data and logbook to HTML on a per system basis. At the customer site, Bram Lous started to collect all snapshots and logbooks on a server and built the first version of the CGI-interface. Later on, Paul te Vaanholt contributed much for the HP OpenView modules. His main contribution is the analysis and conversion to SCC-format of the Operations Center database. A colleague Oscar Meijer wrote the Windows version of the SCC-client, based on WMI and WSH. The configuration of the data we are collecting on Windows systems still needs to be tuned. The software itself is stable, but it detects too many changes. The whole process of tuning what data is "fixed" and what data is "variable" takes quiet some time. LinuxSecurity.com : What is the most important benefit an administrator can get out of SCC? How can this improve the overall security of a network or host? Siem Korteweg : Each administrator should document his/her systems. We all know that, but we all lack time to do this properly. SCC automates the documentation process. For HP-UX systems SCC collects more than 95% of the configuration of the system is covered by SCC. For other system the percentage is somewhat lower at the moment. The logbooks and snapshots can assist administrators in finding the cause of an incident. Configuration changes can have unwanted side-effects (on other systems). By examining the logbooks for the changes during the last days/weeks an administrator might find the cause of an incident easier/faster. Another way of using the SCC-data to find the cause of an incident is to compare (parts of) the configuration of a system with a comparable system that does function correctly. Comparing the configuration of systems can also be used to assure that the systems in a cluster are consistent and identical. Do they run the same (versions of) software? Do they have the same kernel-configuration? It is also possible to check your security policies. Just check the snapshots on the server for the aspects of the policies. By default the server checks and signals accounts without a password. Another use of the SCC-data on the server is to quickly identify systems. After an advisory from Sun, I was able to identify within one minute the 100 systems that needed to be addressed out of a total of 600 systems. Because the selection was automated and because the collection of SCC-data was accurate and outdate, I did not miss a system. This obviously contributes to the safety of the network. LinuxSecurity.com : How difficult is it to get started? How long would it take for an administrator to get the system fully setup? Can you describe at a high level the steps necessary to setup SCC? Siem Korteweg : The easiest way tostart and get the feeling of the software is to install only the client part and keep the data and logbook on the client. Just create a simple cron-job after the installation of the client and you are finished. This way you are able to pilot the software before you deploy it more widely. The setup of the server takes some more steps. First you have to decide how to transport the SCC-data from the clients to the server. Supported mechanisms are email (optionally encrypted, using OpenSSL), scp, rcp and cp. Then setup the webserver to display the data. To achieve this, you have to indicate the path under the document-root and indicate the CGI-script of SCC. Then schedule a cron-job to transfer the SCC-data that is sent by the clients from the transfer-area to the website Finally all cronjobs of the clients have to be extended with the proper options to transfer the SCC-data to the scc-server. For several systems I recorded the entire process of configuring the server in logbooks. These logbooks are present at the website. For our HP-UX 11.i system: LinuxSecurity.com : What improvement would you like to make in the future? What direction is this project heading? Siem Korteweg : When running SCC on a system that uses clustering software, like MC ServiceGuard from HP, switching a "package" from one system to another, results in changes of the SCC-data for both systems involved in switching. We want to make the software cluster-aware by extracting the configuration data for each package and sending it separately to the scc-server. Another future extension is the collection of the configuration of network devices like routers and switches. LinuxSecurity.com : What advantage does SCC have over using a typical pen & paper log book for recording system changes? Siem Korteweg : It is automated, so it does not "forget" to record achange (supposing the changed attribute is part of the SCC-snapshot). It is not lazy (once you run it through cron). - The pen & paper logbook is a physical item that can only be at one place. Each admin of a group of systems can be at a different place, without access to the paper logbook. Suppose 7x24 systems, where the admins "follow the sun". - By consolidating all snapshots on a system with scc-srv, you obtain much data that can be searched automatically. This enables you to quickly identify the systems that need an update or to compare two systems when one of them does not function correctly. This is impossible with pen & paper. LinuxSecurity.com : What operating systems does SCC run on? What type of license is it under? Siem Korteweg : HP-UX, Solaris, AIX, Linux (RedHat, Suse, Gentoo). As the code of SCC only uses "standard" Unix tools, I think it runs on almost all Unix/Linux systems. The coverage of the configuration data depends on the OS. For example the coverage of HP-UX configuration is more than 90%. For other systems this will be less. The license is GPL. LinuxSecurity.com : If an administrator needs assistance setting up or configuring SCC is support available? If so, how can support be obtained? Siem Korteweg : Besides the documentation on our website, SCC comes with documentation and manual pages. We offer an implementation service, where a consultant visits a customer and installs the server and at most 5 clients and introduces the software to the admins of the customer. This is only feasible in the Netherlands. Otherwise, support via email is possible. When the requested support is more than a few simple questions, we have to agree upon payment. LinuxSecurity.com : How does SCC differ from other similar configuration collectors? What are some of the strengths and weaknesses of SCC? SiemKorteweg : SCC collects configuration data without formatting it immediately to HTML. Instead it prefixes each line of configuration data with fix/var and a hierarchical classification. This makes it easy to process the snapshots. The processing consists of comparing consecutive snapshots to generate the logbook, formatting the snapshot to HTML and comparing the snapshots of two systems to determine the differences. The philosophy of SCC is to collect data, not to judge its value or correctness. Stupid configuration errors in Apache/Samba are not detected in scc, this should be done at the server where all snapshots are collected. Some might question the value of all the data in the snapshots. It is true that a considerable part of the snapshots will never change during the lifetime of a system. Nevertheless this data is collected, just in case someone needs it sometimes. One commercial configuration collector works by allowing remote root-access to all clients from their server. This is not very security minded. I had security in mind when coding scc and scc-srv. A weakness of SCC is that I coded the classifications of all collected configuration data. This classification has to be used when an admin wants to view specific information. I decided to store cron configuration data under classification "software:cron:" and swap info under classification "system:swap:". Each user of SCC has to follow my intuition. Another weak point is that the clients are autonomous. The scc-srv can be DOSed by mailing much snapshots from seemingly different systems. Therefore, I suggest to install scc-srv only in a "trusted" network. Finally, scc has to do "reverse engineering" to collect for example the Apache configuration. Apache can be installed and configured in dozens of different locations. We have to determine the correct paths and files from the running processes. LinuxSecurity.com : How can the project benefit from the open source community? Siem Korteweg : The project can benefit from the open source community when admins use it and contribute their extensions. These extensions can be specific applications/hardware/OS they use or new features. At the moment some people already contribute knowledge of specific software. Feedback concerning the strong and weak aspects admins experience while they are using SCC, is also valuable. Area's for future extensions are SAN/NAS and network devices. I am looking for people and organisations that are willing to contribute in any way in these areas. LinuxSecurity.com : I wish to thank Siem, and other contributors to the System Configuration Collector project. We at LinuxSecurity.com would like to wish you the best of luck! . Introduction: Have you ever noticed changes on your departmental server, but couldn't quite pinpoint. interview, learn, system, configuration, collector, (scc), project, began, softw. . Brittany Day
Mar 25, 2004
•
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!