Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security news
We found 2 articles for you...
72
security advisoryhardeningimportantUFW: Important Hardening Patterns for Long-Lived Linux Servers
UFW rules on long-lived hosts don’t fail because the policy is wrong. They fail because changes get applied out of sequence, old rules survive longer than expected, and the first test looks fine until you disconnect. . This guide is about changing policy safely. Every scenario follows the same pattern: add the scoped allow, test the approved access path, confirm the enforcement order, then remove the broad rule. Rollback is always available. If you haven’t audited the ruleset yet, start with Part 1: Guide to Auditing UFW Rules on Long-Lived Linux Hosts . It will make the scenarios below easier to apply safely. Back Up and Roll Back UFW Rules Before You Change Anything Changing UFW rules on a remote host without a rollback path is how people lose access. Deleting or tightening rules should always start with a way to restore the previous state if something goes wrong. Back Up the Entire UFW Configuration (Recommended) This captures everything UFW uses , including user rules, defaults, profiles, and any logic in before.rules . On long-lived hosts, this is the safest option. sudo cp -a /etc/ufw /etc/ufw.bak.$(date +%F-%H%M%S) Note: This copies the /etc/ufw directory into the backup directory, so your backup will look like /etc/ufw.bak.TIMESTAMP/ufw/ . Back Up Only the Active User Rules (Optional) This is faster and sometimes sufficient if you’re making small changes, but it does not include defaults or before.rules . Use it only if you understand that boundary. sudo cp -a /etc/ufw/user.rules /etc/ufw/user.rules.bak.$(date +%F-%H%M%S) sudo cp -a /etc/ufw/user6.rules /etc/ufw/user6.rules.bak.$(date +%F-%H%M%S) Schedule a Rollback Job Before You Tighten or Delete Rules When you’re working remotely, assume you can lock yourself out. This schedules an automatic rollback that restores the backup and reloads UFW if you lose access. You cancel it after confirming everything still works. If at isn’t available on this host, use consoleaccess or a persistent session ( screen / tmux ) with a delayed rollback command instead. Schedule a rollback in five minutes. Replace TIMESTAMP with the backup directory you just created (for example: /etc/ufw.bak.2025-12-31-143200 ). echo "cp -a /etc/ufw.bak.TIMESTAMP/* /etc/ufw/ && ufw reload" | sudo at now + 5 minutes Confirm the rollback job is queued: sudo atq Cancel the job after you confirm SSH still works: sudo atrm Manual Rollback If You Need It If you still have console access or need to revert after a failed change, restore the backup and reload UFW directly. Replace TIMESTAMP with the backup directory you created earlier. sudo cp -a /etc/ufw.bak.TIMESTAMP/* /etc/ufw/ sudo ufw reload With a rollback path in place, the focus shifts to observation. Before touching enforcement or tightening access, you need to understand what the ruleset says about exposure. That means reading what’s there carefully, without trying to fix it yet. Safe Change Rules for UFW on Production Hosts At this point, you already know what the host is exposed to and which rules actually win. Hardening is where people still get burned, not because the policy is wrong, but because they remove access before proving the replacement rule is dominant. Use the same pattern for every change: Back up the UFW state: sudo cp -a /etc/ufw /etc/ufw.bak.$(date +%F-%H%M%S) If you are remote, schedule rollback before you delete anything. Replace TIMESTAMP with the backup directory you created. echo "cp -a /etc/ufw.bak.TIMESTAMP/* /etc/ufw/ && ufw reload" | sudo at now + 5 minutes sudo atq Then harden using the same sequence every time: Add the scoped allow first Test the approved access path Confirm the enforcement order with: sudo ufw show raw Delete the broad rule by number: sudo ufw status numbered Example output will look like this: [ 1] 22/tcp ALLOW IN Anywhere [ 2] 22/tcp ALLOW IN 203.0.113.10 [ 3] 443/tcp ALLOW IN Anywhere [ 4] 22/tcp (v6) ALLOW IN Anywhere (v6) Then delete the broad rule by number: sudo ufw delete Advice: If you are deleting multiple rules, always delete from the highest number to the lowest number to avoid rule-index shifting. Validate again, then cancel rollback: sudo atrm This is how hardened intent becomes real exposure, without relying on memory or hope. Once this pattern is in place, the scenarios below are just variations of the same workflow. Scenario 1: Harden SSH in UFW Without Breaking Access This is the reference scenario. The same sequence applies to everything else. Starting state SSH works. Multiple rules may exist. The trusted access path isn’t clearly defined. End state SSH is restricted to a known subnet or interface. No Anywhere SSH remains. Sequence Add the scoped allow first. sudo ufw allow from 203.0.113.10 to any port 22 proto tcp If SSH should only arrive over a VPN: sudo ufw allow in on wg0 to any port 22 proto tcp Test SSH from the approved source. Test from a new session, not the one you’re already connected with. Remove the broad rule using its number from ufw status numbered : sudo ufw delete Optionally apply rate limiting : sudo ufw limit ssh Validation Confirm enforcement matches intent: sudo ufw show raw Remote safety Before deleting SSH rules remotely, schedule a rollback. Replace TIMESTAMP with the backup directory you created. echo "cp -a /etc/ufw.bak.TIMESTAMP/* /etc/ufw/ && ufw reload" | sudo at now + 5 minutes Cancel after confirming access: sudo atq sudo atrm Scenario 2: Maintainable Service Allowlisting in UFW Use this when multiple services are exposed, and the ruleset has grown noisy. List active listeners: sudo ufw show listening Remove rules for services that are no longer running: sudo ufw delete Replace duplicates with a single explicit allow: sudo ufw allow from 10.0.0.0/8 to any port 9100 Use application profiles when they reduce duplication: sudo ufw allow 'Nginx Full' Bind UFW Rules to the Interface That Should Carry the Traffic On long-lived hosts, many rules apply to Anywhere , even though the traffic was always intended to come from an internal network or a VPN. Those rules tend to survive long after the context that justified them is gone. If a rule applies to Anywhere , assume it is wrong until proven necessary. Binding rules to interfaces is one of the most reliable ways to make a ruleset predictable. Restrict database access to an internal VLAN only: sudo ufw allow in on eth1 from 10.0.5.0/24 to any port 3306 Restrict administrative access to a VPN interface: sudo ufw allow in on wg0 to any port 22 proto tcp Interface binding turns intent into something the firewall can enforce consistently. On long-lived systems, it’s often the difference between a ruleset that looks tight and one that actually behaves that way. Validation Only expected services should be reachable. One rule per access path. Scenario 3: Apply UFW Rate Limiting and Confirm It Triggered Apply rate limiting where abuse is likely. sudo ufw limit ssh Or by port: sudo ufw limit 443/tcp Validation Confirm drops in logs during testing or abuse conditions: sudo journalctl -f | grep -i ufw Expect temporary connection failures from repeated sources. Scenario 4: Tight Defaults With Explicit Exceptions Use this for hosts where exposure should be minimal. Set deny-first defaults: sudo ufw default deny incoming Add only required exceptions. Management access: sudo ufw allow from 203.0.113.10 to any port 22 Public services: sudo ufw allow 443/tcp Internal services: sudo ufw allow in on eth1 from 10.0.5.0/24 to any port 3306 Validation Confirm order and enforcement: sudo ufw show raw After working through service-level hardening, there are two checks that tend to get skipped. One is IPv6 parity . The other is outbound control. Neither changes how UFW works, but both change whether your rules actually reflect intent on long-lived hosts. IPv6 Parity Check After Every Hardening Change Most unintended exposure after hardening isn’t caused by the rule you tightened. It’s caused by the stack you forgot. IPv4 gets narrowed, IPv6 stays permissive, and the ruleset still looks clean unless you check for v6 entries explicitly. Confirm whether UFW is enforcing IPv6: sudo grep -i '^IPV6=' /etc/default/ufw Then check the active ruleset and look for (v6) entries for every externally reachable service: sudo ufw status numbered If SSH is scoped on IPv4 but still shows Anywhere (v6) , the host is still reachable by SSH over IPv6. The fix is not disabling IPv6. It’s applying the same intent across both stacks. Finally, confirm the enforcement order after changes: sudo ufw show raw Parity is part of hardening. If one stack tells a different story from the other, intent and exposure have already drifted apart again. Optional: Outbound Lockdown for High-Control Hosts Everything so far has focused on inbound exposure. Outbound control is a different class of hardening and should only be considered on hosts with well-understood dependencies. In high-control environments, outbound traffic is denied by default, and only required destinations are allowed explicitly. This reduces the impact of compromised services and unexpected processes calling out. To illustrate the boundary: sudo ufw default deny outgoing This change is intentionally disruptive. It will break DNS, NTP, package updates, monitoring, and most external integrations until they are allowed explicitly. Only consider this if you can enumerate outbound requirements and test them carefully. If you go down this path,allow outbound services deliberately. DNS resolvers, time synchronization, package repositories, and monitoring endpoints should be documented and reviewed in the same way inbound exceptions are. Outbound lockdown is optional by design. It belongs in environments where predictability matters more than convenience, and where changes can be validated without guesswork. Hardening isn’t finished until you can explain how the firewall behaves. So, let’s focus on isolating unexpected behavior. The final section turns the whole process into something you can reuse. Troubleshooting: What to Check When UFW Rules Look Correct but Traffic Still Fails When UFW rules look correct, but traffic still fails, the problem is usually not syntax. It’s an overlap, order, or behavior you didn’t account for during hardening. UFW across Linux environments behaves consistently, but overlapping rules, ordering, and rate limiting still produce failures that look random unless you trace which rule matches first. Common symptoms look familiar. A service works from one source but not another. A port looks open in the ruleset, but connections time out. Rate limiting triggers intermittently and looks like a random failure. IPv4 behaves as expected while IPv6 does not. Most of the time, the cause falls into one of a few buckets. Overlapping rules where a broader match wins. The rule order that allows or drops traffic earlier than expected. Rate limiting that temporarily blocks repeated connections. IPv4 and IPv6 rules don’t reflect the same intent. The workflow to isolate the issue stays consistent. Start by confirming the enforcement order, which is the foundation of debugging UFW firewall behavior: sudo ufw show raw Identify which rule would match the failing traffic first. Don’t assume the narrowest rule applies. Look for the earliest permissive or limiting match. Next, validate behavior with logs when needed: sudo journalctl -f | grep -i ufw Logging helps confirm whether trafficis hitting a rule you didn’t expect, or whether rate limiting is triggering under load. Finally, trace the flow back to the dominant rule for that service. The goal is not to add another exception. It’s to understand which existing rule is responsible for what you’re seeing and adjust that rule deliberately. Troubleshooting here is part of the audit mindset. If you can’t explain why traffic is allowed or blocked, the ruleset still isn’t in a stable state. Final Checklist: UFW Audit and Hardening Steps for Long-Lived Linux Hosts This checklist closes the loop. It’s meant to be reused the next time you inherit a host, revisit an old ruleset, or validate changes after an incident. Exposure summarized in one clear paragraph One dominant allow identified for each exposed service Enforcement order confirmed with ufw show raw SSH was narrowed to known sources and validated Each exposed service is allowed by a single, clearly scoped rule Rate limiting confirmed through logs where applied IPv4 and IPv6 parity checked for exposed services Exceptions documented with purpose, owner, and date If you can walk through this list without guessing, the ruleset is doing its job. You know what the host allows, why it will enable it, and how to change it safely when requirements shift. That’s the difference between a firewall that exists and one you can rely on. . Audit and harden UFW rules on long-lived hosts to ensure security while maintaining access. Essential guide for admins.. UFW Hardening, Linux Firewall, Security Best Practices, Firewall Configuration. . MaK Ulac
Dec 31, 2025
•
Firewalls
212
access controlhardeningsecurity strategyFortifying Multi-Cluster Kubernetes Security Strategies and Best Practices
Kubernetes has quickly become a de facto tool within enterprise software development environments, enabling DevOps engineers to scale large numbers of containers. And recent cybersecurity hardening guidelines laid out by the NSA and CISA indicate that adoption of Kubernetes has reached critical mass. But this surge in adoption also can introduce many new vulnerabilities and misconfigurations which, if left unchecked, could put many organizations at risk. . Most infrastructure teams have moved on from running just one or two clusters. It’s now common to operate multiple clusters across various divisions and, perhaps, even across multiple clouds. Within this multi-cluster reality, it becomes difficult to keep an up-to-date inventory of all existing Kubernetes clusters, let alone their unique frailties. This can easily result in over-permissive states that break the rule of least privilege. I recently met with Jimmy Mesta, co-founder & CTO, KSOC Labs, to explore the current issues facing Kubernetes deployments. According to Mesta, increased visibility into all Kubernetes platforms and tighter role-based access control (RBAC) is necessary to keep cloud-native architecture safe and secure. Below, we’ll review these concerns and explore general methods for hardening the growing complexity of today’s Kubernetes deployments. . Discover essential strategies for fortifying Kubernetes multi-cluster setups, tackling vulnerabilities and boosting security.. Kubernetes Hardening, Multi-Cluster Security, Cloud-Native Strategy. . Brittany Day
Apr 18, 2022
•
Cloud Security
212
security advisoryhardeningkubernetesKey Components of NSA/CISA Guidance for Kubernetes Security
NSA/CISA Kubernetes hardening guidance offers a solid foundation for securing Kubernetes environments. Here are the key components and why they're important. . Kubernetes has become the de facto choice for container orchestration. Some studies report that up to 88% of organizations are using Kubernetes for their container orchestration needs and 74% of that occurring in production environments. That said, security remains a critical concern with as many as 94% of organizations reporting at least one security incident in their Kubernetes environments in the last 12 months. As organizations continue to adopt Kubernetes, it is crucial that they follow industry best practices and guidance to ensure they are using Kubernetes securely. . The NSA and CISA have released guidelines to enhance Kubernetes security. Key areas include strong authentication, network segmentation, privilege minimization, and monitoring.. Kubernetes Security, Container Hardening, NSA/CISA Guidance. . Brittany Day
Aug 23, 2021
•
Cloud Security
77
security practiceshardeningconfigurationKey Security Measures For Your Linux Web Server Configuration
With the significant prevalence of Linux web servers globally, security is often touted as a strength of the platform for such a purpose. However, a Linux based web server is only as secure as its configuration and very often many are quite vulnerable to compromise. . While specific configurations vary wildly due to environments or specific use, there are various general steps that can be taken to insure basic security considerations are in place. The link for this article located at Linuxaria is no longer available. . While specific configurations vary wildly due to environments or specific use, there are various gen. significant, prevalence, linux, servers, globally, security, often, touted, strengt. . LinuxSecurity.com Team
Jan 15, 2013
•
Server Security
77
security practiceshardeningLinux securityStrategies For Securing Linux Systems By James Turnbull
Hardening Linux, by James Turnbull, stands out as an important text that clearly lays out how to make your Linux boxes as secure as possible. Mr. Turnbull has done a noteworthy job in delineating many potential vulnerabilities, and how to mitigate them. Each chapter covers a particular area in depth, with carefully worded and easy-to-follow examples. In the cases where you need to install some other piece of software to provide extra security, Turnbull gives you the step-by-step details, removing the chance of misinterpretation. As you finish each chapter, you will want to apply your newfound knowledge to the machines at your disposal. . Naturally, the strongest building will collapse if built on a weak foundation, so Turnbull starts by considering what you need to harden a stand-alone Linux host. He discusses what applications to install and how to secure the boot loader (both LILO and GRUB are covered). The init sequences and scripts are covered next, as well as the login screen. Information on securing users and groups using PAM (Pluggable Authentication Modules) comes next, followed by package management and kernel patching. Finally, Turnbull finishes up with how to keep informed on security issues in the future. All of that is contained in chapter 1, and there are ten more to go! Each chapter ends with a list of resources in the form of mailing lists, web sites, books, etc., so you can fill in any blanks Turnbull may have left in. The link for this article located at Slashdot is no longer available. . Discover effective strategies to safeguard your Linux environments by exploring practical knowledge from James Turnbull's in-depth manual on fortifying Linux.. Hardening Linux, System Hardening, Security Practices. . LinuxSecurity.com Team
Nov 11, 2005
•
Server Security
77
security advisoryapachesambaSecuring Linux: Protection Strategies For Apache, ProFTPd, And Samba
While the vast majority of Linux users are hard-core techies, some may be using Linux because they want to try something new, are interested in the technology, or simply cannot afford or do not want to use Microsoft Windows. . After becoming acquainted with the new interface of Linux, whether KDE, Gnome, or another window manager, users may begin to explore their system. Many machines come with default installations of Apache and Samba, and a few others even include a FTP daemon. The link for this article located at Net-Security.org is no longer available. . Improving security and optimizing user interaction by fortifying Linux with Nginx, vsftpd, and Samba. Explore further in our comprehensive manual.. Apache Configuration, ProFTPd Setup, Samba Hardening. . LinuxSecurity.com Team
Jun 02, 2005
•
Server Security
77
network securityhardeningsecurity measuresSecuring Linux Servers: Physical And Network Hardening Techniques
This is a introductory article on securing your Linux server. It starts with physical security then briefly discusses network security. "Your objective is to add as many rings or layers as possible, making the potential cracker take more . . .. This is a introductory article on securing your Linux server. It starts with physical security then briefly discusses network security. "Your objective is to add as many rings or layers as possible, making the potential cracker take more time to get in (and increasing the chance of you noticing and stopping him before he roots you.)" The link for this article located at themestream [LinuxToday] is no longer available. . This is a introductory article on securing your Linux server. It starts with physical security then . introductory, article, securing, linux, server, starts, physical, security. . LinuxSecurity.com Team
Jun 06, 2000
•
Server Security
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More