DEV Community: Faruk

Linux Security Habit #14: I Snapshot Network State Before I Even Look at Logs

Faruk — Sun, 04 Jan 2026 00:19:41 +0000

Linux Security Habit #14: I Snapshot Network State Before I Even Look at Logs

When something feels off on a Linux serv
er, most people jump straight into logs.

I don’t.

Logs are history.
The network is now.

Before I read a single log line, I capture the current network state. That snapshot often tells me more in 30 seconds than logs do in 30 minutes.

Why logs should not be first

Logs can be:

Rotated
Truncated
Delayed
Or intentionally cleaned
Attackers know this. They plan for it.

If a system is compromised, it almost always needs live network activity
Outbound connections to command and control
DNS lookups to unfamiliar domains
Listening services that should not exist
Processes talking over ports they have no business using
Once those connections drop, the evidence is gone.

That’s why I snapshot first.
What I capture immediately
Before touching logs or restarting anything, I capture:
Active connections and listening ports
Established outbound connections

DNS behavior
Routing and interfaces
Process-to-connection mappings

This freezes the moment in time. Even if the attacker disconnects seconds later, I now have proof.

The pattern logs often miss
I have seen many incidents where:
Auth logs looked clean
No brute-force attempts appeared
No obvious errors showed up
Yet the network snapshot revealed:
Persistent outbound TLS connections
Traffic to IPs unrelated to the server’s role
Legit-looking processes doing illegitimate things
Logs stayed quiet because the attack worked.

Why this habit matters

Taking the network snapshot first:
Preserves evidence
Prevents accidental destruction of context
Shortens investigation time
Leads to faster containment decisions

It also prevents the worst mistake in incident response:
changing system state before understanding it.

If you want this automated

I built a small tool that automates this exact habit.

🔐 Incident Snapshot & Evidence Generator (Linux)
Captures network state, processes, auth activity, and persistence signals in one quick run.
👉 https://ko-fi.com/s/22ab38ab12

It runs fast, does not modify system state, and gives you a clean evidence bundle to analyze calmly.

Strengthen SSH before incidents happen

If SSH exposure is part of your threat model, this helps catch attacks in real time.

🔐 SSH-IDS — Real-Time SSH Intrusion Detection for Linux
Email alerts, optional auto-blocking, lightweight and simple.
👉 https://ko-fi.com/s/9b510f7393

Free checklist (no spam)

If you want to harden SSH the right way before things go wrong:

📄 Free SSH Hardening Checklist (PDF)
👉 https://preview.mailerlite.io/preview/1998020/sites/174539599429764363/6lso1l?fresh=1

Final thought

Logs tell you what survived.
The network tells you what is happening.
Snapshot first. Analyze second.

Follow me on social media:
🔗 LinkedIn: https://www.linkedin.com/in/bornaly/
✍️ Medium: https://medium.com/@bornaly/subscribe
💬 Discord: https://discord.gg/FkjR2WFs
🐦 X (Twitter): https://x.com/cyberwebpen
📘 Facebook: https://www.facebook.com/nextgenthreat

I Got Tired of Guessing About Linux Security — So I Built a One-Command Snapshot

Faruk — Thu, 01 Jan 2026 14:19:09 +0000

Most Linux servers don’t fail loudly when something goes wrong.
They drift.

A new cron job.
A modified binary.
A quiet outbound connection.

Nothing obvious — until it matters.

I noticed that when I wanted to “check a server,” I kept running the same commands manually, hoping I didn’t forget anything. That doesn’t scale, and it’s easy to miss context.

So I built a small, read-only tool for myself:

Linux Blindspot Report
It runs once and generates:
A risk score + severity summary
A clean HTML report
A TXT report for SSH-only systems

A local evidence pack you can review or escalate

No agents.
No installs.
Nothing sent off the box.

It doesn’t replace full forensics — it gives you fast clarity.

If you’re interested, details are here:
👉 [https://ko-fi.com/s/288adc543e]

I also share a free SSH hardening checklist (no email):
👉 [https://preview.mailerlite.io/preview/1998020/sites/174539599429764363/6lso1l?fresh=1]

Happy to hear feedback from other Linux admins.

Why I Use Cold Backups Instead of Relying Only on Snapshots | by Faruk Ahmed | Sep, 2025

Faruk — Thu, 25 Sep 2025 22:42:49 +0000

Member-only story

Why I Use Cold Backups Instead of Relying Only on Snapshots

Most teams rely on snapshots or live backups to protect their Linux servers. They’re fast, convenient, and easy to schedule. But I’ve learned the hard way: snapshots alone aren’t enough.

That’s why I always keep cold backups — offline, disconnected copies that malware or attackers can’t touch.

🚨 The Problem With Snapshots Alone

Ransomware Ready → If your hypervisor or cloud account is compromised, snapshots can be encrypted right along with production.
Silent Corruption → Snapshots faithfully preserve corruption too . If the system is already compromised, your snapshot is a compromised clone.
Same Trust Boundary → Snapshots live in the same environment as the system itself — if an attacker gets root or cloud admin, they own your backups too.

🛡️ Why Cold Backups Are Different

Air-Gapped → Disconnected from the network after creation.
Immutable → Copies can’t be altered without deliberate action.
Recoverable → Even if production is destroyed, you can rebuild from the offline backup.

🛠 How I Do It

👉 Read Full Blog on Medium Here

Why I Don’t Trust Default Firewall Rules on Linux Servers | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 22:37:10 +0000

Member-only story

Why I Don’t Trust Default Firewall Rules on Linux Servers

Every Linux distro ships with its own firewall defaults — whether that’s ufw , firewalld , or plain iptables . But in my experience, default firewall rules are never enough.
ufw firewalld iptables
Here’s why I never rely on them, and how I build firewall policies that actually protect my servers.

🚨 The Problem With Default Rules

Too Permissive Some distros allow all outbound traffic by default — including to malicious IPs.
Assumes “One Size Fits All” A web server and a database server shouldn’t have the same rules, but defaults often treat them the same.
Silent Gaps Some ports stay open unintentionally (like 111 for RPC or 631 for CUPS) because they’re bundled in “trusted services.”
No Egress Control Attackers love defaults because they almost always allow outbound C2 (command-and-control) traffic.

🔐 My Firewall Hardening Steps

1. Deny by Default

Set all inbound traffic to deny unless explicitly allowed.

With UFW:

ufw default deny incoming ufw default allow outgoing

👉 Read Full Blog on Medium Here

The Linux Log Hackers Hope You Never Check | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 22:31:39 +0000

Member-only story

The Linux Log Hackers Hope You Never Check

When attackers brute-force SSH or slip in with stolen credentials, they usually leave their first footprints in one place: /var/log/auth.log (or /var/log/secure on RHEL).
/var/log/auth.log /var/log/secure
Most admins overlook it. Hackers count on that. I don’t — and it’s saved me more than once.

🚨 Why This Log Is So Critical

Shows every SSH login attempt (success or failure)
Records sudo privilege escalations sudo - Logs session activity for cron, systemd, and more
Reveals unusual IPs, odd login times, and brute-force patterns

If you ignore it, you’re flying blind.

🧪 Real Breach Clues I’ve Caught

Brute Force Bots Hundreds of Failed password for root from 45.xxx… attempts in minutes. → Blocked with fail2ban. Failed password for root from 45.xxx… - Suspicious User Access A developer logging in at 3 AM from overseas. → Traced to a compromised laptop.
Misconfigurations PAM errors from a broken cron job spamming auth.log. → Fixed before it spiraled into outages.

🛠 How I Monitor It

Live View

tail -f /var/log/auth.log

👉 Read Full Blog on Medium Here

I Asked My Linux Server to Predict My Death. The Result Froze Me | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 22:31:36 +0000

Member-only story

I Asked My Linux Server to Predict My Death. The Result Froze Me

I thought it was just a script for fun. Until it gave me a date I can’t unsee — and started acting like it knew something I didn’t.

The Joke That Went Too Far

I was bored one night, tinkering on my Linux machine like always.

I thought: What if I could make my server predict my death date?

Not seriously — just a random future date from a script I’d call DeathPredictor.sh . I wrote it in 15 minutes.
DeathPredictor.sh

#!/bin/bash year=$(( $(date +%Y) + (RANDOM % 50 + 1) )) month=$(( RANDOM % 12 + 1 )) day=$(( RANDOM % 28 + 1 )) date -d "$year-$month-$day" +"%d %B %Y"

Simple. Creepy. Harmless.

But when I ran it…

It Gave Me a Real Date

user@server:~$ ./DeathPredictor.sh 16 April 2043 user@server:~$

Then the server froze. No logs. No CPU spike. Just silence — for 43 seconds.

Then it came back online.

The Date Meant Something

At first, I laughed it off. But 16 April 2043 felt… familiar. I searched my notes, my calendar, even old family records.

👉 Read Full Blog on Medium Here

The Hidden Danger of Old Users: Why I Regularly Audit /etc/passwd on My Linux Servers | by Faruk Ahmed | nextgenthreat

Faruk — Wed, 24 Sep 2025 18:33:21 +0000

Member-only story

The Hidden Danger of Old Users: Why I Regularly Audit /etc/passwd on My Linux Servers

Intro: Think your server is secure because it has no root logins and a strong firewall? You might be forgetting something silent but dangerous: stale user accounts . Over time, forgotten system users, leftover developers, or unrevoked test accounts pile up — and they’re a goldmine for attackers. Here’s why I audit /etc/passwd regularly, and how you can do it too.
/etc/passwd

1. Why Old User Accounts Are a Real Risk

Unused accounts are often ignored in patching or permission reviews.
Some may still have sudo access or weak passwords.
If one is compromised, it could provide lateral movement inside your environment.

2. My Quick Script to List Human Users

System accounts are usually below UID 1000. I use this to find real users:

awk -F: '$3 >= 1000 && $1 != "nobody" { print $1 }' /etc/passwd

Want more detail?

getent passwd | awk -F: '$3 >= 1000 && $7 != "/usr/sbin/nologin" && $7 != "/bin/false"' | cut -d: -f1,6,7

This lists:

Username
Home directory

👉 Read Full Blog on Medium Here

Why I Always Use chattr to Protect Critical Linux Files | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 18:32:31 +0000

Member-only story

Why I Always Use chattr to Protect Critical Linux Files

`chattr`

Permissions in Linux are powerful, but sometimes they’re not enough. If an attacker gets root, they can still modify or delete sensitive files. That’s why I use the chattr (change attribute) command as an extra layer of defense.
chattr
It’s a small step that can block both mistakes and attacks.

🚨 Why Permissions Alone Aren’t Enough

Root override → Even if files are chmod 600 , root can still edit them. chmod 600 - Accidental edits → Admins (myself included) can mistype commands and break critical configs.
Malware persistence → Many backdoors work by silently modifying files like /etc/passwd or /etc/ssh/sshd_config . /etc/passwd /etc/ssh/sshd_config ## 🔐 How chattr Helps chattr The chattr command lets you add special attributes to files on ext filesystems. Most useful: chattr - +i → Immutable : file cannot be modified, renamed, or deleted (even by root). +i - +a → Append-only : file can only be written to (not erased). +a ## 🛠️ Step 1: Protect Sensitive Configs

Example: Protect SSH config.

chattr +i /etc/ssh/sshd_config

👉 Read Full Blog on Medium Here

Why I Always Restrict Cron Jobs on Linux Servers | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 18:27:28 +0000

Member-only story

Why I Always Restrict Cron Jobs on Linux Servers

Cron is one of the most powerful features in Linux — it automates tasks, rotates logs, and runs maintenance scripts. But in my experience, cron is also one of the easiest places for attackers to hide persistence .

That’s why I always restrict, monitor, and audit cron jobs as part of my hardening process.

🚨 Why Cron Jobs Can Be Dangerous

Persistence Backdoor Attackers drop malicious scripts in /etc/cron.d/ or user crontabs to execute silently. /etc/cron.d/ - Privilege Abuse If cron runs as root, even a simple script ( wget a payload, start a reverse shell) can compromise the system. wget - Silent Failures A cron job can fail quietly without alerting you, while malicious jobs keep running unnoticed.

🔍 Step 1: List All Cron Jobs

System-wide:

ls -la /etc/cron* cat /etc/crontab

Per user:

crontab -l -u username

Systemd timers (often overlooked):

systemctl list-timers --all

🛠 Step 2: Restrict Cron Access

Edit:

vi /etc/cron.allow vi /etc/cron.deny

👉 Read Full Blog on Medium Here

Why I Always Disable Unused Services on Linux Servers | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 18:27:00 +0000

Member-only story

Why I Always Disable Unused Services on Linux Servers

When I take over a new Linux server, one of the first things I do is check which services are running . Why? Because every service left running is another potential door for attackers .

Here’s why disabling unused services is one of the fastest wins in hardening — and how I do it step by step.

🚨 The Risks of Leaving Services Running

Increased Attack Surface An open port means someone can knock on it. Even if the service isn’t vulnerable today, it could be tomorrow.
Privilege Escalation Paths Services running as root can become a direct route to full system compromise. root - Resource Drain Unused daemons eat CPU, memory, and bandwidth for no reason.
Compliance Failures CIS Benchmarks, PCI-DSS, and HIPAA all require minimizing unnecessary services.

🔍 Step 1: Identify What’s Running

Check active services:

systemctl list-unit-files --type=service --state=enabled

Check open ports:

ss -tulnp

➡️ Any service listening externally that you don’t need is a candidate for shutdown.

👉 Read Full Blog on Medium Here

Why I Always Set a Login Banner on Linux Servers (and What I Put in It) | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 17:50:55 +0000

Member-only story

Why I Always Set a Login Banner on Linux Servers (and What I Put in It)

Most admins skip the login banner. It feels cosmetic — just text before the login prompt. But in reality, it’s one of the most underestimated security controls I use on my Linux servers.

Here’s why I always enable it, what I include in it, and how it helps both security and compliance.

🚨 Why a Login Banner Matters

Legal Warning A banner makes it crystal clear: “Unauthorized access is prohibited.” This helps protect you legally if your system is breached.
Deters Casual Attackers Automated bots won’t care — but opportunistic attackers often move on when they see a monitored system.
Compliance Requirement CIS Benchmarks, PCI-DSS, HIPAA, and government systems all require banners.
User Accountability Even legit users are reminded that activity is logged and monitored.

🛠 Step 1: Set the Message

Edit /etc/issue for pre-login banners:
/etc/issue

vi /etc/issue

Example:

WARNING: This system is for authorized use only. All activities are monitored and logged. Unauthorized access will be prosecuted.

👉 Read Full Blog on Medium Here

Why I Always Disable Unused Linux Services After Installation | by Faruk Ahmed | Sep, 2025

Faruk — Wed, 24 Sep 2025 17:49:59 +0000

Member-only story

Why I Always Disable Unused Linux Services After Installation

A fresh Linux install might feel clean — but behind the scenes, it often starts up services you don’t actually need. Each one is another open door, another potential exploit, and another log entry you have to monitor.

That’s why one of my first hardening steps is simple: disable everything I’m not using.

🚨 The Risk of Unnecessary Services

Attack Surface : Every listening service is a potential entry point.
Resource Drain : Idle daemons still consume CPU and memory.
Noise in Logs : More services = more clutter, harder to spot real issues.
Zero-Day Risk : Even unused software can be hit by future vulnerabilities.

🔍 Step 1: Check Active Services

I start with:

systemctl list-unit-files --type=service --state=enabled

Or to see running services:

systemctl --type=service --state=running

Then I cross-check against what the server is actually supposed to do.

DEV Community: Faruk

Linux Security Habit #14: I Snapshot Network State Before I Even Look at Logs

I Got Tired of Guessing About Linux Security — So I Built a One-Command Snapshot

Why I Use Cold Backups Instead of Relying Only on Snapshots | by Faruk Ahmed | Sep, 2025

Why I Use Cold Backups Instead of Relying Only on Snapshots

🚨 The Problem With Snapshots Alone

🛡️ Why Cold Backups Are Different

🛠 How I Do It

👉 Read Full Blog on Medium Here

Why I Don’t Trust Default Firewall Rules on Linux Servers | by Faruk Ahmed | Sep, 2025

Why I Don’t Trust Default Firewall Rules on Linux Servers

🚨 The Problem With Default Rules

🔐 My Firewall Hardening Steps

1. Deny by Default

👉 Read Full Blog on Medium Here

The Linux Log Hackers Hope You Never Check | by Faruk Ahmed | Sep, 2025

The Linux Log Hackers Hope You Never Check

🚨 Why This Log Is So Critical

🧪 Real Breach Clues I’ve Caught

🛠 How I Monitor It

Live View

👉 Read Full Blog on Medium Here

I Asked My Linux Server to Predict My Death. The Result Froze Me | by Faruk Ahmed | Sep, 2025

I Asked My Linux Server to Predict My Death. The Result Froze Me

The Joke That Went Too Far

It Gave Me a Real Date

The Date Meant Something

👉 Read Full Blog on Medium Here

The Hidden Danger of Old Users: Why I Regularly Audit /etc/passwd on My Linux Servers | by Faruk Ahmed | nextgenthreat

The Hidden Danger of Old Users: Why I Regularly Audit /etc/passwd on My Linux Servers

1. Why Old User Accounts Are a Real Risk

2. My Quick Script to List Human Users

👉 Read Full Blog on Medium Here

Why I Always Use chattr to Protect Critical Linux Files | by Faruk Ahmed | Sep, 2025

Why I Always Use chattr to Protect Critical Linux Files

chattr

🚨 Why Permissions Alone Aren’t Enough

👉 Read Full Blog on Medium Here

Why I Always Restrict Cron Jobs on Linux Servers | by Faruk Ahmed | Sep, 2025

Why I Always Restrict Cron Jobs on Linux Servers

🚨 Why Cron Jobs Can Be Dangerous

🔍 Step 1: List All Cron Jobs

🛠 Step 2: Restrict Cron Access

👉 Read Full Blog on Medium Here

Why I Always Disable Unused Services on Linux Servers | by Faruk Ahmed | Sep, 2025

Why I Always Disable Unused Services on Linux Servers

🚨 The Risks of Leaving Services Running

🔍 Step 1: Identify What’s Running

👉 Read Full Blog on Medium Here

Why I Always Set a Login Banner on Linux Servers (and What I Put in It) | by Faruk Ahmed | Sep, 2025

Why I Always Set a Login Banner on Linux Servers (and What I Put in It)

🚨 Why a Login Banner Matters

🛠 Step 1: Set the Message

👉 Read Full Blog on Medium Here

Why I Always Disable Unused Linux Services After Installation | by Faruk Ahmed | Sep, 2025

Why I Always Disable Unused Linux Services After Installation

🚨 The Risk of Unnecessary Services

🔍 Step 1: Check Active Services

🛠 Step 2: Disable What’s Not Needed

👉 Read Full Blog on Medium Here

`chattr`