Linux Security

Why ss Might Show No Open TCP Ports Even When Services Are Running

I’ve seen this happen on fresh installs, on servers that have just rebooted, and even on production machines that have been up for months. The symptom is simple: ss -tuln prints nothing, but systemctl status nginx (or whatever daemon you’re checking) says active (running). The mismatch usually boils down to one of three things:

1. The service is listening on a non‑TCP socket
2. The service is bound to a Unix domain socket or a local‑only address
3. The socket is managed by a socket‑activated unit that isn’t yet in use

Below is a quick checklist that will help you zero in on the culprit, plus a few hardening tips that come with each case.

HTTP is the backbone of most web services. When a client can’t reach a web server, the first instinct is to look at the application logs, DNS, or the network path. A silent drop by nftables is a common, yet often overlooked, culprit. This post walks through a systematic approach to uncovering why nftables is silently discarding HTTP packets, with a focus on the port‑filtering rules that most administrators set up for hardening.

I upgraded the kernel on my 2026‑era Debian‑based home‑lab server from 6.1.12‑generic to 6.5.0‑generic. The installer was a breeze – “All packages up to date” and a clean reboot. A few hours later, Nginx stopped answering HTTP. The systemctl status nginx looked like this:

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2026‑11‑06 14:32:12 UTC; 1h 12min ago
  Process: 1234 ExecStart=/usr/sbin/nginx -g daemon off; (code=exited, status=0/SUCCESS)
   Main PID: 1234 (code=exited, status=0/SUCCESS)

The master exited cleanly, yet the port was closed. The only clue? The kernel had changed. Below is the debugging walk‑through, the root cause, and how to harden the system so a kernel upgrade never silently kills a critical service again.

When a serverless function is granted a blanket AdministratorAccess policy, the blast radius of a compromised function is the entire account. In 2025, a handful of high‑profile breaches were traced back to overly permissive IAM roles attached to Lambda, Cloud Functions, or Azure Functions. The fix is simple: reduce the scope of the role to the minimum set of actions required by the function. Below is a practical walkthrough that blends AWS, Azure, and GCP examples, with a focus on Linux sysadmins who are comfortable with CLI, JSON, and policy evaluation.

A 30‑day retention window is a default in many backup scripts and commercial tools. It feels safe: “I’ll keep the last month of data, that’s enough for recovery.” In 2025, a mid‑size clinic used exactly that policy on a set of encrypted LVM snapshots stored on a single NAS. When the NAS firmware update rolled out, the snapshots were corrupted, and the backup system fell back to a restore‑all mode. The result? 2 TB of unencrypted PHI leaked to a rogue process that had gained write access to the backup directory.

Turning a Splunk Dashboard into a Hands‑On Threat‑Hunting Playbook

Splunk dashboards are great for visualizing data, but they rarely give you a ready‑to‑execute hunting workflow. In a real‑world environment you need a playbook that tells you what to look for, how to filter the data, and what to do when you find something. This post walks through turning an existing Splunk dashboard into a fully documented playbook that can be run by a sysadmin or a SOC analyst on a Linux host. The focus is on practical commands, trade‑offs, and troubleshooting tips that fit the Linux‑security‑first mindset of the Linux Security blog.

Spotting Silent Credential Dumping on Windows 10 Workstations with Sysmon Event ID 1

Why a Linux‑centric blog cares about Windows Sysmon

Mixed‑platform environments are the norm now. A Windows 10 workstation behind the same perimeter firewall, on the same Active Directory domain, can be the entry point for a lateral attack that eventually hits your Linux servers. Detecting credential dumping early on Windows is not a luxury; it’s a practical part of a sysadmin’s defensive toolbox. Sysmon, a lightweight Microsoft Sysinternals agent, writes detailed process‑creation events to the Windows event log. Event ID 1 (“Process creation”) is the most common entry and, when filtered correctly, can expose the classic “silent” credential‑dumping techniques that slip past traditional AV.

Why disabling unused systemd units matters

Every fresh install of a modern distro ships dozens of systemd units.
Bluetooth, CUPS, smart‑card readers, legacy daemons—you name it.
On a headless server most of those are overkill. They still eat a bit of RAM,
they create audit events that you’ll never look at, and they’re an extra attack surface.

The quickest way to shrink that surface and keep the journal from turning into a log‑dump is to disable the unit in one go and clean up its log space.

Freeing 5 GB of Disk Space by Pruning Old journalctl Logs on a 20 GB VPS

A 20 GB VPS is a tight fit. On a busy host, the system journal can grow fast, especially with frequent reboots, kernel messages, or misconfigured services that spam systemd-journald. When the journal consumes several gigabytes, you hit the “no space left on device” error on /var/log or /var/run, and the OS starts throttling services or, worse, refuses to start new ones.

Why systemd‑resolved is giving you 127.0.0.1 for every host

Ubuntu 24.04 ships with systemd‑resolved as the DNS resolver.
If every hostname you look up ends up at 127.0.0.1, the most common culprit is the search‑domain order that resolved builds.
It pulls the list from three places:

1. /etc/resolv.conf (or the DNS=/Domains= directives in /etc/systemd/resolved.conf)
2. DHCP‑provided domains
3. The machine’s own hostname ($HOSTNAME)

When localhost or the local hostname lands at the top, the resolver will try it before forwarding the query to the real DNS servers, and you’ll get a loopback address for any name that isn’t fully qualified.