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 -2 articles for you...
102
security advisorycommand executionconfigurationWhen Monitoring Turns Risky: SNMP Exposure in Linux Infrastructure
A recent command-execution flaw in the CACTI monitoring framework underscores a broader risk that keeps repeating. SNMP is routinely treated as passive plumbing, yet it exposes real control paths that attackers continue to abuse. . Misconfigured or outdated instances of the Simple Network Management Protocol remain low-effort entry points, especially in Linux environments. SNMP often arrives indirectly through monitoring stacks or embedded agents, then persists untouched, which is why its impact tends to surface late and hit hard. What Is the SNMP Protocol? The snmp protocol , short for Simple Network Management Protocol, is a way for systems to observe and manage devices without logging into them directly. It was built for visibility. You poll a device for counters, status, or configuration state, and the device answers through a small background service called an agent. In practice, SNMP works by exposing structured data known as MIBs. Management systems query that data over the network, usually through port 161, and receive responses that describe things like interface usage, uptime, or error rates. Devices can also push notifications, called an SNMP trap, when certain conditions occur, such as a link going down or a threshold being crossed. The design favors reach and simplicity over strict security controls. Early versions rely on a shared secret, the SNMP community string, and assume the network itself is trusted. Later revisions, like SNMPv3 , add authentication and encryption, but the protocol still reflects its original goal. Make monitoring easy, even if that means security depends heavily on how carefully it’s deployed. Understanding Core Flaw Mechanics & SNMP Configuration Gaps Behind Recent Exploits The command-execution issue uncovered in CACTI did not stem from a novel technique. It emerged where protocol behavior, aging code, and permissive deployment habits overlap, which is where snmp problems usually live. At the technical level, improper input validationin SNMP request handling allowed malformed packets to reach unsafe code paths. When an agent fails to parse a request defensively, buffer handling errors and weak bounds checks can turn what should be a read-only monitoring interface into an execution surface. Configuration choices widen that window. SNMPv1 and v2c rely on cleartext community strings, so anyone who can observe traffic or guess the value effectively inherits the same access as the monitoring system. SNMPv3 improves this with authentication and encryption, but it is frequently disabled or only partially deployed due to compatibility constraints and legacy tooling that still expects older behavior. These technical and operational gaps reinforce each other. Default community strings like “public” persist, SNMP services are exposed without ACLs, and agents run for years without updates that address known parsing flaws. SNMP continues to be treated as background infrastructure rather than an exposed service, which is why the same failure patterns keep resurfacing across different platforms and incidents. Impact and Context of SNMP Flaws for Linux Environments This is where snmp moves from a design discussion to an operational risk. The danger is not tied to clever exploitation, but to how quietly the protocol embeds itself into Linux environments and then persists, trusted and largely untouched, as systems evolve around it. Network devices, Linux servers , and appliances frequently ship with SNMP enabled by default. Monitoring frameworks such as CACTI bring in legacy SNMP modules that expand the attack surface without much visibility, and once enabled, those services tend to survive rebuilds, migrations, and ownership changes. From an attacker’s perspective, exploitation is usually straightforward. Many deployments still allow unauthenticated queries, and internet-facing SNMP ports are easy to identify with basic scanning. When the protocol exposes topology, counters, and configuration data by design, there is little needfor novel techniques. This behavior has a long history. Large-scale scans abusing default SNMP community strings have been documented for years, and publicly available tools can enumerate MIBs, inject SNMP traps, or deliberately trigger faults in poorly hardened agents. The tooling is mature, and the failure modes are predictable. The real impact often shows up after initial access. An SNMP foothold can support lateral movement by revealing interface layouts, routing paths, and configuration fragments that reduce uncertainty. That visibility shortens attack paths, which is why SNMP-related weaknesses so often appear early in broader Linux compromise chains. SNMP Mitigation and Response Strategies for Admins Mitigation around SNMP rarely hinges on a single fix. It’s usually the accumulation of small, unglamorous decisions that either leave the door open or quietly close it over time. For Linux administrators, this work lives at the intersection of patching discipline , configuration hygiene, and basic network restraint. The steps are familiar, but SNMP has a habit of slipping past them unless you look for it directly. Patching and Agent Maintenance Apply vendor fixes for SNMP parsing flaws promptly. Verify that updates cover all deployed agents and modules, not just the primary monitoring server. Stale binaries are common in SNMP stacks. Configuration Hardening Disable SNMP anywhere it isn’t pulling its weight, because idle agents become forgotten attack surface fast. Where SNMP is still required, move fully to SNMPv3 and actually enable encryption and authentication, not auth-only configs that leak data in transit. Use authPriv mode with strong credentials, per-user accounts, and modern algorithms, and confirm older v1 and v2c listeners are shut off instead of assumed gone. Default and shared community strings should be removed entirely, not renamed, and any legacy strings that remain need rotation on a schedule and the same handling as service credentials. For CACTIspecifically, patch to the fixed release and review how SNMP responses are consumed, since the underlying issue came down to insufficient input validation before data was passed into command execution paths. SNMP output should be treated as untrusted input, even when it comes from internal devices, with strict validation, type checks, and allowlists enforced before values ever touch shell commands, templates, or plugins. Network-Level Controls Restrict SNMP access with ACLs and firewall rules . Keep management services on isolated networks rather than general-purpose segments. If an SNMP listener does not need broad reachability, remove it. Detection and Monitoring Alert on unusual SNMP traffic patterns. Log authentication failures and unexpected GET or SET activity. SNMP failures are often silent unless you choose to watch them. Vendor and Platform Guidance Track advisories for device-specific SNMP behavior and quirks. Regularly review firmware and agent versions across managed assets. Older hardware often carries the highest risk. The Broader Takeaway on SNMP Risk in Linux Environments SNMP persists as a blind spot in asset inventories because it feels passive. Misconfiguration and legacy defaults drive recurring exploitation more than zero-day flaws. Regular configuration audits reduce exposure. The protocol’s design limits make defense-in-depth necessary, not optional. Mitigating SNMP risk must be a top priority among Linux admins and security teams because it continues to resurface in incident chains. Engaging with it deliberately, rather than inheriting it quietly, is how that pattern finally breaks. . Misconfigured Simple Network Management Protocol instances represent low-effort entry points for attackers in Linux environments.. Linux security issues, SNMP monitoring risks, CACTI command execution. . Brittany Day
Dec 20, 2025
•
102
security advisoryconfigurationubuntuImproving Nagios Security On Ubuntu: Configuration Tips
Nagios is a monitoring software designed to let you know about problems on your hosts and networks quickly. You can configure it to be used on any network. Setting up a Nagios server on any Linux distribution is a very quick process however to make it a secure setup it takes some work. This article will not show you how to install Nagios since there are tons of them out there but it will show you in detail ways to improve your Nagios security. . Bill Keys Introduction Nagios is a monitoring software designed to let you know about problems on your hosts and networks quickly. You can configure it to be used on any network. Setting up a Nagios server on any Linux distribution is a very quick process however to make it a secure setup it takes some work. This article will not show you how to install Nagios since there are tons of them out there but it will show you in detail ways to improve your Nagios security. You may be wondering why should I need to think about securing my Nagios server? Well, think about the amount of information the attacker can get if they compromise it. All the examples below assumes you are using Ubuntu. However these examples will help any user running a Nagios server to make it more secure since the concepts will still apply. Web interface If you installed Nagios with one of the quick start guides out there, chances are that you setup the web interface. Since Nagios uses Apache to display it there are many security options. Below is an example of apache configuration for a Nagios web interface: Options ExecCGI AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user The 'Allow from' option is used to provide access to only a certain IP address and/or network. The above example allows any IP address to access the web interface. The other security options are used for authentication.'AuthType' defines the type of authentication being used. There are two types you can choose from Basic or Digest. Basic authentication will transmit your passwords and username as clear text. However using Digest the passwords are transmitted as MD5 digests which is more secure then in clear text. After making some security improvement we get the below. Options ExecCGI AllowOverride None Order allow,deny Allow from 192.168.4. AuthName "Nagios Access" AuthType Digest AuthDigestFile /usr/local/nagios/etc/htpasswd.users Require valid-user Now only computers on the 192.168.4.0 network can have access to the web interface. Also we are now using Digest authentication instead of the insecure method of Basic authentication. Now we need to add users and passwords to allow accesses to the web interface. To add a new user using digest authentication use the below command: # htdigest -c /usr/local/nagios/etc/htpasswd.users realm username Digest is more secure then Basic authentication but the best way keep your username and passwords safe is to use SSL. Make sure that you restart apache if you make any configuration changes. # /etc/init.d/apache2 restart Best Practices This sections lists some of the best security practices when setting up an Nagios server. Don't Run Nagios As Root There should be an normal user called nagios. If Nagios is running as root then if Nagios gets compromised then the attacker can do anything they want to your system. Lock Down The Check Result Directory Make sure that only nagios has read/write access to the check result directory otherwise an attacker can send fake host and service checks. This directory is normal at /usr/local/nagios/var/spool/checkresults Use Full Paths In Command Definitions When defining commands, make sure to specify the full path and not the relative one to any scripts or binaries you . Bill Keys Introduction Nagios is a monitoring software designed to let you know about problems on yo. nagios,monitoring, software, designed, about, problems, hosts, networks. . Anthony Pell
Mar 17, 2010
•
102
security advisoryaccess controlsecurity risksSecuring Apache Web Server: Effective Logging And Access Control
This is the second installation of a 3 part article on LAMP (Linux Apache MySQL PHP). Apache is the most widely used HTTP-server in the world today. . It is also the most used web server for a Linux system. A web server like Apache, in its simplest fun ction, is software that displays and serves HTML pages hosted on a server to a client browser that understands the HTML code. You must always be careful in knowing the web services that run. Run: [root@aquarius /# netstat -a | grep LISTEN to scan your ports. A secure site should have only ports 22 (SSH), 80 (HTTP) and 443 (SSL) exposed. Log files are another useful utility for monitoring attacks on your server. One must set up a centarlised secure log server so that hackers will not be able to remov e traces of their intrusion so easily. Various logfile analyzers like analog, webaliser help in keeping track of the web server access by people. By installing and configuring a good logfile analyser one can know details about the total traffic across the network and the various files and directories accessed,mod ified,deleted or any such activity. It will also tell you the pages that were visited and by whom. In addition to that are all the resources that are busy with respect to apache. Maintaining Logfiels is such an important task that one must follow in order to keep track of his system's activities.Apache web server logfiles are httpd.log,error _log and access_log These files log all the attempts by a user in order to perform a task,it can be an attempt for compromising the system The daemon syslog must be enabled which is responsible for logging activity. Care must be taken that logging is on for mail and auth privileges in /etc/syslog.conf In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command th at root executes, you must take care that it is protected from modification bynon-root users. Not only must the files themselves be writeable only by root, but so mu st the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these: mkdir /usr/local/apache cd /usr/local/apache mkdir bin conf logs chown 0 . bin conf logs chgrp 0 . bin conf logs chmod 755 . bin conf logs It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected: cp httpd /usr/local/apache/bin chown 0 /usr/local/apache/bin/httpd chgrp 0 /usr/local/apache/bin/httpd chmod 511 /usr/local/apache/bin/httpd You can create an htdocs subdirectory which is modifiable by other users -- since root never executes any files out of there, and shouldn't be creating files in there. If you allow non-root users to modify any files that root either executes or writes on then you open your system to rootcompromises. For example, someone could repla ce the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could repl ace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a no n-root user), then someone may be able to overwrite the log itself with bogus data. Server Side Includes Server Side Includes (SSI) present a server administrator with several potential security risks. The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the f iles. While this load increase is minor, in a shared server environment it can become significant.SSI files also pose the same risksthat are associated with CGI script s in general. Using the "exec cmd" element,SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as config ured in httpd.conf. That should definitely give server administrators pause. There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide. To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec as described in the CGI in General section. Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files shoul d have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk. Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use to execute CGI scripts if these scripts are in directories desginated by a ScriptAlias directive. Non Script Aliased CGI Allowing users to execute CGI scripts in any directory should only be considered if: You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack. You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant. You have no users, and nobody ever visits your server. Script Aliased CGI Limiting CGI to special directories gives the admin control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI script/program for potential security holes. Most sites choose this option over the non script aliased CGI approach. CGI in General Always remember that youmust trust the writers of the CGI script/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental. All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B's CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1. 2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap. Protecting System Settings To run a really tight ship, you'll want to stop users from setting up .htaccess files which can override security features you've configured. Here's one way to do it. In the server configuration file, put AllowOverride None This prevents the use of .htaccess files in all directories apart from those specifically enabled. Protect Server Files by Default One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its wa y to a file through normal URL mapping rules, it can serve it to clients. For instance, consider the following example: # cd /; ln -s / public_html If a client accessed , this would allow them to walk through the entire filesystem. To work around this, add the following block to your serve r's configuration: Order Deny,Allow Deny from all This will forbid default access to filesystem locations. Add appropriate blocks to allow access only in those areas you wish. For example, Order Deny,Allow Allow from all Order Deny,Allow Allow from all Pay particular attention to the interactions of and directives; for instance, even if denies access, a directivemight overturn it. htpasswd authentication With apache,you can secure your files and directories in a more simplest way by using any of the authentication methods like basic,digest etc. By using htpasswd one can allow only specific users to access a particular file or a directory like this. Create a file called users and list all the names of the users u want to give access and place it in a location like /etc/httpd/ Use the following command: root# htpasswd -cm /etc/httpd/users username -c is only used the first time For other users you need not use the -c option type the password on prompt You can notice the file users containing the passwords encrypted Now add this in httpd.conf file at the end o fthe file AuthType "Basic" AuthUserFile /etc/httpd/users AuthName "Authorisation Required" require valid-user Whenever a user tries to access /var/www/html/test directory he will be prompted for the username and password and if he is allowed to access only then he will be pe rmitted to enter into the directory and access fiels otherwise he will not be allowed. This is just one way of securing your files with apache. Roopa Rannorey Roopa has been in the IT field in Karnataka, India for about three plus years. Her interests include Linux Security and Networking and she has been at them for a while.. It is also the most used web server for a Linux system. A web server like Apache, in its simplest fu. apache, second, installation, article, (linux, mysql. . Brittany Day
Nov 22, 2002
•
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!