Forem: Hugo | DevOps | Cybersecurity

Split Tunneling: Performance vs Security in the Remote Work Era

Hugo | DevOps | Cybersecurity — Sun, 03 May 2026 12:33:03 +0000

I recently sat in a boardroom where a non-technical CISO was pounding the table, demanding that every single byte of data from 500 remote employees be forced through the corporate VPN. "Full Tunneling is the only way to ensure security!" he shouted.

Meanwhile, back in the server room, the network engineers were watching the office's primary 1Gbps fiber uplink choke to death. Why? Because half the staff was working from home with Netflix running in the background, or downloading 50GB Call of Duty updates, and all that irrelevant, non-business traffic was being hauled across the country into our datacenter, decrypted, inspected by a firewall that was never sized for that much throughput, and then shoved back out to the internet.

Congratulations. You’ve successfully "secured" your network by making it completely unusable for everyone.

If your "Security Policy" involves turning your office into a bottlenecked proxy for the entire internet's entertainment traffic, you aren't an architect; you're a glutton for punishment. It’s 2026. We have the tools to be surgical. It’s time to talk about Split Tunneling—the right way.

The Mechanics: Full Tunneling (The "Hammer" Approach)

In a Full Tunnel configuration, the VPN client modifies the operating system's routing table to set the "Default Gateway" to the virtual VPN interface. In networking terms, we are pushing a 0.0.0.0/0 route into the tunnel.

1. The Bottleneck Problem

When a remote worker is on a Full Tunnel, their computer says: "I don't care if I'm looking for a spreadsheet on the internal file server or a cat video on YouTube—send it all to the VPN."

This creates a massive "tromboning" effect. A packet goes from the user's home in New York, to the office in Chicago, gets inspected, and then goes back out to a server in Virginia. This adds massive latency (RTT) and consumes twice the bandwidth on your corporate circuit—once for the "ingress" from the user, and once for the "egress" to the destination.

2. The False Sense of Security

Admins love Full Tunneling because it allows them to use their expensive "Next-Gen" Firewalls to perform Deep Packet Inspection (DPI) on all user traffic. They think they are catching malware. In reality, most malware today is delivered over encrypted HTTPS (TLS 1.3) with Certificate Pinning. Unless you are performing invasive SSL decryption (which breaks half the modern web and opens its own can of privacy worms), your firewall is just watching encrypted blobs fly by. You are killing your performance for a security benefit that is largely theoretical for most remote workloads.

The Mechanics: Split Tunneling (The "Scalpel" Approach)

Split Tunneling is the practice of only sending specific, corporate-owned IP ranges through the VPN tunnel. Your internet traffic (Google, YouTube, Office 365) goes out through your local home ISP, while your internal traffic (Jira, GitLab, Database) goes through the VPN.

1. The Routing Logic

Instead of 0.0.0.0/0, the VPN client only adds specific routes—like 10.0.0.0/8 or 192.168.50.0/24—to the tunnel interface. The OS sees that a request for 10.0.5.20 matches the specific VPN route, but a request for 8.8.8.8 falls back to the default local gateway.

Tailscale & ZeroTier: Why You're Fighting CGNAT and Losing

Hugo | DevOps | Cybersecurity — Sat, 02 May 2026 12:33:03 +0000

I recently talked to a developer who spent three days trying to set up a WireGuard tunnel to his home server. He had the config perfect. He had the port forwarded on his router. He had the dynamic DNS updating every five minutes. But no matter what he did, he couldn't get a handshake.

I told him to check his WAN IP on his router and compare it to what "WhatIsMyIP" told him. Sure enough, his router showed a 100.64.x.x address.

"You're behind CGNAT," I said. "Your ISP isn't giving you a public IP. You're effectively behind a firewall that you don't own and can't control. You can't forward a port if the port doesn't belong to you."

If you’re still trying to use traditional "inbound" VPNs in an era where ISPs are hoarding IPv4 addresses like digital dragons, you aren't fighting a technical battle; you're fighting a losing war against the exhaustion of the internet's address space. It’s 2026. If you want to connect your devices without losing your mind to "Double NAT" hell, it’s time to embrace the "magic" of overlay networks like Tailscale and ZeroTier.

The Rant: The CGNAT Death Trap

Carrier-Grade NAT (CGNAT), specifically defined in RFC 6598, is the ISP's solution to the fact that we ran out of IPv4 addresses years ago. Instead of giving every customer a unique public IP, the ISP puts thousands of customers behind a single public IP. Your router gets a private address in the 100.64.0.0/10 range.

This works fine for 99% of people who just want to browse TikTok. But the moment you want to host a VPN, a Minecraft server, or a Plex instance, you hit a brick wall. Because you don't have a unique public IP, there is no way for a packet from the outside world to "find" your router. Traditional port forwarding is dead.

You can call your ISP and beg for a "Static IP" (which they will happily charge you $15/month for), or you can stop living in the past and use a mesh VPN that was designed to handle this exact nightmare.

The Mechanics: How the "Magic" Works

Tailscale and ZeroTier are often described as "magic" because you just install them, log in, and suddenly your devices can talk to each other as if they were on the same switch, regardless of firewalls, NAT, or CGNAT.

This isn't magic; it's sophisticated orchestration using three core technologies: STUN, TURN, and UDP Hole Punching.

1. STUN (Finding the Exit)

STUN (Session Traversal Utilities for NAT) is how a device finds out what it "looks like" to the outside world. Your server sends a packet to a STUN server on the public internet. The STUN server replies: "Hey, I saw your packet coming from public IP 203.0.113.5 on port 54321."

Now your server knows its external "mapped" address.

2. UDP Hole Punching (The Handshake)

This is the brilliant part. Most firewalls are "stateful." They block incoming packets by default, but they allow outgoing packets. Crucially, if you send an outgoing UDP packet to a destination, the firewall opens a temporary "hole" to allow a response from that same destination to come back in.

Tailscale’s coordination server tells both Peer A and Peer B: "Okay, both of you send a UDP packet to each other's mapped STUN addresses at the same time."

The MTU Nightmare: Why Your VPN Connection is Fragmenting to Death

Hugo | DevOps | Cybersecurity — Fri, 01 May 2026 12:33:04 +0000

I’ve lost count of how many times I’ve had to explain this to "Senior" DevOps engineers who think they’ve discovered a ghost in the machine. The symptoms are always the same: The VPN tunnel is "Up." You can ping the remote gateway. You can even SSH into the server. But the moment you run ls -al in a directory with 500 files, or try to scp a database dump, the terminal just... hangs.

The website starts to load—you see the favicon and the title in the tab—and then it spins forever, eventually timing out with a "Connection Reset."

You check the logs. Nothing. You check the CPU. Idle. You check the bandwidth. Plenty.

Congratulations. You aren't being hacked, and your app isn't buggy. You are suffering from an MTU mismatch, and your packets are being ruthlessly discarded by a "black hole" router that someone—likely a junior security admin with an itchy trigger finger—configured to block the very protocol meant to prevent this exact disaster.

The Mechanics: The 1500-Byte Delusion

To understand why your VPN is dying, you have to understand the Maximum Transmission Unit (MTU). On a standard Ethernet network, the MTU is almost universally 1500 bytes. This is the largest frame that can be sent across the physical wire without being broken into pieces.

When your application sends a packet, it assumes it has 1500 bytes of "room." It builds a 1500-byte IP packet. But your application is inside a VPN tunnel.

1. The VPN Tax (Overhead)

A VPN is an encapsulation protocol. It takes your original 1500-byte packet and wraps it inside another packet (the tunnel header) to send it across the internet.

WireGuard adds roughly 60-80 bytes of overhead.
OpenVPN or IPsec can add 60 to 100+ bytes depending on the cipher and padding.

If your original packet was already 1500 bytes, and you add 80 bytes of WireGuard headers, you now have a 1580-byte packet. When that packet hits the physical network interface, the OS realizes it’s too big for the 1500-byte limit of the physical wire.

2. Fragmentation vs. The "Don't Fragment" Bit

In a perfect world, the router would just "fragment" the packet—break it into two smaller pieces. But modern TCP/IP implementations almost always set the DF (Don't Fragment) bit. Why? Because fragmentation is computationally expensive and introduces massive latency.

When a 1580-byte packet with the DF bit set hits a router with a 1500-byte MTU, the router is supposed to drop the packet and send back an ICMP message: Type 3, Code 4: "Destination Unreachable, Fragmentation Needed and DF set."

This message includes the "Next-Hop MTU," telling the sender exactly how small the packet needs to be to fit. This process is called Path MTU Discovery (PMTUD).

The "Black Hole" Router: A Security Admin's Crime

Here is where the nightmare begins. Many "security-conscious" admins think that ICMP is "scary" or "dangerous." They configure their firewalls to DROP all ICMP traffic, thinking they are hiding from pings.

By dropping all ICMP, they have effectively blinded the network. Your server sends the 1580-byte packet. The intermediate router drops it and sends the "Fragmentation Needed" message. Your firewall sees the ICMP message, thinks it’s an attack, and drops it.

VLAN Segmentation: Why Your Smart Fridge Shouldn't Talk to Your File Server

Hugo | DevOps | Cybersecurity — Tue, 28 Apr 2026 12:33:04 +0000

I recently audited a homelab belonging to a "Senior Developer" who had over $10,000 worth of enterprise-grade server hardware. He had a 100TB ZFS storage array, three Proxmox nodes, and a dedicated Opnsense firewall. But when I looked at his network map, I nearly walked out.

Everything—his production database, his high-end workstation, his guest's iPhones, and thirty-five unpatched, $5 Chinese-made smart lightbulbs—was sitting on a single, flat 192.168.1.0/24 subnet.

"It makes it easier for the apps to find the devices," he told me.

If your definition of "easier" is providing a friction-less, high-speed highway for a Russian botnet to move from your $12 smart fridge to your corporate file server, then sure, a flat network is "convenient." But in the world of modern network architecture, a flat network is a sign of fundamental laziness. If you aren't segmenting your traffic, you aren't running a secure network; you're just hosting a digital mosh pit where the guy with the most infectious disease gets to hug everyone else.

The Mechanics: The "Inside-Out" Attack

To understand why a flat network is a disaster, you have to understand the concept of Lateral Movement.

Most hobbyists and junior admins think of security as a "perimeter" problem. They build a big, thick wall at the edge of the network (the firewall) and assume everything inside the wall is "trusted." This is an archaic 1990s mentality.

1. The IoT Trojan Horse

IoT devices—your smart cameras, lightbulbs, vacuum cleaners, and fridges—are notorious for having the security posture of a wet paper bag. They run ancient, unpatched Linux kernels (often 2.6.x), they have hardcoded "backdoor" credentials for manufacturer testing, and they almost never receive security updates.

When an attacker finds a vulnerability in that $12 Wi-Fi camera you bought on a whim, they don't use it to watch you sleep. They use it as a persistent, low-power pivot point. Because that camera is on the same subnet as your file server, the attacker is already "inside." They don't have to bypass your $500 firewall. They are already standing in your living room.

2. ARP Spoofing and Scanning

Once an attacker has a foothold on a single "dirty" device in a flat network, the entire subnet is at their mercy. They can perform ARP Spoofing (Man-in-the-Middle) to intercept your unencrypted traffic. They can run nmap scans to find every open port on your NAS. They can attempt to exploit known vulnerabilities in your PC.

In a flat network, there is no internal gatekeeper. Every device can "see" every other device. A compromise of the least secure device on your network is, by extension, a compromise of the most secure device on your network.

The Mechanics of the Fix: 802.1Q and Isolation

The Senior Network Architect's fix is Micro-Segmentation via VLANs (Virtual Local Area Networks).

Using the IEEE 802.1Q standard, we can take a single physical switch and "slice" it into multiple logical networks. Each slice is a separate broadcast domain. A device on VLAN 10 cannot even "see" a device on VLAN 20 unless you explicitly configure a router (and a firewall) to allow that traffic.

The 3-VLAN Blueprint

For a secure home or small office, you need a minimum of three distinct zones:

WireGuard vs OpenVPN: Why You're Still Driving a Tractor in a Formula 1 World

Hugo | DevOps | Cybersecurity — Mon, 27 Apr 2026 12:33:03 +0000

I recently consulted for a mid-sized enterprise where the "Standard Operating Procedure" for remote work involved a 50MB OpenVPN client that took exactly 32 seconds to complete a handshake. Every time a user moved from their home WiFi to a 5G connection, the tunnel would collapse, and they’d have to sit through the "Initializing..." loop all over again.

I asked the Head of Infrastructure why they were still using a protocol designed in 2001 to solve 2026 problems. His answer? "It’s what we’ve always used, and it has so many configuration options."

If your definition of a "feature" is a 100,000-line codebase filled with legacy C spaghetti and enough configuration toggles to accidentally downgrade your encryption to 1990s standards, then sure, OpenVPN is "feature-rich." But if you care about throughput, battery life, and a verifiable attack surface, you are driving a tractor in a Formula 1 world.

It is time to nuke the OpenVPN profiles and move to WireGuard.

The Mechanics: The Bloat vs. The Blade

To understand why WireGuard is objectively superior, you have to look at the codebase. OpenVPN (including its reliance on OpenSSL) is a behemoth. We are talking about hundreds of thousands of lines of code.

In the world of cybersecurity, code is liability. Every line of code is a potential buffer overflow, a memory leak, or a logic error waiting for a zero-day. Auditing OpenVPN is a multi-month academic project that very few people have actually completed.

WireGuard, by contrast, is roughly 4,000 lines of code. It is so small that a single, highly-competent security researcher can read the entire thing in an afternoon and actually understand every single state transition. It lives in the Linux kernel (as of 5.6), meaning it isn't just a "program" running on your OS; it is a fundamental part of the networking stack.

The Mechanics of Speed: User-Space vs. Kernel-Space

Why is OpenVPN so slow? It’s not just the encryption; it’s the Context Switching.

OpenVPN operates in "User-Space." When a packet arrives at your network card, the kernel has to context-switch to the OpenVPN process, let it decrypt the packet, and then context-switch back to the kernel to route that packet to the application. This "bounce" happens for every single packet. On high-speed 1Gbps+ links, this overhead becomes a massive bottleneck, pinning your CPU and introducing jitter.

WireGuard operates entirely in Kernel-Space. It uses the udp_tunnel infrastructure and high-performance cryptographic primitives (ChaCha20-Poly1305) that are optimized for modern CPU instruction sets. There is no bouncing. There is no context switching. This is why a $35 Raspberry Pi can push 800Mbps+ through a WireGuard tunnel while it chokes at 60Mbps on OpenVPN.

The Security: Cryptographic Agility is a Bug

OpenVPN fans love to brag about "Cryptographic Agility"—the ability to choose between 50 different encryption ciphers and hash functions.

As a Senior Engineer, I tell you: Agility is a vulnerability. When you have 50 options, you have the "Downgrade Attack" problem. An attacker can potentially trick your client and server into negotiating a weaker, broken cipher. WireGuard eliminates this by using a "Fixed Cryptographic Suite." It uses Curve25519 for key exchange, ChaCha20 for encryption, and Poly1305 for data authentication.

VLAN Segmentation: Because Your 'Smart' Toaster is a Moron (and a Security Risk)

Hugo | DevOps | Cybersecurity — Sat, 25 Apr 2026 12:33:03 +0000

This isn't a suggestion; it's a mandate. If you're running consumer-grade IoT junk on your primary network, you're not just inviting trouble, you're hand-delivering the keys to your entire digital kingdom. We're going to put that garbage in a cage, where it belongs. This guide details how to build that cage, because waiting for a patch from a company that went bust three years ago isn't a strategy, it's a death wish.

VLAN Segmentation: Because Your "Smart" Toaster is a Moron (and a Security Risk)

Introduction: The Unvarnished Truth About Your "Smart" Devices

Let's cut the marketing fluff. Your "smart" home is a collection of poorly engineered, minimally secured, and often abandoned devices. From thermostats to light bulbs, these gadgets are security vulnerabilities waiting to happen. They're built for convenience, not resilience, and certainly not with your network's integrity in mind. If you're treating them as trusted endpoints on your main LAN, you've already lost. This guide is about damage control: segmenting these digital delinquents into their own isolated VLANs, because the alternative is a compromised network and a long, painful cleanup. We're going to build firewalls, not trust.

The IoT Cesspool: A Litany of Flaws You Can't Ignore

The security posture of most Internet of Things devices is abysmal. This isn't an exaggeration; it's a fact. You're deploying embedded systems, often running ancient Linux kernels or custom RTOS variants, designed by junior engineers for minimum bill-of-materials, not maximum security. Understanding these inherent flaws is crucial to grasping why isolation is non-negotiable.

VLAN Segmentation: Securing IoT Devices from the Main Network

Hugo | DevOps | Cybersecurity — Fri, 24 Apr 2026 12:33:03 +0000

This isn't about making your network "smart"; it's about making it resilient to the inevitable stupidity of your "smart" devices. If you've got cheap junk phoning home on your primary network, you're not just inviting trouble, you're leaving the front door unlocked with a giant "Hack Me" sign outside. Let's fix that.

I. Introduction: Your "Smart" Toaster Is a Security Liability, and Here's How to Contain It

Let's get one thing straight: the vast majority of "smart" devices you've crammed into your home or small business network are not intelligent; they are security liabilities masquerading as convenience. Your network hygiene is likely appalling if you haven't tackled this head-on.

IoT devices are not merely insecure; they are often abandoned hardware running ancient, unpatched software, designed for rapid deployment, not robust security. Assume every single one is compromised or compromise-able the moment it touches your network. It's not if it gets owned, but when. The "smart" illusion leads most users, even IT pros who should know better, to plonk these devices directly onto their main network. This means your "smart" bulb can potentially sniff traffic from your workstation, or your compromised camera can pivot directly to your NAS, your financial data, or your corporate VPN session. This isn't just a risk; it's negligence, pure and simple.

The basic premise is this: VLANs are not a panacea, nor are they "advanced" networking arcana reserved for enterprise data centers. They are the absolute minimum, foundational step in containing the blast radius when [not if] these gadgets inevitably become part of a botnet, a cryptocurrency miner, or a backdoor into your sensitive data. If you haven't done this, you're playing Russian roulette with your digital assets. It’s 2024; this isn’t optional. This isn't theoretical best practice; it's basic, common-sense survival in a hostile digital landscape.

II. The Problem with "Smart": A Security Hellscape by Design

The term "smart" in IoT should raise immediate red flags, not expectations of brilliance. The reality is a security hellscape, born from vendor apathy and user complacency.

Vendor Negligence is the Standard: Manufacturers couldn't care less about security. Their business model is often built on racing to market with the cheapest possible hardware, slapping together outdated kernels, hardcoded credentials, and insecure protocols, then abandoning the device without a single firmware update after the sale. "Planned obsolescence" now includes security: your [smart] lightbulb from 3 years ago is running code riddled with [known] CVEs that will never be patched. These devices are frequently deployed with vulnerable versions of Linux, ancient libraries, and often contain backdoors or unauthenticated API endpoints. They phone home, they transmit telemetry, and they rarely offer any meaningful security controls to the end-user.

What Is Tailscale? The VPN That Doesn't Suck

Hugo | DevOps | Cybersecurity — Wed, 22 Apr 2026 12:33:03 +0000

The VPN Struggle Is Real

If you've ever tried to set up a traditional VPN — OpenVPN, WireGuard, IPsec — you probably know how it goes:

It takes hours (or days) to configure
Something always breaks with firewalls or DNS
You spend more time managing the VPN than doing real work

Enter Tailscale. It's a tool that feels like magic the first time you use it.
But it's not magic. It's just smart engineering.

So... What Is Tailscale?

Tailscale is a zero-config VPN built on top of WireGuard.

It creates a secure, private network between your devices — no matter where they are.

In other words:

Your phone can talk to your server at home.
Your laptop can SSH into your Raspberry Pi on a mobile hotspot.
Your Docker containers can reach your NAS over a Tailscale subnet.

All without touching a firewall or router. And yes — it just works.

Why It's a Game-Changer

Tailscale isn't "just another VPN". It's more like a trusted mesh network across all your devices.

Here's what makes it different:

Traditional VPN:

Painful to set up
Needs port forwarding
Breaks in restrictive networks
Shared secrets
No visibility

Tailscale:

1-minute install
No port forwarding
Works over NAT, firewalls, CGNAT
Uses OAuth (Google, GitHub, Microsoft)
Admin console for ACLs & devices

You get end-to-end encrypted connections, no central server required, and identity-based access control.

Use Case: Why I Can't Live Without It

In my setup, I manage:

A few Hetzner VPS servers
My homelab (ZimaBlade + Raspberry Pi)
A laptop, desktop, phone, and tablet

Before Tailscale, I was juggling SSH keys, port forwards, and DNS hacks. Now?

I can run tailscale up on a new server, and boom — it's part of my private network.
I can access 192.168.x.x home devices remotely via Tailscale subnet routing.
I use tailscale serve to spin up secure HTTPS dashboards in seconds.
I don't worry about firewalls. I don't need a static IP.
I don't even need to remember where my stuff is — it all just works.

Great for Developers, Freelancers, and Teams

Tailscale isn't just for homelab nerds.

If you:

Work remotely with sensitive code or production servers
Need to share secure access with clients or teammates
Want to avoid exposing ports to the open internet
Need a simple way to access internal dashboards

Then you'll love Tailscale.

Bonus: You can even share access with people outside your team via ACLs and ephemeral auth.

Integrations I Love

GitHub Actions: Auto-provision servers that join Tailscale immediately
Caddy + Tailscale Serve: Instant HTTPS reverse proxy
Rancher over Tailscale: Secure K8s access without public exposure
Syncthing + Tailscale: Secure file sync across all devices
Prometheus: Monitoring over encrypted tunnels

Tailscale becomes the glue for everything.

What's Coming Next?

This is only the beginning. In the next article and upcoming YouTube videos, I'll show you:

How to install and configure Tailscale on Linux (including headless)
How to expose internal web UIs securely using tailscale serve
How to combine Tailscale with Rancher, Docker, and Caddy for powerful, secure infrastructure
How to automate Tailscale onboarding in your CI/CD pipeline

WireGuard vs OpenVPN: Kernel Space vs User Space – A Reality Check

Hugo | DevOps | Cybersecurity — Mon, 20 Apr 2026 12:33:04 +0000

WireGuard vs OpenVPN: Kernel Space vs User Space – A Reality Check

1. Introduction: The Unavoidable Truth of VPNs

Let's be blunt: nobody wants a VPN. We use them because the underlying network infrastructure is either hostile, insecure, or poorly managed. It's a workaround for a broken world, a necessary evil. For years, OpenVPN has been the ubiquitous answer, a Swiss Army knife that did everything – often with the elegance of a brick. It was the default, the venerable solution, and for a long time, the only truly robust, open-source contender for flexible VPN deployments.

Now we have WireGuard, a newcomer that doesn't pretend to be more than it is: a fast, secure, simple layer 3 tunnel. It's a specialized tool, meticulously crafted for a single purpose, and it excels at it. This isn't just about "new shiny syndrome"; it's about a fundamental shift in design philosophy, rooted in the very execution context of the VPN daemon itself. We're talking kernel space versus user space, and the implications are significant, not just for theoretical performance metrics, but for your actual throughput, latency, CPU utilization, and ultimately, your sanity when trying to debug why "the VPN is slow." If you're still relying on solutions from the early 2000s, it's time to understand why you might be sacrificing performance, introducing unnecessary complexity, and perpetuating a configuration nightmare that modern alternatives have long since eradicated. The difference isn't just a detail; it's a foundational architectural decision with direct, measurable impact.

2. OpenVPN: The Grand Old Dame (User Space - And All Its Baggage)

OpenVPN arrived in a different era, one where kernel module development was less standardized, less portable across various operating systems, and often viewed with a healthy dose of suspicion by many administrators. The idea of running arbitrary, complex network code inside the kernel was concerning. Its design reflects this: a robust, flexible, but ultimately user-space application that leverages existing OS mechanisms for networking. It's mature, it's auditable (having been picked apart by countless eyes for nearly two decades), and it's slow – relatively speaking. This slowness isn't due to poor coding; it's an inherent limitation of its architectural choice.

2.1. Architectural Overview: The User Space Slog

OpenVPN operates primarily in user space. The openvpn daemon handles everything: key exchange (via the TLS/SSL protocol, typically using OpenSSL), data encryption/decryption (also via OpenSSL), packet encapsulation/decapsulation, and interaction with the virtual network interface (tun for IP packets, tap for Ethernet frames).

This user-space approach means that every single packet flowing through the VPN must traverse the user-kernel boundary multiple times. This is the crux of its performance limitation, the architectural "tax" you pay for its flexibility and historical context. Let's trace a packet:

Exposing SSH to 0.0.0.0: The Fast Track to a Brute-Force Apocalypse

Hugo | DevOps | Cybersecurity — Sun, 19 Apr 2026 12:33:03 +0000

Every day, a junior developer spins up a $5 DigitalOcean droplet, leaves port 22 exposed to 0.0.0.0/0, enables password authentication, and sets the root password to Company2026!.

A week later, they are posting on Reddit, utterly baffled as to why their server's CPU has been pinned at 100% for five days and their /var/log/auth.log is suddenly 50 gigabytes.

Congratulations. You didn't deploy a web server; you successfully deployed a new worker node for a Russian crypto-mining botnet. Leaving SSH wide open with default configurations is the absolute fastest way to lose control of a Linux machine.

The Mechanics: The Background Radiation of the Internet

There is a constant, ambient background radiation of malicious scanning on the internet. Within approximately 45 seconds of your server acquiring a public IPv4 address, automated scanners will find it.

These botnets don't care who you are. They are blindly hammering port 22 with millions of dictionary attacks and credential stuffing payloads. If your sshd_config allows root logins with a password, you have already done half their job for them—they don't even have to guess the username.

They will throw admin, root, ubuntu, and test at your daemon ten times a second until the server either crashes from the IO overhead of writing failed auth logs, or they guess the password. Once they have a root shell, they drop a persistence script in /etc/cron.d, alter your authorized keys, and start hunting for AWS credentials in your environment variables.

The Fix: Kill Passwords and Jail the Noise

The Senior Sysadmin approach to SSH is uncompromising: Passwords are dead. If you are using a password to authenticate to a production Linux server in the current year, you are doing it wrong. You must enforce public key authentication (specifically Ed25519 keys, stop using weak RSA), disable root login entirely, and disable password authentication.

As a secondary layer, you implement Fail2Ban or CrowdSec. While dropping passwords makes brute-forcing mathematically impossible, the botnets will still try, filling your disk with garbage logs. Fail2Ban monitors those logs and automatically drops a firewall block on any IP that fails authentication 5 times.

Finally, move SSH off port 22. It is not "security," it is security through obscurity—but changing the port to 50222 will instantly filter out 98% of the automated script-kiddie noise hitting your daemon.

The Code & Config

Here is the default garbage you usually find in /etc/ssh/sshd_config.

# THE BAD WAY (A Botnet Welcome Mat)
Port 22
PermitRootLogin yes
PasswordAuthentication yes

Here is the hardened, DevSecOps-approved configuration. Open /etc/ssh/sshd_config, make these changes, and run systemctl restart sshd. (Make sure your SSH key is actually installed before you do this, or you will lock yourself out).

# THE REAL ENGINEER'S WAY (Zero Trust SSH)

# Move the port to drop the automated noise
Port 50222

# Only allow Protocol 2 (Usually default, but be explicit)
Protocol 2

# THE FIX: Kill root login and password auth entirely
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes

# Optional: Only allow specific users to even attempt login
AllowUsers deploy_user admin_user

To stop the log spam, install Fail2Ban (apt install fail2ban) and drop this configuration into /etc/fail2ban/jail.local:

Hardcoded Passwords in Scripts: That's Not Automation, That's a Breach

Hugo | DevOps | Cybersecurity — Sat, 18 Apr 2026 12:33:03 +0000

There is a special place in infrastructure hell for sysadmins who write "automation" scripts with $AdminPassword = "CompanyAdmin2026!" right at the top.

You usually find these masterpieces sitting on a globally readable network share like \\fs01\IT_Scripts\NewUserSetup.ps1, or worse, pushed to a public GitHub repository because someone didn't understand how .gitignore works.

Let’s get one thing straight: if your script contains a plain-text password, you didn't write an automation script. You wrote a self-service portal for threat actors. You are doing the attacker's job for them.

The Mechanics: The String Search

When a threat actor or an automated worm breaches a low-level workstation on your network, they don't immediately start dropping zero-days. They live off the land. One of the very first enumeration steps is mounting available network shares and running a recursive search for files ending in .ps1, .sh, .bat, or .py.

Once they find those files, they just grep for strings like password, pwd, credential, or api_key.

If anyone with read access to that file share can read the script, anyone can own the domain. It doesn't matter how complex the password is if you leave it written on a digital Post-it note attached to the execution file.

The Fix: DPAPI and Secret Vaults

Stop hardcoding secrets. If you need a script to run unattended, you have to decouple the credential from the code.

For enterprise environments, the correct answer is a dedicated secrets engine like HashiCorp Vault, Azure Key Vault, or AWS Secrets Manager. Your script authenticates via a managed identity or machine certificate, pulls the secret dynamically into memory, uses it, and dumps it.

If you don't have a vault, you can still secure local automation using the Windows Data Protection API (DPAPI). PowerShell's Export-Clixml cmdlet can serialize a credential object and encrypt it using a key tied specifically to the Windows user account and the machine executing the script. If an attacker copies the XML file to another machine, or tries to read it as a different user, it fails to decrypt.

The Code

Here is the script that guarantees your Domain Controller gets encrypted by Friday:

# THE BAD WAY (A breach waiting to happen)
# Anyone who can read this file owns the hypervisor

$Username = "admin@corp.local"
$Password = "SuperSecretAdmin123!"
$Cred = New-Object System.Management.Automation.PSCredential($Username, (ConvertTo-SecureString $Password -AsPlainText -Force))

Connect-VMHost -Server vcenter.corp.local -Credential $Cred

Here is the Senior Sysadmin approach using local DPAPI encryption.

First, as a one-time setup step logged in as the service account running the automation, you prompt for the password and encrypt it to disk:

# ONE-TIME SETUP (Run as the Service Account on the execution machine)
Get-Credential | Export-Clixml -Path "C:\SecureScripts\Credentials\vcenter_cred.xml"

Then, your actual automation script just imports that encrypted object. No plain-text secrets in the code, no hardcoded strings for malware to scrape.

# THE REAL ENGINEER'S WAY (Decoupled and Encrypted)
# The credential can only be decrypted by the specific Service Account on this specific machine.

$CredPath = "C:\SecureScripts\Credentials\vcenter_cred.xml"

if (-Not (Test-Path $CredPath)) {
    Write-Error "Credential file missing. Cannot authenticate."
    exit 1
}

MFA Fatigue: Why Your 'Secure' Push Notifications Are Getting You Hacked

Hugo | DevOps | Cybersecurity — Fri, 17 Apr 2026 12:33:04 +0000

Companies will spend $50,000 a year on a premium Identity Provider (IdP) tier, roll out an authenticator app to the entire org, and proudly declare themselves "unhackable" at the next board meeting.

Then Kevin in Sales gets his password scraped by an infostealer. At 2:14 AM on a Tuesday, his phone buzzes. He ignores it. At 2:15 AM, it buzzes 30 more times in rapid succession. Bleary-eyed, irritated, and just wanting the screen to go dark so he can go back to sleep, Kevin hits "Approve".

Congratulations. Your multi-million dollar security perimeter was just breached because Kevin was tired.

Basic push notifications are not a security boundary; they are an annoyance threshold. If your security architecture relies on a binary "Yes/No" from an exhausted human, it is structurally flawed.

The Mechanics: Prompt Bombing

This attack vector is known as "MFA Fatigue" or "Prompt Bombing," and it is the primary way threat actors like Lapsus$ and Scattered Spider have been breaching Fortune 500s.

The attacker already has the valid username and password—usually bought for $5 on a darknet market or phished via a fake Office 365 login page. The only thing standing between them and your corporate VPN is the MFA prompt. So, they script the login portal to fire authentication requests repeatedly.

Sometimes they don't even rely on pure fatigue. They will hit the user with three prompts, then immediately call the user's phone, spoofing the caller ID to look like the internal Helpdesk. "Hi, this is IT. We're doing an overnight server migration and need you to acknowledge the prompt on your phone to keep your account active."

The user taps "Approve", the attacker gets the session token, and they are in. It relies entirely on human psychology, requiring zero technical sophistication once the password is known.

The Fix: Kill the "Approve" Button

The modern Zero-Trust approach dictates that you must immediately disable simple "Approve/Deny" push notifications.

You must enforce Number Matching. With Number Matching, the login screen displays a randomly generated 2-digit number. The user cannot simply tap "Approve"; they must open their authenticator app and manually type that specific number. You cannot type the number if you aren't the one looking at the login screen. It completely neutralizes MFA fatigue.

For highly privileged accounts (Domain Admins, Global Admins), you should deprecate phone-based MFA entirely. Mandate FIDO2 hardware keys (like YubiKeys). FIDO2 is cryptographically bound to the TLS session and the specific domain being accessed, making it mathematically phishing-resistant.

The Code & Config

If you are using Microsoft Entra ID (formerly Azure AD), Number Matching is now the default, but if you have legacy policies overriding it, you are vulnerable. Here is the Microsoft Graph API payload to strictly enforce Number Matching, along with application context and geographic location display.

// THE REAL ENGINEER'S WAY (Enforce Number Matching via MS Graph API)
// PATCH [https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/microsoftAuthenticator](https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/microsoftAuthenticator)