LinuxSecurity.com

Most SSH hardening advice ends at the same recommendation: Disable password authentication and use SSH keys.

Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload.

A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic.

Most of the time, nobody notices. SSH authentication succeeds, no alerts are generated, and the connection looks exactly the way it did the day the key was installed. That's part of the problem.

The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was.

You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back.

Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware.

Linux rootkits are old, but they never really disappeared. They just stopped attracting the same attention.

The wrong IPS rule can look like a security fix right up until it becomes an outage.

Exposed SSH servers are continuously hammered by brute-force attacks, password spraying, credential stuffing, and recycled passwords from infostealer dumps. Attackers rotate usernames, test weak credentials, and probe for anything that gives them initial access. The logs usually look messy long before the compromise happens.

The first 30 minutes after discovering a compromised Linux server usually decide how much evidence remains available. One rushed reboot or cleanup attempt can wipe logs, terminate malicious processes, or remove network activity that investigators still need to review. Attackers also do not usually stay on one system for long once access is established. Early response is mostly about preserving visibility. Collect process information. Save network connections. Limit access carefully before mak...

A production Linux server gets rebuilt from an old image. A contractor leaves. A CI/CD job is retired. Months later, the same SSH public keys are still sitting in authorized_keys, silently trusted by root or a service account nobody owns anymore.

When a Linux server initiates an unauthorized outbound connection to an unknown IP address, it rarely triggers an immediate system failure. Instead, the server continues running normally, and the connection is usually only discovered during a routine firewall log review, a DNS audit, or a post-incident investigation. Because there are no obvious system crashes or performance drops, these quiet outbound sessions can easily be overlooked.

For years, most software supply chain attacks focused on malicious dependencies and vulnerable open-source packages. Recent GitHub Actions compromises exposed a different problem entirely. Attackers increasingly target the automation systems responsible for building, testing, and deploying software because those systems often hold broader operational access than the applications themselves.

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.

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.

LinuxSecurity.com has been part of the Linux and open-source security community since the late 1990s. Over the years, the platform has evolved alongside the Linux threat landscape itself — from the early days of mailing lists and isolated vulnerability disclosures to today’s nonstop cycle of advisories, exploit research, malware reporting, supply chain attacks, and infrastructure-focused threat intelligence.

Linux privilege escalation starts once an attacker gets a foothold on a machine. Maybe it is a regular user account. Maybe it is an exposed application that nobody patched, or a reused password from another breach. Root access is usually the next objective. Attackers typically keep digging once inside, looking for a way to gain root privileges and remove the restrictions around them.

The recent FamousSparrow attacks reportedly relied on exposed web applications, ProxyLogon exploitation, and other well-known server-side vulnerabilities. 

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.