DEV Community: Hugo | DevOps | Cybersecurity

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)

Port 3389 to the World: How to Lose Your Company Data Over the Weekend

Hugo | DevOps | Cybersecurity — Thu, 16 Apr 2026 12:33:03 +0000

It’s 4:30 PM on a Friday. The head accountant insists they need to finish payroll from home over the weekend. The junior IT guy, wanting to be helpful and avoid setting up a VPN profile, logs into the edge firewall, creates a quick NAT rule forwarding TCP 3389 straight to the internal terminal server, and goes to the pub.

By Monday morning, every file server, domain controller, and backup repository on the network ends in .lockbit.

If you are exposing Remote Desktop Protocol (RDP) directly to the public internet in the current year, you are not administering a network. You are operating a honeypot. It is the single most amateur mistake in Windows system administration, and it is the primary vector for ransomware groups globally.

The Mechanics: The 48-Hour Guarantee

You might think your obscure static IP address is flying under the radar. It isn't.

Mass-scanning botnets map the entire IPv4 address space in a matter of hours. When you open port 3389, it takes roughly 45 minutes for automated scanners to find it and flag your IP in a Telegram channel.

Once the port is discovered, the attack branches into two paths:

Credential Stuffing: Automated scripts hammer your login prompt with leaked credentials, default passwords, and variations of Administrator and Company2026!. If you don't have aggressive Active Directory account lockout policies enabled, they will eventually brute-force their way in.
Protocol Exploits: If the server is missing a few critical Windows Updates, attackers just fire off a known RDP vulnerability payload—like the infamous BlueKeep (CVE-2019-0708). This gives them pre-authentication remote code execution at the SYSTEM level.

Once they have an RDP session, the game is over. They deploy Cobalt Strike, disable Windows Defender, dump LSASS memory to harvest Domain Admin credentials, and move laterally across your hypervisors.

The Fix: Kill the NAT Rule

The Senior Sysadmin approach to RDP is absolute: Never, under any circumstances, expose 3389 to the internet. If users need remote access, you implement layers:

The Network Layer: Users must connect to a proper VPN (WireGuard or IPsec) before they can even route to the internal subnet where the RDP server lives.
The Gateway Layer: If you absolutely cannot use a VPN client, deploy a Remote Desktop Gateway (RD Gateway) behind a reverse proxy. This encapsulates the RDP traffic over HTTPS (TCP 443).
The Identity Layer: Enforce Multi-Factor Authentication (MFA) via Entra ID, Duo, or Okta at the VPN or Gateway level. Passwords alone are mathematically obsolete.

The Code & Config

Here is what the firewall rule looks like on an amateurly managed network. Delete this immediately.

# THE BAD WAY (Ransomware Welcome Mat)
# Edge Firewall NAT / Port Forwarding
Rule: 10
Action: ALLOW
Protocol: TCP
Source: ANY (0.0.0.0/0)
Destination Port: 3389
Forward IP: 192.168.10.50 (Internal Terminal Server)

Your edge firewall should simply drop all inbound 3389 traffic.

Inside the network, you must harden the RDP host itself. At a bare minimum, enforce Network Level Authentication (NLA). NLA requires the user to authenticate before the server establishes a full RDP session and allocates memory, completely neutralizing entire classes of pre-auth exploits like BlueKeep.

Run this snippet in an elevated PowerShell prompt to force NLA on your Windows Servers, or push it via Group Policy (GPO):

Wazuh SIEM: A Threat Hunting Toolkit for People Who Hate SIEMs

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

1. Introduction: So You Need a SIEM. My Condolences.

Let's get one thing straight. You're here because someone—a manager, an auditor, or that little voice of dread in your head—told you that you need a Security Information and Event Management (SIEM) system. My condolences. Most SIEMs are expensive, proprietary black boxes designed to do one thing exceptionally well: generate invoices. They are compliance checkboxes, not functional security tools. They drown you in so many false positives that a real attack would look like just another Tuesday.

We're not here to install a "next-gen" magic quadrant leader. We're here to build a data analysis engine.

Why Commercial SIEMs Are (Mostly) Expensive Alert Cannons

The commercial SIEM market is built on a foundation of terrible ideas. The "per-GB-per-day" licensing model is the most fundamentally broken of them all. It actively punishes you for collecting more data, which is the entire point of security monitoring. The more visibility you want, the more it costs, until you inevitably start making compromises, like not logging DNS queries because it'll blow the budget.

Then there's the vendor lock-in. Their detection logic is an opaque, proprietary secret sauce. You can't see it, you can't easily modify it, and you're entirely at the mercy of their release cycle to detect the latest threat. The default configuration is a firehose of useless "Severity: Medium - User logged in" noise, designed to make the dashboard look busy and justify its existence. Alert fatigue isn't a side effect; it's a feature.

Enter Wazuh: The Box of Sharp Parts

Wazuh isn't a polished, shrink-wrapped product. It's a framework, a collection of sharp, powerful parts that you have to assemble yourself. It grew out of the OSSEC HIDS (Host-based Intrusion Detection System) and has been bolted onto the Elastic Stack—or OpenSearch, or whatever they're calling the fork this week. The point is, it's a battle-tested agent-based HIDS connected to a modern, scalable data backend.

The power of Wazuh isn't in the pre-canned dashboard widgets. It's in the absolute, granular control you have over data collection, rule logic, and automated response. It's free, as in beer. Your only cost is the hardware (or cloud bill) and your own time. If you're not willing to invest the time to learn its quirks and tune it properly, stop reading now. Go call your Splunk sales rep and prepare your purchase order. For everyone else, let's build something useful.

2. Architecture: Don't Screw This Up from the Start

Your initial architectural decisions will determine whether this project is a success or a slow, painful failure. Get this part right, and the rest is just tuning.

The Three Horsemen

Wazuh is composed of three primary services. Understand what each one does and its limitations.

Schrödinger's Backup: If You Haven't Tested a Restore, You Don't Have a Backup

Hugo | DevOps | Cybersecurity — Tue, 14 Apr 2026 12:33:03 +0000

Let me introduce you to Schrödinger's Backup: the condition of your corporate data is simultaneously pristine and completely destroyed until you actually attempt a bare-metal restore.

I have sat in entirely too many incident response war rooms where a company gets hit by LockBit or BlackCat. The CEO is panicking, but the IT Director smugly crosses his arms and says, "Don't worry, we use Veeam. We'll just restore from last night."

Ten minutes later, the blood completely drains from the IT Director's face. He realizes that the backup server was joined to the exact same Active Directory domain that just got compromised. The attacker used their stolen Domain Admin credentials to log into the backup repository and encrypted the backups, too.

You didn't have a disaster recovery plan. You just had a really expensive secondary target.

The Mechanics: Destroying the Safety Net

Modern ransomware is not a dumb script that just blindly encrypts C:\Users. It is a human-operated, highly targeted "living off the land" operation.

The absolute first thing a competent threat actor does after escalating privileges is hunt down your safety net. They query Active Directory for servers with "backup", "veeam", "rubrik", or "datto" in the hostname. They log into your hypervisors. They run vssadmin delete shadows /all /quiet to nuke your local Volume Shadow Copies. They log into your network-attached storage (NAS) and format the volume.

Only after they have systematically dismantled your ability to recover do they push the button to encrypt your production environment. If your backup system relies on the same authentication perimeter (Active Directory, shared local admin passwords) as your production system, it will fall the second your domain falls.

The Fix: Immutability and the 3-2-1-1 Rule

The old 3-2-1 backup rule (3 copies, 2 media, 1 offsite) is dead. You need 3-2-1-1: the final "1" stands for Immutable.

Immutable storage is Write-Once-Read-Many (WORM). Once the data is written, it is physically and cryptographically impossible to delete, modify, or encrypt it for a specified retention period. It doesn't matter if the attacker gets Domain Admin. It doesn't matter if the attacker gets the literal AWS root credentials. The storage API will simply reject any delete or modify requests until the timer expires.

The modern Senior Engineer approach is to push your secondary backups to a cloud bucket with strict Object Lock enabled in Compliance Mode.

The Code & Config

Here is how you actually build an immutable vault. This Terraform snippet creates an AWS S3 bucket and locks it down with a 30-day compliance retention policy.

# THE REAL ENGINEER'S WAY (Immutable S3 Storage)
# If an attacker compromises your entire datacenter and AWS keys, 
# they STILL cannot delete these backups for 30 days.

resource "aws_s3_bucket" "immutable_backups" {
  bucket = "corp-airgapped-backups-2026"
}

# 1. Enable Object Lock (Must be done at bucket creation)
resource "aws_s3_bucket_versioning" "backup_versioning" {
  bucket = aws_s3_bucket.immutable_backups.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_object_lock_configuration" "backup_lock" {
  bucket = aws_s3_bucket.immutable_backups.id

Still Running SMBv1? You're Basically Inviting WannaCry to Dinner

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

It is 2026. The fact that I still walk into enterprise environments and see Server Message Block version 1 (SMBv1) enabled on Domain Controllers because the HR department refuses to replace a multifunction Xerox scanner from 2005 is a complete dereliction of duty.

Let me be absolutely clear: SMBv1 is a 30-year-old protocol that was deprecated before most junior sysadmins even graduated high school. Keeping it active on your network isn't a "business requirement," it is gross negligence. If you have SMBv1 running, you are effectively leaving the front door to your datacenter wide open with a neon sign pointing to the servers.

The Mechanics: The EternalBlue Nightmare

To understand why SMBv1 is so lethal, you have to look at EternalBlue (CVE-2017-0144), the exploit that powered the WannaCry and NotPetya global meltdowns.

This isn't a phishing attack that requires a user to click a bad link. It requires absolutely zero user interaction. If SMBv1 is enabled, an attacker (or a self-propagating worm) simply sends a specially crafted, unauthenticated packet to the target's IPC$ share.

Because of a massive vulnerability in how the Windows kernel driver (srv.sys) handles these packets, that single malformed request triggers a buffer overflow. The attacker instantly gains arbitrary code execution at the Ring 0 (SYSTEM) level. They don't just own the machine; they own the kernel. From there, the worm scans the local subnet, finds every other machine listening on TCP 445 with SMBv1 enabled, and infects the entire VLAN in a matter of seconds.

The Fix: Nuke It From Orbit

You do not mitigate SMBv1. You exterminate it.

The Senior Sysadmin approach is to aggressively disable the protocol across every single endpoint and server in the domain. If that legacy 2005 scanner suddenly breaks, good. Tell them to buy a $300 printer from Best Buy. If management absolutely insists that a legacy piece of manufacturing hardware must use SMBv1, you physically isolate that machine on a completely locked-down, air-gapped VLAN with zero routing access to the rest of the corporate network.

The Code & Config

Stop clicking through GUI menus. Here is the exact PowerShell and Group Policy configuration to rip SMBv1 out of your infrastructure permanently.

First, run this on your Windows Servers to kill the service immediately without a reboot:

# THE REAL ENGINEER'S WAY (Kill SMBv1 on Windows Server)

# Check if the protocol is even enabled
Get-SmbServerConfiguration | Select EnableSMB1Protocol

# Terminate it with extreme prejudice
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

Write-Host "SMBv1 Server service terminated." -ForegroundColor Green

To rip the client feature out of Windows 10/11 workstations, use the Optional Features cmdlet:

# Kill SMBv1 Client on Windows Workstations
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Finally, to ensure no rogue machine or helpdesk tech ever turns it back on, you enforce this registry key via Group Policy Object (GPO) applied to the entire domain:

# THE GPO NUKE (Enforce via Group Policy Preferences -> Registry)

Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value Name: SMB1
Value Type: REG_DWORD
Value Data: 0

The 'Domain Admin' Ego Trip: Why Handing Out DA Privileges Guarantees a Ransomware Outbreak

Hugo | DevOps | Cybersecurity — Sat, 11 Apr 2026 12:33:04 +0000

I frequently audit corporate networks where 15 different people are sitting in the Domain Admins group. When I ask the IT Director why the junior helpdesk tech and the database administrator hold the literal keys to the entire Active Directory forest, the answer is always some variation of, "It makes fixing printer permissions easier."

No, it doesn't. It makes you lazy. Handing out Domain Admin (DA) privileges like candy isn't an IT strategy; it's an ego trip for the IT staff and a guaranteed ransomware deployment for the business.

If your helpdesk uses a DA account to log into user workstations, you are actively facilitating your own network's destruction.

The Mechanics: How Mimikatz Eats Your Domain

You don't need to be hacked by a nation-state to lose your domain. An attacker only needs to phish one low-level employee. Let's say Kevin in HR clicks a bad PDF, and an attacker gets a silent, unprivileged reverse shell on his laptop.

Kevin notices his computer is acting sluggish and calls the helpdesk. The lazy helpdesk tech, using their daily driver account which happens to be in the Domain Admins group, RDPs into Kevin's infected workstation to take a look.

The moment that DA account authenticates to the workstation, Windows caches their credentials in the Local Security Authority Subsystem Service (LSASS) process memory.

The attacker, sitting quietly on Kevin's machine, runs a tool like Mimikatz. They scrape the LSASS memory and extract the helpdesk tech's NTLM hash or plain-text password. Because the tech is a DA, the attacker takes that hash, uses Pass-the-Hash to authenticate directly to the Domain Controller, and dumps the NTDS.dit database.

The attacker now owns every password of every user and service account in your company. The domain is dead.

The Fix: Tiered Administration and LAPS

The Senior Sysadmin fix is non-negotiable: The Tiered Administration Model.

Domain Admins (Tier 0) must never log into workstations (Tier 2) or standard application servers (Tier 1). Ever. If a DA account logs into a workstation, that workstation is now effectively a Domain Controller from a risk perspective.

To give your helpdesk the ability to fix Kevin's computer without using a DA account, you implement the Principle of Least Privilege and deploy Microsoft LAPS (Local Administrator Password Solution).

LAPS randomizes the built-in local administrator password on every single workstation in the domain, makes it completely unique, changes it automatically every 30 days, and stores it securely in a hidden Active Directory attribute. When the helpdesk needs to fix a PC, they look up that specific PC's LAPS password, use it, and move on. If the PC is compromised, the attacker only gets a local admin password that is useless on every other machine in the network.

The Code & Config

Deploying LAPS is not hard. It takes 15 minutes of PowerShell on a Domain Controller to stop 90% of lateral movement attacks.

Here is the PowerShell snippet to prepare your Active Directory schema and delegate the correct permissions so your helpdesk can actually read the LAPS passwords without needing Domain Admin rights.

# THE REAL ENGINEER'S WAY (Deploying LAPS via PowerShell)

# 1. Import the LAPS module on your Domain Controller
Import-Module AdmPwd.PS

# 2. Update the AD Schema to include the ms-Mcs-AdmPwd attributes
Update-AdmPwdADSchema

The Open S3 Bucket Epidemic: Why Reading the Manual is Apparently Too Hard

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

Every time a tech company issues a somber press release about a "highly sophisticated, coordinated cyber incident," I immediately assume an intern left an AWS S3 bucket open to the public. Nine times out of ten, I'm right.

There is an epidemic of startups leaking millions of customer passport scans, API keys, and PII because someone couldn't figure out IAM roles and just clicked "Public" so the frontend application could load an image. When your company's crown jewels are exposed to the internet without authentication, you haven't been hacked. You have just successfully hosted a public file share for criminals.

The Mechanics: The Three-Minute Window

Many developers believe that if their bucket name is obscure—something like prod-backup-kyc-docs-xyz123—nobody will ever find it. This is fundamental ignorance of how modern adversaries operate.

Attackers do not guess your bucket names. They use automated bucket stream scanners. They algorithmically monitor AWS IP spaces, passive DNS logs, and Certificate Transparency logs (like Certstream).

The second you provision a new S3 bucket with a public ACL, a Python script running on a bulletproof VPS somewhere evaluates it. The script sends an unauthenticated HTTP GET request. If AWS replies with 200 OK instead of 403 Forbidden, the automated script instantly triggers a recursive download of the entire bucket. Your data is cloned and sitting on a darknet marketplace in under three minutes.

The Fix: Engineering Guardrails

You cannot fix this with compliance training or strongly worded memos. You fix this with hard engineering guardrails at the infrastructure level.

The Senior Cloud Engineer's approach dictates that storage must be private by default, and public access must be explicitly blocked at the AWS Account level. If a frontend application absolutely needs to serve a private file to an authenticated user, you do not make the bucket public. You generate an S3 Pre-Signed URL in your backend code, which grants the user temporary read access to that specific object for exactly 60 seconds.

For anomaly detection, you turn on Amazon Macie to constantly scan your buckets for PII, and GuardDuty to flag anomalous access patterns.

The Code & Config

Here is the Terraform configuration that will eventually result in a class-action lawsuit:

# THE BAD WAY (A Resume Generating Event)
# Making the entire bucket publicly readable because "IAM is confusing"

resource "aws_s3_bucket" "customer_data" {
  bucket = "startup-kyc-documents"
}

resource "aws_s3_bucket_acl" "customer_data_acl" {
  bucket = aws_s3_bucket.customer_data.id
  acl    = "public-read"
}

Here is the DevSecOps-approved Terraform. We deploy the bucket, and we immediately attach an absolute, non-negotiable block on all public access policies and ACLs.

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

resource "aws_s3_bucket" "customer_data" {
  bucket = "startup-kyc-documents"
}

# 1. THE FIX: Slam the door shut on public access
resource "aws_s3_bucket_public_access_block" "secure_bucket" {
  bucket = aws_s3_bucket.customer_data.id

Your VPN is Your Biggest Vulnerability: The Irony of Perimeter Security

Hugo | DevOps | Cybersecurity — Thu, 09 Apr 2026 12:33:04 +0000

There is a dark, painful irony in modern infrastructure: the very appliance you spent $50,000 on to keep the bad guys out is almost certainly the exact door they will use to walk in.

I have lost count of the incident response calls where a company’s entire Active Directory forest was encrypted because the network admin was too terrified of "causing thirty minutes of downtime" to patch their enterprise VPN appliance. The perimeter security model is dead, and relying on it in 2026 is professional negligence.

The Mechanics: The Pre-Auth Webshell

Enterprise VPN appliances—be it Pulse Secure, Fortinet, Palo Alto GlobalProtect, or Cisco AnyConnect—have become the absolute favorite targets for state-sponsored actors and ransomware syndicates alike.

These devices sit directly on the public internet by design. Attackers do not need a phished password or an MFA bypass to compromise them. Instead, they target the unauthenticated pre-login endpoints—the very web interfaces that serve the initial login form to the user.

Using path traversal vulnerabilities or basic buffer overflows on these public-facing interfaces, attackers drop a webshell (often written in Perl or Python) directly onto the appliance's underlying Linux operating system.

Because a VPN appliance inherently requires deep, unrestricted routing access to your core network to function, the attacker now has a persistent, unlogged backdoor. They bypass every firewall rule, IPS, and identity provider you have set up, stepping right over your perimeter defenses.

The Fix: Kill the Perimeter

The Senior Security Engineer's fix is twofold.

First, treat your VPN as a highly hostile zone. You patch it aggressively, immediately, the day a critical CVE drops. "Maintenance windows" are a luxury you do not have when your edge device is bleeding zero-days.

Second, you stop relying on perimeter security entirely and migrate to a Zero Trust Network Access (ZTNA) model. In ZTNA, there is no "trusted internal network." Users do not connect to a VPN gateway and receive a /16 subnet route allowing them to ping whatever they want.

Instead, users authenticate to an identity broker at the edge. The broker verifies their identity and their device's security posture, and then dynamically builds a micro-tunnel to one specific application. If the user's laptop gets compromised, the malware cannot scan your internal subnets because those subnets are mathematically invisible to the client.

The Code & Config

Here is the legacy VPN configuration that assumes anyone with a valid password deserves a map to the kingdom.

# THE BAD WAY (Legacy VPN Configuration)
# "Welcome to the LAN. Please don't scan the Domain Controllers."

# Pushing the entire corporate routing table to the client
push "route 10.0.0.0 255.0.0.0"
push "route 192.168.0.0 255.255.0.0"
push "dhcp-option DNS 10.0.1.10"

Here is what modern Zero Trust Network Access looks like. Before the user is allowed to even see the internal application, the policy engine verifies the device is domain-joined, running EDR, and fully patched.

// THE REAL ENGINEER'S WAY (ZTNA Device Posture Policy)
// The network is assumed hostile. Access is granted per-app, not per-subnet.