Overly broad permissions can turn one compromised account into a much larger security problem. Learn how to reduce unnecessary access, review privileges, and apply least privilege across modern Linux systems. Review Linux Privileges×
Stay Ahead With Linux Security Features
identity management security tactics For years, we secured our Linux infrastructure by building walls: VPCs, security groups, and hardened SSH configurations. We treated the cloud like a virtual data center, assuming that if we kept the "bad guys" out of the network, our workloads were safe. . That model is no longer sufficient. Today, one of the most common paths from an initial compromise to a major cloud breach is the identity assigned to your Linux workload. When an attacker gains code execution on a Linux instance—through a...
Jul 17, 2026
security practices patch management Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange...
Jul 14, 2026
Linux security cyber attacks Every Linux server in your fleet produces thousands of events every minute. From journald logs and auditd records to kernel-level eBPF hooks, your systems are constantly talking. Most of that noise is just the mundane churn of system services, CI/CD runners, or routine administrative automation. But among that noise, an attacker might be establishing a foothold, moving laterally, or setting up persistence. The challenge for any security team is: how do you separate the routine from the...
Jul 13, 2026
open-source infrastructure risk Security scanners flag exposed API keys in public repositories every day. The initial response is usually predictable: delete the commit, revoke the credential, and move on. That’s a mistake. . In a real Linux environment, an API key never stays in one place. By the time it hits a public repo, it’s already everywhere. It’s in the CI/CD pipeline. It’s in your container registry. It’s in the build logs. It’s in the backups. Git makes this worse because the history never dies. Deleting a file in...
Jul 11, 2026
open-source rootkit Most of us think of Linux rootkits as ancient history—the stuff of 90s hacking forums and clunky malware that would crash your system if you looked at it the wrong way. But if you think they’ve gone away, you’re mistaken. They’ve just gotten smarter. . Modern attackers aren't using the noisy tools of the past. Today’s threats are surgical. Many of today’s most advanced Linux rootkits operate at the kernel level or abuse legitimate system features to blend in with normal traffic. They’re...
Jul 09, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
Loading...
Explore Latest Linux Security features
We found -1 articles for you...
102
system managementLinux securityopen-sourceExploring AI Agents' Influence on Linux Security Threats and Administration
AI didn’t invent hacking, and it didn’t make attackers smarter. It removed friction. Tasks that once required patience, focus, and a fair amount of context now run unattended, looping quietly until something gives or someone notices. . Most AI agents run on Linux. Most of the infrastructure they interact with runs on Linux, too. CI runners, container platforms, build systems, cloud control planes. You start to see the pattern once you trace where agent frameworks live and what they need to touch to be useful. The same agent models show up in red team automation, blue team hygiene checks, and criminal tradecraft. The mechanics don’t change much between those uses. The intent does, and intent is rarely obvious in logs or telemetry when everything looks like normal administrative activity. In this article, we’ll look into what AI agents have changed for hacking, where they still fall short, and why Linux and open source sit at the center of both the opportunity and the risk. This isn’t a prediction about some distant future. It’s an attempt to make sense of the tools already in use, and what they mean for admins responsible for securing Linux systems today. Why Do AI Agents Change the Threat Model? AI agents don’t replace attackers. They remove delay and fatigue. Once you hand an agent a goal, it doesn’t wait for coffee, context switching, or a free afternoon. It keeps going, even when nothing works the first time. That changes the shape of attacks. Instead of a scan here and an exploit attempt there, you get continuous recon, execution, and retry loops that run until they’re stopped or succeed. In Linux environments, where misconfigurations tend to be small and layered, persistence matters more than cleverness. Linux admins tend to feel this shift first. Most agent infrastructure runs on Linux, and most of the services agents probe or control do as well. Containers, SSH access , internal APIs, build systems. The result is activity that looks familiar at a glance, butbehaves differently over time, steady, repetitive, and unconcerned with how long it takes. What Is an AI Agent? An AI agent isn’t just a script with better syntax. It’s a task-driven system that can plan a sequence of actions, execute them, look at the output, and adjust before moving on. That feedback loop is the important part, not the language model behind it. Most agents lean heavily on existing Linux and open-source tooling. Shell commands, API clients, scanners, cloud CLIs. There’s usually nothing novel in the tools themselves, which is why their activity blends so easily into normal administrative workflows. The difference shows up mid-run. A script follows a path until it fails and then stops. An AI agent notices the failure, tries another option, changes parameters, or pivots to a related target. Over time, that adaptability turns routine automation into something closer to an operator that doesn’t need to log off. ARTEMIS: A Neutral Example of AI Hacking ARTEMIS wasn’t built as an attack framework. It’s a general-purpose AI agent designed to break down objectives, call tools, and iterate based on what comes back. In normal use, that means automating complex workflows that would otherwise take a human hours to coordinate. A simple example makes this clearer. Given an objective to assess a Linux service, ARTEMIS might start by enumerating exposed endpoints, then pivot to pulling related configuration files or repository metadata when something looks misaligned. If a scan returns limited results, it adjusts. Different ports, different credentials, a related host. Each result feeds the next action, without a human deciding every step. From a security perspective, it’s useful precisely because nothing about it is malicious by default. Change the objective, point it at exposed Linux services, public repositories, or loosely protected APIs, and the behavior shifts without any change to the core system. Recon becomes just another task. So does persistence. That’swhat makes intent hard to reason about. The same ARTEMIS run can look like legitimate administration, testing, or maintenance in logs and telemetry. Code doesn’t carry motive, and AI agents don’t announce why they were told to act. By the time behavior stands out, the work is often already done. What Do AI Agents Give Hackers? The biggest advantage AI agents bring to hacking is speed, but not the obvious kind. It’s not about one exploit running faster. It’s about many small actions running at the same time, without pauses, across systems that were never meant to be examined in parallel. Where that speed shows up first: Recon across services, repositories, containers, and configuration files happening simultaneously Correlating small signals that would normally be ignored or reviewed later Revisiting the same targets repeatedly without fatigue or loss of focus In Linux environments, exposure often lives in the gaps between tools and teams. That consistency matters. An AI agent doesn’t get distracted or decide something is probably fine and move on. Agents also execute long attack chains reliably. They don’t skip steps or lose patience halfway through a process. For less experienced attackers, that reliability is the real shift. Syntax, sequencing, and tool choice get abstracted away, leaving the human to define an outcome rather than understand every command that leads there. Where Do AI Agents Still Struggle? For all their persistence, AI agents are bad at understanding history. They see what’s there now, not why it exists. In Linux environments shaped by years of migrations, quick fixes, and half-finished projects, that gap shows up quickly. They struggle most with things that only make sense to the people who lived through them: Bespoke workflows and hand-rolled scripts with no documentation Systems whose behavior reflects past incidents or temporary workarounds Inconsistent configurations that were never meant to be permanent Agents assume a level of consistency that rarely exists. They also trust tool output more than they should, especially when permissions or ownership don’t tell the full story. That overreliance on current state leads to quiet mistakes. Misread permissions. Incorrect assumptions about control. False confidence that a path is closed when it’s merely hidden. Humans still catch those faster, mostly because they remember breaking them before. Linux and Open Source as the Amplifier of AI Hacking AI hacking scales because Linux and open source make it easy to build on existing work. Most AI agent frameworks are open. So are the scanners, API clients, and orchestration tools they rely on. An attacker doesn’t need to invent new techniques when the building blocks are already there. The same tools Linux admins use to manage systems show up in agent workflows. SSH libraries, container runtimes, package managers, cloud CLIs. Used one way, they keep infrastructure running. They enumerate, pivot, and persist. From the outside, the commands often look identical. That transparency cuts both ways. Defenders can read the same code, understand the same execution paths, and anticipate how agents behave. In practice, many don’t. Linux and open source don’t create the risk, but they do make it easier for AI agents to move quickly once someone points them in the wrong direction. Ethical vs Malicious Use in Practice In practice, AI agents don’t announce whether they’re being helpful or harmful. The same mechanics show up on both sides, which is why this line keeps getting blurred in real environments rather than in theory. Red teams use AI agents to increase coverage. They let an agent enumerate systems, test configurations, and follow up on weak signals without burning human time. Blue teams are starting to do the same thing for drift detection, exposed secrets, and forgotten services, especially in large Linux estates where manual review never really scales. Criminal use lookssimilar on the surface, which is the problem. When everything runs through standard tooling, intent doesn’t show up cleanly in logs. Common patterns across all three uses include: Automated discovery of hosts, services, and trust relationships Repeated low-impact actions that test assumptions over time Use of standard Linux administration tools rather than custom malware From an operational view, logs and telemetry rarely separate these cases on their own. Context matters, and context usually lives outside the system doing the logging. AI Hacking Trends Emerging Right Now The most noticeable trend is where AI agents spend their time. Instead of hammering production systems first, many start by pulling at public and semi-public artifacts. Git repositories, CI output, container registries, and documentation pages tend to leak just enough detail to make the next step easier. Post-access automation is growing as well. Once an AI agent gets a foothold, it doesn’t rush. It enumerates. It maps permissions. It tests escalation paths slowly and repeatedly, blending into normal Linux activity in a way that’s hard to flag without baseline behavior. Another shift is away from single, critical exploits. AI hacking favors chaining small weaknesses together. A permissive repo here, a stale credential there, a misconfigured service that was never meant to be public. None of these matters much alone. Together, they’re often enough. What the Next Phase of AI Hacking Likely Looks Like The next change isn’t about smarter exploits. It’s about memory. AI agents are starting to persist context across runs, learning how an environment behaves instead of treating every scan like a fresh start. That’s when activity gets quieter. Cost plays into this as well. As agent frameworks get cheaper to run, volume goes up first. More attempts. More noise. Over time, that noise drops as operators tune objectives and filters, leaving behind fewer actions that look increasinglyintentional. The hardest part to spot will be familiarity. Future AI hacking activity is likely to resemble normal Linux administration, using the same tools, the same access paths, and the same schedules. The difference won’t be what runs, but why it runs and how often it comes back. The Broader Takeaway: What Linux Security Admins Should Keep in Mind About AI Hacking AI agents don’t require a new security model as much as they expose weak ones. Most of what they exploit already exists. Forgotten services, permissive defaults, scripts no one owns anymore. Automation just reaches those gaps faster and more consistently. Chasing AI-specific indicators tends to miss the point. What matters is behavior over time. Repetition, timing, and actions that don’t quite line up with human workflows. Linux environments generate enough noise that these patterns are easy to ignore until you start looking for them deliberately. The practical takeaway is simple and uncomfortable. Any task you can automate, someone else already has. That doesn’t mean locking everything down to the point of paralysis. It means tightening fundamentals, understanding your own automation, and assuming that persistence, not sophistication, is what most AI hacking relies on today. . Explore how AI agents impact hacking in Linux environments and what it means for system security.. AI agents, Linux security, automation, threat model, open source. . Brittany Day
Dec 29, 2025
•
218
system managementkernel securityopen-sourceLinux Business Security Open Source Framework User Rights and Kernel Traits
If you manage systems, you’ve probably thought about the Windows vs. Linux security debate more than once. Security isn’t just some checkbox for compliance; it’s the thing keeping attackers out of your networks and your reputation intact. . And while Windows gets the job done for a lot of companies, there’s a reason Linux is seen as the OS you turn to when security really matters. Think about it: Linux isn’t just open-source; it’s massively open to scrutiny. Developers all over the globe are poking at the code every day, not because they’re required to, but because they’re invested and genuinely care. Combine that with Linux’s stricter privilege system (where regular users absolutely do not get unlimited power by default) and a highly customizable design, and it’s pretty clear why businesses, governments, and even tech giants like Google and IBM put their chips on Linux when it comes to securing high-value environments. Now, if you’re thinking, “Yeah, but Windows isn't exactly insecure,” that’s fair. Microsoft isn’t clueless; they know what they're doing when it comes to hardening their OS. But here’s the kicker—Windows tends to rely on “security through obscurity,” which means the source code is locked up, hidden away from public eyes. That might sound good at first, but if you’ve been doing this for a while, you’ll know it also means fewer people catching bugs before bad actors exploit them. With Linux, it’s the opposite; there’s nowhere for vulnerabilities to hide when you’ve got thousands of developers constantly digging through the code with loud opinions. That said, Linux isn’t perfect, and you shouldn’t expect it to magically shield you from all threats. But if you want a foundation that’s built with security front and center, it’s definitely worth considering. Honestly, the numbers speak for themselves—when 97% of the world’s top domains are running Linux, there’s probably a good reason for it. The Open-Source Edge: Why DoesIt Matter? Let’s talk about why Linux’s open-source nature makes all the difference. With Linux, the source code is out in the wild, which means an army—literally thousands—of developers are poring over it daily. These people aren’t just doing it for fun (though, yeah, some of them probably think reading kernel code is fun); they’re invested. It’s a community effort to spot vulnerabilities before attackers even know they exist, so fixes get rolled out freakishly fast. Contrast that with Windows, where the code is hidden behind closed doors, stuck in a vault. That “security through obscurity” model? Eh, it’s not great. This means that only Microsoft’s in-house team is hunting for bugs, and no matter how skilled they are, they’re never going to match the sheer volume of eyeballs Linux has. By the way, big names like Google and IBM—who have arguably more resources than most—are actively funding kernel developers to beef up Linux security. That’s the level of trust people have in the platform. Linux greatly restricts root access through a strict user privilege model, where a superuser has all privileges and ordinary users only have permission to access whatever they need to accomplish their tasks. Because Linux users have low automatic access rights and require additional permissions to open attachments, access files, or adjust kernel options, it is more difficult to spread malware and rootkits on a Linux system than on a system running another OS. Although it is possible to implement least-privilege administration models on Windows systems, organizations rarely take this precaution, and, in reality, “everyone is an admin” on most Windows systems. As a result, attacks in network security can more easily spread malware and viruses on Windows systems than on Linux servers. User Privileges: You’re Not “Admin by Default” on Linux Here’s another thing that hardcore Linux folks won’t shut up about: user privileges. On Linux, even if you’re logged in, youdon’t automatically have godlike powers to mess with the system or execute sketchy scripts. Normal users are sandboxed—they only get access to what they absolutely need, no more. Installing something that might jack up your kernel? Yeah, you’ll have to elevate your privileges explicitly, and even then, Linux has safeguards baked in. On Windows? Let’s be honest. It’s an open secret that most users—even in business environments—are often “admins” by default. Everyone’s an admin, and everything gets full permissions. It’s like begging malware to stroll in and invite its friends. On Linux, spreading malware isn’t just harder; it often requires jumping through a series of flaming hoops, and most attackers don’t want to bother. The Diversity Defense Linux isn’t just one monolithic system—it’s a buffet. There are so many distributions (distros) with different architectures, security models, and components that targeting them is a pain for attackers. One exploit isn’t going to work everywhere when everyone’s running customized setups. It’s kind of like trying to break into a vault when every single one has a unique lock; you’ll probably move on to easier targets, like vanilla Windows installs that look identical from a hacker’s perspective. And if you’re deep into privacy and security concerns —maybe you dabble in pentesting or work in sensitive industries—there are even specialized distros like Kali Linux and Qubes OS, which are laser-focused on locking things down for folks who don’t mess around. Built-In Kernel Security That’s Actually Useful Let’s geek out about the kernel for a minute because this is where Linux does some cool stuff. Linux comes loaded with features like UEFI Secure Boot, Kernel Lockdown, and mandatory access controls (MAC) through tools like SELinux or AppArmor. These aren’t random options you’ll never use—they’re practical tools for hardening your system. Take Linux Kernel Lockdown, for instance. This niftyfeature can stop even root users from modifying kernel code. Why? Because let’s say your root account gets hijacked—Lockdown mode acts like a last-resort shield. You can enable it in two ways: integrity mode (to block any kernel modifications) or confidentiality mode (to block sensitive data access). Quick note: integrity mode is usually the smarter choice for most admins unless you’re running something super-sensitive where even root shouldn’t touch certain data. Then you’ve got SELinux and AppArmor, which help you dictate airtight security policies for your processes. They’re not some over-complicated headache—they’re flexible tools that let you control what applications can or can’t do. Compare that with Windows, where MAC options like Mandatory Integrity Control (MIC) exist but aren’t nearly as versatile or common. Hosting Without the Sticker Shock Let’s be real: Linux hosting is where small businesses and developers clinch the deal. It’s free—like, actually free—which means no annoying subscription fees or per-user license charges. For Linux server admins, a lot of what you need is baked in, with support for core languages like Python, PHP, Ruby, and so on. Plus, Linux hosting tools like cPanel make managing websites way easier. Meanwhile, Windows hosting? Costs can pile up fast, and you’re going to pay for those licenses whether you like it or not. If you’re someone running big sites (think about healthcare data portals or e-commerce platforms), Linux hosting wins both on price and security features. So, What About Windows? Here’s the deal: attackers love Windows. This is partially because it’s everywhere. However, Microsoft’s approach doesn’t help its case either. By keeping Windows code all locked up, third-party devs can’t find bugs ahead of time. The open-source community simply does this better because, honestly, nobody has more time or energy to dissect vulnerabilities. It’s worth mentioning that Microsoft is starting to embrace Linuxmore. Things like Windows Subsystem for Linux (WSL2) and Azure Sphere show they’ve realized the open-source model works, and you’ll even find Microsoft mingling with Linux devs in protective mailing lists. Still, out of the box, Windows isn’t going to give you the same peace of mind that Linux does when it comes to keeping your business safe. Wrapping It All Up: Which OS is Best for You? Here’s where all this lands: if you pick Linux for your business, you’re starting from a fundamentally secure place. There’s less malware targeting it, root users don’t get free reign, and the open-source nature of the system means bugs don’t linger. But—and this is a big but—it’s only one piece of the puzzle. A secure OS is part of a solid defense plan, but it’s not the whole strategy. You still need to think about layered security: assessing your network, patching vulnerabilities , and training your users not to click things just because they’re shiny. Linux gives you a strong foundation, though—and if you’re running servers or handling sensitive data, it’s hard to argue against the level of control it offers over Windows. . Explore the Linux security advantages over Windows, highlighting user rights, kernel traits, and why businesses prefer Linux.. Linux security, open source framework, user rights, kernel traits, business systems. . Brittany Day
Jun 02, 2025
•
102
file integrityosirismass deploymentMass Deployment Of Osiris For Secure File Integrity Management
Osiris is a centralized file-integrity program that uses a client/server architecture to check for changes on a system. A central server maintains the file-integrity database and configuration for a client and at a specified time, sends the configuration file over to the client, runs a scan and sends the results back to the server to compare any changes. Those changes are then sent via email, if configured, to a system admin or group of people. The communication is all done over an encrypted communication channel.. Osiris can be deployed locally or it can be deployed on another continent. One of the major features that makes that possible and secure is the secure communication channel that is used to communicate with the client. Osiris uses SSL for communication between the client and server. Another feature of Osiris is that it is portable across a few platforms including Linux, BSD's, Windows, AIX, Solaris, MacOS, etc.. Osiris has many other features like: logging to syslog emailing alerts filtering out recurring alerts detecting new accounts being created or deleted monitoring kernel modules configuring what attributes of a file to scan manually starting scans scheduling a scan and many other features. It should be noted that the central server or the server maintaining the management console should be kept secure and limited access allowed to the server except for those administering the osiris management console and the clients that will need to communicate with it. By default, the management console will only allow incoming login connections from the localhost (127.0.0.1) and any other hosts will need to be added. Those allowed access to the management console can log onto the server directly or log in remotely with the osiris commandline client, provided their IP is allowed to connect. If the central server is kept secure and a client is compromised and the attacker deletes or kills the osiris client, no problem. The central server maintains theconfiguration file and the database. All that needs to be done is for the client reinstalled on the compromised system, preferrably with a static binary as this article describes, then the admin logins into the management console, pushes a scan config file over, initiates a scan and it will send the results back and compare it against the database on the central server, so you can still see what the attacker did on the computer. This article discusses how to mass deploy Osiris in a Linux environment. This is useful for environments with a large number of computer systems they want to deploy Osiris too. This applies if Osiris is going to be installed and managed locally or 2,000 miles from where the managment console is located. The mass deployment is done using the program "remote_update.pl". It uses SSH to execute commands on multiple machines and logs the output to a file for each system it logs into. It has the ability to only run commands on servers that failed during a previous run. Also, multiple machines can be logged into at once. Since remote_update.pl requires a password that is located in a text file, the program "ccrypt" will be used to encrypt the text file and decrypted on the fly when remote_update.pl is executed. There are other programs that can be used such as GnuPG but ccrypt was chosen because it too is portable across many Operating systms Linux, Solaris, AIX, BSD's, Windows, etc. and can be quickly deployed. Osiris - remote_update.pl - ccrypt - (or some other commandline file encryption program like GnuPG. This tutorial will discuss ccrypt.) If you know how to install Osiris as a static binary on other OS's, please email me with the instructions and I'll add it to this article. Osiris Untar the distributions to " /tmp/ ". /bin/tar -xzvf osiris-x.x.x.tar.gz cd osiris-x.x.x-release First edit the file: "src/install/install.sh " and change the line: INTERACTIVE=1 to INTERACTIVE=0 This will prevent the " remote_update.pl " program from prompting you for input when Osiris is installed on the remote systems. Change any other options you need in that file. If you will be running Osiris on multiple Linux versions, you can compile it as a static binary on one Linux system and then push that binary out to the other Linux systems. If you want to do this, then add this before running ./configure : export CFLAGS="-static $CFLAGS " Now to compile Osiris: ./configure or as a static binary: export CFLAGS="-static $CFLAGS" ./configure /bin/make /bin/make agent /bin/make console 1 (optional) 1 (Note: Run this command to create static binaries of the management console.) In the source directory there will be a tarball created of the agent that was just compiled. It is located under the Osiris source directory in: " src/install " It will have the name format of: osiris-version-release-kernel-version-architecture.tar.gz /bin/ls src/install/ You should see something like: osiris-agent-x.x.x-release-Linux.2.4.26.tar.gz (if you ran: /bin/make console you will also see osiris-console-x.x.x-release-Linux.2.4.26.tar.gz) remote_update.pl Untar the " remote_update.pl " tarball: /bin/tar xzvf remote_update-x.x.tar.gz /bin/cp remote_update-x.x/remote_update.pl /usr/sbin create a directory called " osiris/ " under " /tmp/ ": /bin/mkdir /tmp/osiris cd /tmp/osiris Create the directories: " files/ " and " scripts/ " and a text file named " hosts " and " password " in the root of " /tmp/osiris/ ": /bin/mkdir /tmp/osiris/{files,scripts} /usr/bin/touch /tmp/osiris/{hosts,password} Copy the files that you want to transfer to the directory " files/ " /bin/cp/tmp/osiris-x.x.x/src/install/osiris-agent-x.x.x-release-Linux-2.4.26-1-686.tar.gz /tmp/osiris/files (Optionally you can copy over the management console to some hosts but it is recommended to copy it to only a few computers. In particular, just those that will be managing the Osiris file-integrity program.) Then, create a script that will untar the Osiris distribution and run the install program on the remote systems and put that script in " scripts/ ". Here is a sample script called " Osiris-deploy.sh ": ##################### /tmp/osiris/scripts/Osiris-deploy.sh ########################## #!/bin/sh /bin/tar -xzvf ./files/osiris-agent-x.x.x-release-Linux-2.4.26-1-686.tar.gz # I like to be sure the temporary remote directory is owned by the user that is logging # in so all temporary files and directories are removed /bin/chown -R user:user /home/user/.remote_update/ cd ./osiris-agent-x.x.x-release ./install.sh ##################### /tmp/osiris/scripts/Osiris-deploy.sh ########################## Make the file executable and copy it to the " scripts/ " directory: /bin/chmod +x Osiris-deploy.sh /bin/cp Osiris-deploy.sh /tmp/osiris/scripts/ Next, specify in the " hosts " file a list of hosts, one per line, to deploy Osiris on. For example, ##################### /tmp/osiris/hosts ########################## host1 127.0.0.1 myhost.domain.net ##################### /tmp/osiris/hosts ########################## ccrypt The program ccrypt will be installed based on the distribution you are using, OS, and the format you choose to use. It comes as a static binary, RPM, or source. For debian I ran: /usr/sbin/apt-get install ccrypt Now comes the really imporant part, the " password " file. The remote_update program comes with a sample password file so you can peruse that for more information. Below is an example of how to setup the password file: and a list of passwordsfor root. The remote_update program will try each password until it succeeds or fails. Here is a sample password file called " password ": ##################### /tmp/osiris/password ########################## # 1. Be sure no one is looking over you shoulder during this part! # 2. Be sure you type the passwords correctly. # 3. The username must be at the beginning of the line and the password # has to be one tab over and underneath the username for that particular user. # 4. There are some exceptions to this so read the "example_password.txt" file # in the source directory of remote_update # 5. remote_update will keep trying until there are no more user/password combinations or until it suceeds duane password1 password2 password3 password4 ryan password1 password2 root password1 password2 ##################### /tmp/osiris/password ########################## Immediately encrypt the file with " ccrypt " (or GnuPG): /usr/bin/ccrypt -e password After you type a password to encrypt the file it will give the file a " .cpt " extension. All Together now Be sure that that the " hosts " file is located in the root of " /tmp/osiris/ ". Now you are ready to deploy Osiris with the command: /usr/bin/ccat password.cpt | /usr/sbin/remote_update.pl -v -p - -d /tmp/osiris Here is what is going on. First you decrypt the contents of the " password.cpt " file ( /usr/bin/ccat password.cpt ) and pipe it into the remote_update program and tell it to get the password from standard input: ( | /usr/sbin/remote_update.pl -p - ) then specify the directory where the scripts and files to copy over is located ( -d /tmp/osiris ). I have a sick and personal thing about seeing stuff moving on my terminals so I specified the verbose switch ( -v ). For each host specified in the hosts file under " /tmp/osiris" there will be a " .log " file created with the verbose output from the remote system under the " /tmp/osiris/ " directory. This is the same output as the ( -v ) switch on the commandline. If there are any errors with installing osiris on some hosts you can specify the ( -f ) switch and remote_update will only retry the hosts that failed. /usr/bin/ccat password.cpt | /usr/sbin/remote_update.pl -v -f -p - -d /tmp/osiris Under the directory " /tmp/osiris " there will be a " .log " file for each hosts specified in the " hosts " file. Now you have three great programs to work with, Osiris, remote_update.pl, and ccrypt. Remote_update.pl can be used for a wide variety of purposes when you are administering a lot of computer systems at once. Duane Dunston received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS. Hey,Ann Curry!. Osiris can be deployed locally or it can be deployed on another continent. One of the major features. osiris, centralized, file-integrity, program, client/server, architecture, check. . Duane Dunston
Nov 22, 2004
•
102
intrusion detectionsystem managementsecure operating systemGuardian Digital EnGarde Secure Linux: Next-Gen Proactive Protection
Award-winning secure operating platform combines ease of management with unsurpassed security as a primary focus.. ALLENDALE, NJ-February 9, 2004 -- Guardian Digital, Inc., the world's premier open source security company, announced an update to the next generation, award-winning platform that delivers features designed to ease the process of building a complete Internet presence and the level of security necessary to prevent system compromise. EnGarde Secure Linux leverages the best open source applications available to provide secure Internet connectivity, user privacy, Web and email functions, and intrusion detection. "The proactive security improvements inherent into its design are one of the primary factors in the success of EnGarde," writes Pete O'Hara, vice president of engineering at Guardian Digital. "Coupled with the most sophisticated open source Web-based management system, EnGarde consistently protects users from even debilitating kernel security vulnerabilities where other Linux vendors fail." EnGarde features secure web-based management of all functions, including Internet edge services (Web, DNS, email), integrated intrusion detection, cryptography, improved authentication and access control, as well as protection from many forms of intrusion such as buffer overruns and denial of service attacks. Enhanced availability and access control mechanisms delivers a potent combination suitable for the largest enterprise. "Security management is an essential component of any successful online operation. Mitigating security risks through the use of a dynamic, rapidly-evolving development process bolstered by collaboration of the open source community provides the most efficient form of protection," writes PaulBrisson, orthopedic spinal surgeon, New York Spinal Care. "EnGarde Secure Linux and its secure-by-design approach combined with the security benefits engineered by Guardian Digital offer the best in proactive protection," continues Brisson. EnGarde Secure Linux features the Guardian Digital WebTool, a web-based interface used to securely manage network and server operations. Emphasizing increased security, performance, and an available 2.6 Linux kernel, EnGarde Secure Linux features include: Simple and secure web-based management. Core Internet services including Web, DNS, and email system management. Unlimited virtual domains. Comprehensive backup/recovery system. Sophisticated access control mechanisms. Integrated network and host intrusion detection Guardian Digital Secure Network to provide easy access to security and system updates. Mandatory Access Control (MAC) using the Linux Intrusion Detection System to provide sophisticated access control and prevent Trojan horse attacks. Latest cryptography tools including built-in web-based key management for building secure Web sites. Hardened kernel and user tools providing highly resilient protection from intruders. Gateway firewalling using stateful packet inspection. Security Control Center to monitor system activity. Upgraded core components including Linux kernel 2.4.22 and development tool chain. Unparalleled protection from the latest Internet threats including denial of service, Trojan horse, spoofing, Microsoft worms. Other new features in EnGarde Secure Linux include new executive summary reportingfunctionality that allows IT Managers to receive and deliver comprehensive graphic reports on server activity and security alerts, scalability improvements, and enhanced journaling filesystem support. See Guardian Digital Makes Email Safe For Business - Microsoft 365, Goo.... for a complete overview of features and information on Guardian Digital enterprise products. Pricing and Availability EnGarde Secure Linux is now available for download from Guardian Digital and includes a free 30-day subscription to the Guardian Digital Secure Network to obtain system and security updates. An annual subscription to the GDSN is available for $229 per year and includes thirty days of email installation and configuration support. About Guardian Digital, Inc. Guardian Digital, the premier open source security company, offers the first secure, open source Internet infrastructure system. Based on Guardian Digital's operating system platform, EnGarde, the company provides enterprises with the software and services necessary for secure computing on the Internet. By leveraging the merits of the collaborative open source design model, coupled with the company's security and Internet expertise, Guardian Digital solutions maintain the highest degree of security and reliability. Founded in 1999, Guardian Digital is headquartered in Allendale, New Jersey. For additional information, please visit Guardian Digital Makes Email Safe For Business - Microsoft 365, Goo.... or call 1-866-GD-LINUX . Contact: Alison Parker Guardian Digital, Inc. Corporate Communications 201-934-9230
Feb 10, 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!