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...
77
Linux securityserver protectionsecurity hardeningLinux Security Hardening Guide 2026 SSH Backup Strategies
Linux security is not about stacking tools and hoping for the best. It comes down to deliberate configuration, steady maintenance, and systems that can withstand real-world pressure. . Most production compromises still trace back to the same issues. Weak SSH settings. Unpatched services. Overexposed ports. Backups that fail when you need them. None of these are exotic threats; they are operational gaps. If you run Linux in production, hardening has to be practical and repeatable. Start With SSH, Because Attackers Do SSH is still the main entry point into Linux systems. Treat it like the front door, not a side entrance. The default configuration is rarely strict enough for production. A hardened setup should: Disable direct root login. Force administrative access through controlled privilege escalation. Disable password authentication; use public-key authentication only. Restrict allowed users or groups – Make access explicit. Limit authentication attempts – reduce the effectiveness of brute-force attacks. Set idle timeouts – Close forgotten sessions automatically. These are small changes inside the SSH daemon configuration, but they remove entire categories of risk. Quick check # Verify what is actually listening on the system ss -tulnp # Confirm SSH is running with the expected settings grep -E '^(PermitRootLogin|PasswordAuthentication|MaxAuthTries|AllowUsers|ClientAliveInterval)' /etc/ssh/sshd_config Then add automation. Fail2Ban brute-force protection watches authentication logs and temporarily blocks IP addresses that repeatedly fail to log in. It turns constant background probing into a non-issue without daily oversight. Quiet automation beats manual reaction every time. Patch Automatically, Review Intentionally Waiting for someone to remember to apply updates is not a strategy. Most modern Linux distributions support automatic security updates through their native package managers. Enable them. Security patchesshould apply without waiting for a maintenance window that never comes. That said, automation does not remove responsibility. A healthy workflow looks like this: Automatic security updates enabled – Shrinks exposure windows. Scheduled reboots when required – Kernel updates need to be activated. Weekly review of applied updates – Confirm nothing critical broke. Security improves when patching becomes routine instead of reactive. Treat Open Ports as Liabilities Every listening service is a potential foothold. Linux provides strong native firewall tools such as nftables and simpler front ends like UFW . The tooling matters less than the policy. A secure baseline should follow one rule: deny everything by default, allow only what is necessary. That means: Default deny inbound traffic – No open doors without a reason. Explicitly allow required services – SSH, application ports, nothing more. Quick check # Review active firewall rules (UFW example) ufw status verbose Port sprawl happens quietly over time. Regular review keeps exposure under control. Logging That Survives an Incident Logging often gets attention only after something goes wrong. By then, it is too late. Start with auditd. It provides kernel-level auditing and records changes to sensitive files, account modifications, and authentication events. This gives visibility beyond standard system logs. But local logs alone are fragile. If an attacker gains sufficient privileges, they can alter or delete them. Forward logs to a separate system. That might be a dedicated log server or a security monitoring platform isolated from production. The important part is separation. Retention matters as well. Incidents are sometimes discovered weeks after they begin. Keeping short-term searchable logs and longer-term archived copies makes forensic review possible. Logs are not just for troubleshooting. They are evidence. Backups Designed for Ransomware, Not HardwareFailure Backups used to focus on disk crashes. In 2026, they must assume hostile access. A resilient Linux backup strategy includes: Immutable backup storage – Prevent deletion or modification during a retention window. Offline or air gapped copies – Ensure at least one copy is unreachable from production systems. Separate credentials – Backup systems should not trust production authentication. Encrypted storage and transfer – Protect backup data itself. The step many teams skip is restore testing. Quarterly restore tests validate more than file recovery. They confirm permissions, ownership, database integrity, and recovery time expectations. A backup that has never been restored is a guess. Design backups as if an attacker already has administrative access. Because one day, they might. Container Security Is Not Automatic Isolation Containers improve deployment speed, but they do not eliminate risk. Running containers as root on the host defeats much of the isolation benefit. Rootless containers reduce that exposure and should be the default where practical. Layer in additional controls: Mandatory access control profiles – Enforce AppArmor or SELinux in enforcing mode, not permissive. Seccomp filters – Restrict unnecessary system calls. Minimal base images – Reduce the attack surface. Dropped Linux capabilities – Remove privileges containers do not need. Network boundaries – Prevent containers from freely reaching internal services. Containers are processes with namespaces, not magic boxes. Treat them with the same discipline as traditional services. Build a Security Rhythm Hardening is not a one-time event. It is a cadence. A practical operational rhythm looks like this: Weekly patch review – Confirm updates applied successfully. Weekly log sampling – Check authentication spikes or unusual access. Monthly port and service audit – Validate exposed services. Quarterly restore test – Provebackups work. Quarterly access review – Remove unused accounts and SSH keys. Security improves when it becomes part of the calendar. Resilience Over Perfection No Linux system is invulnerable. The goal is controlled exposure, fast detection, and reliable recovery. Tight SSH configuration. Automatic patching. Minimal open ports. Centralised logging. Ransomware-resistant backups. Hardened containers. A steady review cycle. That combination does more for real-world Linux security than any single tool ever will. Production safety is built through discipline, not optimism. . Most production compromises still trace back to the same issues. Weak SSH settings. Unpatched servic. linux, security, about, stacking, tools, hoping, comes, deliberate. . MaK Ulac
Feb 05, 2026
•
Server Security
74
incident responsesecurity incidentattack mitigationMitigation And Remediation Strategies For Unix Security Incidents
As we all know, prevention, detection and response are our three main lines of defence against threats, with a good administrator putting most focus on prevention. As the old adage goes, "an ounce of prevention is worth a pound of cure" - a 1:16 ratio for the metrically inclined - but there's always going to be the odd occasion where prevention fails, either through a lack of time or a mistake in one's security procedure. In this article we describe a few hardening and alerting methods for Unix servers that help block vectors for various attacks, including two web-based application attacks and the brute-forcing of SSH passwords. The article then looks at what an administrator should do post-compromise. These incidents have been drawn from both honeypots and real systems. . Today, devices such as stateful firewalls are common and people are paying more attention to vendor patches. This correlates with a trend of more attacks being carried out at the application level. For example, we are seing more and more instances of SQL injection, SSH password guessing, cross-site scripting attacks and leveraging browser flaws. For the purposes of this article, we assume the reader has a reasonable firewall configuration and that he makes an effort to keep up with OS and application patches; if not, this is an area to fix this first. We all benefit from applying a defence-in-depth strategy - ideally a network should still be secure even if any single security measure fails. The link for this article located at is no longer available. . Today, devices such as stateful firewalls are common and people are paying more attention to vendor . prevention, detection, response, three, lines, defence, against, threa. . Brittany Day
Jul 24, 2006
•
Network Security
77
security enhancementIT infrastructuree-commerceTrusted Operating Systems Boost E-Commerce Security for IT Departments
Enter the resurrection of the TOS (trusted operating system), a relic from the early '80s developed for military and government security. Considered by many to be too expensive and complicated to implement and maintain, TOSes failed to catch on when introduced . . . . Enter the resurrection of the TOS (trusted operating system), a relic from the early '80s developed for military and government security. Considered by many to be too expensive and complicated to implement and maintain, TOSes failed to catch on when introduced to the commercial sector and instead were pigeonholed into the financial industry. With today's corporate Web servers serving as the gateway to mission- critical e-business applications and information, however, IT departments should take a hard look at the new generation of TOSes. View illustration, "Compartmentalization is the key." A TOS is simply a security-hardened version of a standard OS. TOSes come in a variety of flavors, including Sun Solaris, Hewlett-Packard's HP-UX, IBM AIX, Linux, and Microsoft Windows NT. Trusted versions of these operating systems isolate key OS functions into separate compartments, limiting the ability of intruders to access and control critical parts of a computer system, as well as preventing administrators from making inadvertent, harmful changes. The link for this article located at IT World is no longer available. . The revival of reliable operating systems is crucial for strengthening e-commerce security, helping IT departments protect data and transactions effectively. Trusted Operating Systems, E-Commerce Security, IT Infrastructure. . LinuxSecurity.com Team
Feb 06, 2002
•
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