DEV Community: Shoban Chiddarth

I did an ettercap MITM Home Lab

Shoban Chiddarth — Mon, 06 Jul 2026 17:15:06 +0000

Introduction

As I've been getting deeper into Cybersecurity and after the Wazuh lab I did a MITM lab using ettercap for ARP Poisoning and Wireshark to capture the traffic and analyse it.

Full write up on GitHub repo.

Demo video: youtu.be/jZ10v4bCBzY

About the lab

I am enrolled in a college course for Cybersecurity and now the course is currently teaching us Penetration Testing. And this exact lab was taught to us in Network Security, a few days ago.

That one was very similar to this one but the network architecture was very different. We were told to connect our laptops to our mobile hotspot (so that we are hacking in a network we own, completely legal) and put one Kali VM in bridged adapter mode.

Now both the host and the Kali VM behave like real network devices talking to the real router (phone). We were told to consider the host as the victim and Kali as the attacker.

And the ettercap command was run in Kali to make the host think Kali is the router and to make the router think Kali is the host, then we were told to generate some traffic on the host, and open that same vulnerable website mentioned in the write up and capture it in wireshark and login. Then after that we were supposed to do the same analysis and sniff out the credentials.

In theory it sounds like it works and it did work for a lot of people using Windows on their host machine but for me, since I use Linux btw, the traffic from the host was just not being seen from Kali even after disabling Cloudflare WARP. I called my teacher and showed him and he said it could be because of some inbuilt security features in Linux.

So I introduced the lab architecture I usually use when working with multiple Virtual Machines because this one is just cleaner and more isolated. And I cloned a Windows VM from my list of base images into the LAN part of the pfSense router and then I did the same thing on Kali with the Windows hosts IP and it worked, the traffic capture and analysis and credential sniffing.

So I thought it will never work with Linux but if you read the write up, I never used Windows anywhere and replaced the Windows VM with Debian Desktop VMs for victims. And it still worked.

Turns out, it will only not work when the Linux host is being ARP poisoned by a bridged VM. When Linux is not the host and a VM on the same network as the attacker, ARP poisoning will work just fine.

Things I learnt from this lab

I learnt about

ARP poisoning
precisely how attackers sniff out passwords over plain HTTP connections
and why exactly ARP snooping is required in enterprises, something I learned while studying for CCNA.

Conclusion

I also documented the remediation steps for individuals, network administrators and website owners to protect themselves from this type of attack. It is in the write up, link above, go read it.

I finished the SIEM Wazuh Home lab

Shoban Chiddarth — Sat, 04 Jul 2026 09:54:02 +0000

Introduction

Continuing from this post, the SIEM Wazuh lab is done.

You can check it out here: GitHub repo

Demo Video

Further reducing the scope

I dropped pfSense as a log source because setting up syslog on network devices was never a requirement for this lab as well as the bigger project I am building. This is something that will be managed by security analysts, and also there is a limitation with that as everything that will hit :514 will be collected under agent 000 so differentiating between network devices that send logs would be another hectic job.

I just decided not to worry about that and set up Wazuh agents on Windows and Debian and did File Integrity Monitoring, sudo to ROOT privilege escalation monitoring, and SSH brute force detection. I also filtered the logs by providing queries, which is the core focus of the lab for the bigger project I am building. For details on all of that, you can check out the GitHub repo I shared earlier.

Now the network architecture would look like this:

Reducing the size of VMs for video recording

I had to reduce the RAM of Kali VM from 12 GB to 4 GB, and Windows from 8 GB to 4 GB. Now if I run all VMs at once without Brave Browser, VSCodium and Obsidian, I would have enough RAM left to run OBS in order to do the demo video and capture it.

Fortunately my PC did not hang and I was able to record it in OBS, edit and render it in Kdenlive for publishing on YouTube. I didn't do any advanced video editing, just basic trimming and merging and then I published it on YouTube (link above).

Future of this project

After submitting all these in the Monday weekly review I am gonna do the exact same thing on AWS using Terraform. Except I won't have a Windows EC2 instance, that is costly and not available for free tier.

In the AWS Hosted lab I plan to set up a web server and make wazuh agent on the webserver monitor the webserver logs as well, and host a vulnerable web application and attack it with Kali. Then the logs for each type of attack will be on Wazuh dashboard, another server will host Wazuh server. And there will be another EC2 which acts as a user's desktop but is not really a desktop.

The reason for hosting the lab in AWS is, we wan't a one click deploy button to spin up the lab from any computer in the world. The core idea of the project is to build on top of a lab. So we need to make the spinning up of the lab as seamless as possible.

After that a chatbot interface making use of Wazuh API to write and query logs can be built and easily integrated into the existing lab.

Conclusion

My first 100% pure Cybersecurity project is done. All other projects I did touched Cybersecurity to some extent, some more and some less. This is the first project that is purely Cybersecurity that I have done. I now understand Cybersecurity deeper than I did earlier. And I will do more.

Day 1 of Cybersecurity

Shoban Chiddarth — Fri, 03 Jul 2026 09:54:28 +0000

Introduction

The title of the blog is clickbait and it is not actually my day 1 of Cybersecurity. I have been using Linux as on my host machine for almost 2 years, I have a lot of experience with network engineering, I am studying for the CCNA exam as well as I did a lot of labs on packet tracer and worked with real life physical network equipment, I have a physical home lab where I run my own DNS server (pi-hole), and I worked a lot with UFW, AWS NACLs and Security Groups, I am also experienced in ssh hardening and server administration, I can secure servers and restrict access only to authorised individuals. I also know VirtualBox very well, including VirtualBox network adapters, inter VM networking, additionally using pfSense as a virtual router to connect multiple VirtualBox networks. I also did some CTFs here and there, some tryhackme and hackthebox labs, used Kali to learn penetration testing basics from PortSwigger academy. And I know Docker very well, and how applications work, I have some experience with backend programming.

So I am not a complete beginner to Cybersecurity. I have been doing a lot of things related to Cybersecurity. But day before yesterday is when I truly started getting deep into Cybersecurity. All my previous work involved some amount of Cybersecurity in it in some ways but this is the first time I started doing a 100% Cybersecurity only project. My college required students in the 7th semester to form a team and submit a project, a research-oriented one instead of an application-oriented one (like the previous semester's Capstone project). My friends Savitha, Srimathi and I formed a team and decided to do SIEM assistant, a chatbot to interface with an existing SIEM solution so that SOC analysts can talk to a chatbot in human language to make it write complex queries and the SOC analyst can review it and execute them right in the chat interface and see the filtered output. This would help save a lot of time for SOC analysts so that they don't have to spend a lot of time writing complex queries in a query language and debugging those queries and can instead focus on investigating the threats.

But to do this I first have to understand Wazuh very well so I decided to do a Cybersecurity home lab in Wazuh, and I started it around day before yesterday evening. This is the first pure Cybersecurity resume worthy standalone project I ever started. I learnt SIEM basics from the internet and got a grip of what Wazuh is all about and decided to do a basic lab fully in Virtualbox with a Wazuh server and some log sources and do some attacks with Kali and generate some logs and analyse them and document it. This blog post is not the technical write up or the build log of that lab but my experience getting into Cybersecurity. For the lab required for the SIEM project, it will be hosted fully in AWS using Terraform because we are showcasing the assistant part in our project so we need a one click deploy for the lab.

Designing the Network Architecture

I initially planned on having different types of log sources. A Windows desktop log source, debian desktop log source, a pfSense firewall log source additionally with IDS/IPS, and a webserver that hosts a as a vulnerable web application as a log source, and DNS server log source. And planned to launch recons and attacks on the network and the webserver and investigate all the logs from Wazuh.

Here is what the initial plan looked like.

I put all the log sources in an internal network, and used a pfSense VM to connect it to the public internet. I chose internal because I wanted it to be isolated from the host, and I didn't choose NAT Network because I wanted control over the router instead of letting VBox manage it for me, since that is a log source.

And I didn't want to put Kali attacker in the same internal network as I didn't want to log Kali's outbound internet access in the corporate SIEM lab for obvious reasons. So I put the Kali VM in another host only ethernet adapter network (here it doesn't matter if it is host only or internal), and connected it to the public internet via another pfSense VM.

And I attached another network adapter to both pfSense VMs and put it in a separate internal network for the point to point link because I will have to set static routing between them so I need predictable stable IP addresses, which is why I didn't set up bridged adapter on the public link for those pfSense VMs to talk directly because if I did those will be assigned via DHCP from my real world router. So for public internet access I set NAT on the WAN interfaces of both pfSense as it didn't really matter at this point, since both pfSense has one for its own LANs and one for the point to point link called OPT1.

I have a lot of VM base images from which I just clone if I need to do a lab with multiple VMs. The base images are pfSense, debian desktops and servers and etc. Every VM in the diagram except for Kali, pfSense and Windows were debian desktops and servers. After cloning all that, I set up the required network adapters on each device and assigned them the right network. Now all that was remaining is the host configuration.

pfSense behaves differently with non LAN adapters

So I booted up the pfSense VMs first and set up the interfaces which was easy enough and set the LAN and WAN adapters appropriately along with DHCP for the LANs, and set static IPs on both the OPT1. Now I tried to ping one pfSense from the other using the IP set in another one's OPT1 but it just didn't work for some reason. I searched about it and only LAN is allowed to do whatever it wants, for OPT1 a separate firewall allow rule has to be set for communication to succeed. Coming from Cisco IOS routers, this was the first obstacle in this whole lab. So I set up the firewall rule and now I was able to ping both pfSense from each other.

So I went ahead and booted up the servers and setup static IP, then I booted up the desktop VMs and checked for connectivity. Then I added static routes to both pfSense and then tried pinging the machines in the LAN from the Kali. It worked fine. By this time it was night so I decided to do the remaining part of the lab, which I thought would be just installing Wazuh server and setting up agents and log sources and doing some attacks and analysing the logs from the Wazuh server, the next day which would be yesterday and I went to sleep thinking it would be over.

The Next Day

Wazuh Installation and Re-installation on Debian server VM

So I booted up the all the VMs and tried to install Wazuh on the medium sized debian server I dedicated for Wazuh. I also made pi-hole resolve wazuh-server.internal to the Wazuh server's IP beforehand. I opened the Wazuh docs quickstart page, copied the command which would download and run the install script, and executed it on the Wazuh server. It said OS not supported and only some Ubuntu, RHEL and Amazon Linux were supported. It told me to pass a flag with the install script to ignore that, and since I thought the debian VM can handle it I did that. So it began the installation and I had to wait for a lot of time as the downloading and installing was slow. After around 80% was done, it aborted the process and removed all the installed components and said the server is not big enough to handle the Wazuh and self deleted itself. So I allocated more resources to that server so that it can handle Wazuh and restarted the installation process.

It said a previous installation exists but the previous time the script clearly said it was removed. And the script said to pass another flag to overwrite the existing installation and I did that but it couldn't overwrite it fully as certain processes and files weren't fully removed earlier and several ports that would be used by the Wazuh server were still being listened on by detached processes. There was no standardized way to completely remove every left over thing. So I decided to purge the entire Wazuh server VM and mind you every install and uninstall commands took a lot of time. So I deleted the entire VM and decided to setup a fresh Ubuntu server that is big enough to handle Wazuh.

Ubuntu static IP issue

So I downloaded the Ubuntu noble ISO which took a lot of time, I waited for it. And after it finished downloading, I installed a base image from which I planned to clone another VM for the Wazuh server so that I don't have to install Ubuntu whenever I need a server VM. The installation also took a lot more time, so I had to wait. By the time the installation was over it was afternoon after my lunch time.

After finishing my lunch I got back to work and tried to set up static IP for the Wazuh server. For debian servers I just had to edit /etc/network/interfaces and put something like

iface eth0 inet static
    address 192.168.1.50
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 1.1.1.1

And then reload the service called networking and boom it works out of the box. But for Ubuntu, I have to edit a complicated yaml file and the syntax is too annoying even one extra indentation would mess up the whole thing but in debian indentation was not an issue. So I copy pasted the yaml values after giving the IP addresses to chatpgpt and making it generate the YAML file and ran sudo netplan apply and it finally worked.

Ubuntu not seeing the whole disk

I tried to install Wazuh server on the bigger Ubuntu VM, and mind you I did allocate enough resources to it so that I can install Wazuh on it and I did tell it to take up the full disk when installing the Ubuntu ISO and I never selected the LVM option. So when I downloaded and executed the install script I had to wait for a lot of time again. And it did the exact same thing it like earlier it finished around 80% of its job and then said the system is not big enough to handle Wazuh and self deleted all the components it installed. What?

So I checked the disk space on the server and it turns out only a small portion of the entire disk is visible to the host OS because by default Ubuntu server wouldn't install it over the entire disk and would just set up a LVM that I have to manually extend to the whole disk. So I did that and restarted the install script. Which again complained about existing installations that I had to pass the overwrite flag again and it took a lot of time to download the packages and when it is supposed to install them it couldn't overwrite again due to left over files and services and detached processes listening on ports. It was not possible to investigate all of that and remove one by one as the scope of this lab is log analysis so I decided to abandon this current installation and restored a snapshot, thankfully I had a snapshot even if I didn't I would have cloned from that Ubuntu base server VM (which I still have to modify to make it take up the entire disk).

And the first thing I did was extend the LVM to take up the whole disk. After that since it was fresh, I downloaded and executed the install script again. Which took a lot of time so I waited. And after a lot of time the server was installed and the username and password were printed on the terminal, so I opened up wazuh-server.internal in the browser from the debian administrative desktop (as it is an internal network) and it worked when I logged in. So finally the server was installed.

Accidental VirtualBox basic mode

Approximately around this time I accidentally clicked on Basic mode in the per VM settings in VirtualBox and that changed the entire VirtualBox manager to basic mode so the clone VM option wasn't there and there was only one network adapter option on each VM and it only had 2 options NAT and Bridged. I was so confused and crashing out trying to find the clone button for 5 entire minutes and I stumbled on the basic/expert setting in per VM setting again and set it to expert and got all my buttons back, I was finally relieved.

Configuring pfSense+Suricata IDS/IPS as a log source

I wanted network monitoring and IDS deployed on the corporate network and I wanted the IDS logs on the Wazuh. So I opened pfSense dashboard, added the Suricata package and set it up to send eve-json logs to the system. Then I set up remote logging in pfSense and made it send logs to Wazuh's IP on port :514. And then on wazuh server I installed rsyslog and made it save whatever comes on :514 to a separate file pfSense.log and edited Wazuh's xml conf to monitor that log file as well.

Now how does Wazuh server know it is pfSense that is sending the logs and no logs are being edited by unauthorized sources before it reaches the server? I don't know. I decided it is not my problem.

And after Suricata and pfSense logging to remote server to was set up I refreshed Wazuh and pfSense did send some logs to the server and it was visible under the agent id 000. So whatever comes to :514 it gets read as agent 000's activity. So no matter how many network devices are set up to remote syslog, it is all under agent id 000. How do we group the logs based on the source and type and classify them? I have decided it is not my problem and in a real organization I would escalate this issue to the senior security analyst as the scope of this lab is to just do some log analysis on Wazuh not configure multiple log sources and aggregate them with precision.

So I went ahead and did a nmap aggressive scan on the entire corp subnet expecting Suricata to log something related to it and after the scan was over I tried to refresh Wazuh dashboard and found out nothing. Why is Suricata not sending nmap scan incident logs to Wazuh server? I don't know. Probably because I haven't configured the exact rules to detect it. I have decided that I don't care to since IDS/IPS configuration is out of the scope of this lab and decided to drop Suricata entirely so that I can spend time on the actual scope of the lab.

I opened the pfSense dashboard and removed the entire Suricata. Now just the regular firewall logs come to Wazuh under agent 000. Which was fine for now and I moved on to installing agents on the remaining hosts.

My PC hanged

I use Linux by the way on my bare metal host machine as my daily driver that is why it was able to support all these VMs so far. Right before I started setting up agents on the hosts my PC just hanged. It was because 8 separate VMs, one windows and one bulky Ubuntu and one Kali, along with Brave browser, obsidian, and vscodium, 3 separate chromium processes were running. I just left my computer and took a break. When I came back it was locked but it was working, so I unlocked it and then stopped Brave, Obsidian and VSCodium. Then I shutdown and purged the webserver as nothing useful was on it. And I shut down the Kali VM and its pfSense. Some RAM was freed. Then the PC was working fine.

pfSense DNS resolve host override subdomain field confusion

I also decided to purge the pi-hole VM and make pfSense resolve domain names without an external server. So I edited the DHCP settings to make pfSense as the DNS server. And then in the host overrides, to add a manually entry to resolve wazuh-server.internal to the Wazuh server's IP address I opened up that setting page in pfSense dashboard and there were 3 options

host name
Domain
IP

In pi-hole GUI there are only 2 fields, FQDN and IP so I thought the first field host name is about the OS host name of the target server and entered the values like

wazuh-server
wazuh-server.internal
10.0.0.4

And then nslookup wazuh-server.internal failed but other public domains were working fine (after the DHCP settings have been reloaded in VMs that use DHCP and in the hosts that have static IP I manually edited it to use pfSense as its DNS server). I found out through the hard way the first field host name is a sub domain field. So currently wazuh-server.wazuh-server.internal is being resolved to 10.0.0.4 and wazuh-server.internal is not even being cared about.

This was really annoying because why would it make me enter the subdomain in a separate field if I am gonna have to make a new entry for another subdomain for the same top level domain? I figured out I was supposed to leave the first field empty if I wanted to resolve the main domain and I did that and finally internal DNS was back to normal.

Reducing the scope of this project

Since the DNS server and web server are gone, we will only be collecting logs from Debian desktop, Windows Desktop, and the firewall. So the new network architecture looks like this.

2 pfSense VMs have 1 GB RAM each, and Wazuh server and Windows have 8 GB RAM each, Debian Desktop has 2 GB RAM and Kali has 8 GB RAM. So in total it is 32 GB RAM if all these VMs operated at maximum capacity but fortunately they won't and I am also going to reduce the RAM of Kali and other things when I do the attacks and ssh brute force on the hosts. And I have to run OBS to record the attacks and logs generation and inspection so it is a big problem for future me.

Originally I planned to do webserver log monitoring and DNS server log monitoring so I can host a vulnerable web application on the webserver and attack it with Kali so I can have those logs in Wazuh too and also I planned to do DNS poisoning and capture logs from pi hole so another investigation can be done. Now due to my host's limitations I will only be doing File Integrity and Registry edit monitoring in windows and default monitoring in debian desktop and the only thing I will be doing with Kali is ssh brute force.

Deploying the agents

Deploying the agents on the hosts was the easy part, I literally had to enter some values in the Wazuh dashboard and I got the commands to copy paste on the host and thankfully it worked out of box in the debian desktop. I tried installing some packages and removing them and it was shown correctly in the Wazuh server and the login and logout details. Thankfully this part worked out of the box.

And I deployed an agent in Windows and did some registry edits and ran notepad as admin and edited some files, including the host files and hoped that it would show up in the Wazuh dashboard but nothing showed up. Turns out I have to install a separate thing on Windows for it to actually send all these data.

By this time it was night so I decided to do rest the next day and just went to sleep.

Conclusion

This is the moment that I realised, this is Cybersecurity. Yes, this. All this. I am a junior and I am having to deal with all of these in my first cybersecurity lab, so I am pretty sure professionals have it 1000 times worse. I have decided this is worth it. I am getting into Cybersecurity.

I also spent a lot of time documenting all these from my memory and made sure I didn't miss anything that happened yesterday because a lot of people that get into Cybersecurity and become a professional don't share their technical struggles. Maybe some on YouTube but I've only heard people say it is hard, I haven't seen anyone show the "why" it is hard publicly like this. I wanted to document it and share so that I can look back at this from the future and think "things were so easy back in the day", and recruiters if they stumble on this, they would know I am a guy that actually does things so I would be hire-able, and also people that are starting fresh could see this and other posts I will make in the future so they can see the reality of getting into Cybersecurity, the technical details part.

I am gonna go ahead and configure the agents in debian and Windows after posting this and do the brute force and log analysis and document that part too. The deadline for this lab is Monday so I do have a lot of time to do that. The deadline exists because we are supposed to show weekly progress report to our college.

Thanks for reading so far and goodbye.

I recently learnt how to setup a NAT instance instead of NAT Gateway in AWS

Shoban Chiddarth — Thu, 25 Jun 2026 10:15:55 +0000

GitHub repo: ShobanChiddarth/nat-instance-aws-terraform

Introduction

AWS NAT Gateway is a solution for letting EC2 instances in private subnets access the internet. Here is how it usually works. Private subnets would have a route table associated that has a default route 0.0.0.0/0 pointed to a NAT gateway that is present in a public subnet (one that has a default route 0.0.0.0/0 pointed to the internet gateway of the VPC).

This way private instances can download and install software updates, pull public Docker images and so on without needing a public IP address. And also the internet would not have a way to access the private EC2 instances. This is similar to setting up Port Address Translation (NAT, masquerading) in on premises networks so that PCs can use the internet without needing a public IP address. This setup is extremely common in home networks.

In this project I am basically replacing the NAT Gateway with another EC2 instance to save costs.

Architecture

For this demo project we have

1 VPC
2 subnets, one public and one private
1 bastion instance in the public subnet
1 NAT instance in the public subnet
2 Private EC2 instances in the private subnet
Route tables, security groups, IGW and all other miscellaneous

The intended traffic flow is, the private EC2 instances will use the NAT instance as their router and the private subnet will have a default route pointing to the NAT instance's ENI. And the NAT instance will do masquerading and communicate with the internet.

The bastion will be used to SSH into the private EC2 instances in order to check for internet connectivity.

NAT Instance config

You can create a regular EC2 instance but make sure to have these configured if you want it to be a NAT instance.

1. `source_dest_check = false`

AWS, by default, blocks traffic that enters or leaves an EC2 instance if the traffic that enters or leaves the instance does not originate from it or is not destined for it. This to prevent EC2 instances from acting like routers. So you must disable this option on the NAT instance.

2. Security Group config

The NAT instance security group must allow the traffic that will be forwarded from private subnets. For simplicity in this demo, all traffic from the VPC CIDR is allowed. And allow all egress traffic (default), and optional bastion config for SSH access. Here is how my NAT instance's SSH group works.

resource "aws_security_group" "nat_instance_sg" {
    name = "nat_instance_sg"
    vpc_id = aws_vpc.NatInstanceDemoVPC.id
    description = "allow everything"

    ingress {
        from_port = 22
        to_port = 22
        protocol = "tcp"
        security_groups = [ aws_security_group.bastion_sg.id ]
    }

    ingress {
        from_port = 0
        to_port = 0
        protocol = "-1"
        cidr_blocks = [ aws_vpc.NatInstanceDemoVPC.cidr_block ]
    }

    egress {
        from_port = 0
        to_port = 0
        protocol = "-1"
        cidr_blocks = [ "0.0.0.0/0" ]
    }
}

3. Route table (of private subnets)

The route table must have a default route that directs all queries to the NAT instance's primary ENI.

resource "aws_route_table" "to_nat_instance" {
    vpc_id = aws_vpc.NatInstanceDemoVPC.id

    route {
        cidr_block = "0.0.0.0/0"
        network_interface_id = aws_instance.nat_instance.primary_network_interface_id
    }

    depends_on = [ aws_eip.nat_instance_eip ]
}

4. `user_data`

This is the most important part of that NAT instance config. The following is the script intended to be put in user_data of the NAT instance.

#!/bin/bash
apt-get update
apt-get upgrade -y

set -eux

export DEBIAN_FRONTEND=noninteractive

echo iptables-persistent iptables-persistent/autosave_v4 boolean true | debconf-set-selections
echo iptables-persistent iptables-persistent/autosave_v6 boolean true | debconf-set-selections

apt-get install -y iptables-persistent

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-nat.conf

PRIMARY_IFACE=$(ip route | awk '/default/ {print $5; exit}')

iptables -t nat -A POSTROUTING -o "$PRIMARY_IFACE" -j MASQUERADE
iptables -A FORWARD -i "$PRIMARY_IFACE" -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -o "$PRIMARY_IFACE" -j ACCEPT

netfilter-persistent save

I got the script from the internet and modified it a little. The script enables IP forwarding and configures iptables masquerading. I would say understanding each command is recommended before using it in production, but for a lab environment the script can be used as-is. However, on modern Linux distributions, nftables may be preferred over legacy iptables configurations.

5. Make sure the NAT instance has an Elastic IP

Assigning an Elastic IP ensures the NAT instance keeps the same public-facing address across stop/start cycles. The NAT functionality itself does not depend on a fixed public IP, but using an EIP avoids unexpected outbound IP changes and makes firewall allowlists, logging, and operational management easier.

Demo

This video is a live demo of test infrastructure created for NAT instance test working and the private EC2 instances are able to access the internet through the public IP of the NAT instance.

Instructions to run it are in the README of the repo linked above.

Cost Calculation

I used calculator.aws for these numbers.

NAT Gateway

$0.045/hour for just existing
$0.045/GB for data processing

So in a month, it would be 0.045*24*30 = $32/month + 0.045 for every GB of data transfer. For illustration assume 300GB data transfer per month. Which means `300*0.045 = $13.5/month.

So in total it would be way more than 32+13.5= $45.5 so definitely more than $50 per month.

NAT Instance

Shared on-demand Linux t3.micro in ap-south-1 => $8.18/Month
8GB gp3 with minimum values for input output (as it won't be modified that much) => $0.73/month => round it up to $1/month as updates and patching will take some IO
EIP for a month = $3.65 USD/month
300 GB of network egress per month would be covered in total network egress bill anyway, there is no per EC2 billing. When using NAT Gateway the data transfer will be billed twice, once when the NAT gateway processes it and once when it leaves AWS.

So in total it will be 8.18+1+3.65 = $12.83/month which means around $15 per month.

Comparison

NAT Gateway	NAT Instance
~$50/month	~$15/month
~$600/year	~$180/month

You are saving $420/year ($35/month), not counting the enormous data processing of high stakes environments and counting it as t3.micro which is what is available for free tier in ap-south-1 so in non-free tier accounts you could use even cheaper EC2 instance types (and different pricing options) given that you manage the NAT instances, patch them regularly, provision according to load and etc.

When NAT Gateway is better

NAT Gateway is a managed service that provides built-in availability within an Availability Zone, automatic scaling, and no patching requirements. A NAT instance is cheaper but introduces operational responsibility and can become a single point of failure if not designed for redundancy.

Conclusion

I have now learnt a cost efficient way to allow EC2 instances in private subnets to access the internet and I will be using this in the upcoming projects (the one I am currently building is telegram proxy server infrastructure for an entire country).

Earlier I ran into the cost problem of NAT Gateways for small college projects when I wanted to let private EC2 instances temporarily access the internet so what I did earlier was I deployed the infra on terraform and immediately deleted the NAT gateway to avoid costs.

Now I won't have to worry about that and I can just deploy another EC2 instance for cheaper rates that acts as a NAT gateway.

Telegram Ban in India has been lifted, for now

Shoban Chiddarth — Tue, 23 Jun 2026 10:34:30 +0000

It is June 23, 15:38 as I am writing this and the Telegram ban on India has been lifted, temporarily. It was supposed to be lifted at today morning 00:00 but it wasn't and I had to use my proxy to access Telegram until around afternoon. Some of my friends were able to use Telegram without proxy or VPN and some couldn't access Telegram without proxy or VPN (all of them are in India).

I say it has been temporarily lifted because there is a NEET exam coming next year so it most probably will be banned again and also governments cannot be trusted, especially Indian government due to the reasons I covered in the previous blog posts of this series. So if India wants to censor the civilians from the internet to restrict the flow of information for whatever reason like they did in Russia and Iraq and even China, India will block access to all Social Media and Telegram for sure.

In which case the public should be prepared to oppose a tyrannical regime's censorship and have ways to freely access the internet and exercise your god given right to freedom of speech in order to expose a corrupt government that exploits its citizens.

I am doing my part by building an infrastructure for Telegram proxy servers that can scale and handle traffic for an entire country. Anyone with an AWS account will be able to get the terraform files from the GitHub repo and then launch a proxy instance in one terraform apply command. If you want to see the development for that live, you can check out the engineering-for-scale branch in the GitHub repo I shared above. In the main branch, the terraform files are configured to launch just one EC2 as a MTProto proxy server.

You still should not be relying on Telegram as your sole communication app. That being said, thanks for reading so far. In the upcoming revision of the Telegram proxy infrastructure that can handle load for an entire country, I have planned to implement Auto Scaling based on CPU, Network Load Balancer, Lambda CRUD app for manually overriding auto scaling instance counts, secrets mounting via EFS, etc. I will publish another post in detail after I finish it.

Deploying a Telegram MTProto Proxy on AWS with Terraform

Shoban Chiddarth — Sat, 20 Jun 2026 17:46:28 +0000

GitHub link: shobanchiddarth/telegram-proxy-server-aws

Introduction

In my previous blog post I talked about using proxy servers for Telegram to bypass censorship. I also said using someone else's proxy server makes you less anonymous as the proxy server admins can easily see your traffic meta data. That is why I created an AWS infrastructure to one-click-deploy your own Telegram MTProto proxy instance in AWS cloud. Here is how it works.

Architecture

When deploying the terraform code to AWS as per the instructions in the GitHub, a new VPC is created in Thailand with one subnet, and one EC2 is launched there. That one EC2 pulls the telegram mtproto proxy zero config container and runs it volume mapped and makes the secrets file accessible to the host. And then the host pulls another docker image of a FastAPI app I wrote (code in the GitHub repo) to serve the proxy connection details (including that secret) and runs it volume mapped and servers it over port 80 while the proxy server is running over port 443.

The architecture has been kept simple because the intended usage is just one group of friends or family. The current configuration is enough to handle that much load. The EC2 instance type is t3.micro which is more than enough for that.

The Proxy Server

MTProto

MTProto is a custom protocol for proxy servers for Telegram. When you host a Telegram proxy server and enter the details of it in a Telegram client, the Telegram client sends all outbound requests to that server, encrypted and obfuscated, instead of to Telegram directly so that any regional restrictions can be bypassed and also it will look like a regular HTTPS website since it is made to run on port 443. ISP, government, and big tech will never know it is a Telegram proxy server as the connection is encrypted.

Region choice explanation

In the GitHub repo of the IaC, region is set to Thailand. This is because it is the closest AWS region to India that is not in a place that could be affected by the recent war and also not China. So that Indian users who connect to it will have low latency, since Telegram is banned in India (currently) there is no point in hosting it in India. If you want to host it anywhere else the GitHub repo linked above has instructions.

Security implications

Port 22 open to internet

Currently, the port 22 of the EC2 is exposed to the public internet. This is generally considered bad practice but it is a temporary measure and also I didn't want to commit my public IP address in a GitHub repo. When you host it, for more security, you can do any of the following

Change the security group rules to allow only your public IP to port 22
Use SSM
Use AWS VPN (it is costly)
Use EC2 Instance Connect from the AWS console (you will have to allow the port to AWS IP ranges)
etc

Depending on your use case, you can choose what is best for you to avoid exposing port 22 to the internet.

Anyone who has the public IP of the EC2 can connect to the Telegram proxy (Port 80 open to the internet)

This is because both port 80 and 443 are open to the entire internet. In port 80, the management container used to expose proxy server connection details (which includes the secret) is running. I created it this way because the intended use for this project is the proxy server will be hosted by one person and will be shared to a small group of people who will keep it private. So if you want to hide the proxy server connection details from anyone who has the public IP then I suggest you don't allow port 80 to the entire internet, and instead allow it to only your public IP address or stop the container entirely and ssh into the machine using any of the above ways and read /data/secret manually and store it and send it to other people manually.

Other issues

Current architecture can't handle enormous load

The EC2 uses t3.micro (as it is in free tier) and there is only one available EC2 instance. And a lot of TCP segments will be sent back and forth per second per user. The current configuration can withstand a few users, like a few friends groups and family members, not entire towns or cities or countries. So don't share the connection details publicly.

The instance runs 24/7

If you don't want the instance to run 24/7 you can shut it down when you don't need it to save costs. Auto scaling groups and load balancing has not been set up since the target usage is a very small group of people. So the complexity is unnecessary. Elastic IP is used instead of associating a public IP address to an EC2 so that even after reboot, the EC2 still gets the same IP address. This way, the clients don't need to be reconfigured.

Cost Calculation

We are going to use calculator.aws to calculate the monthly costs for the current setup. Currently, we will be billed for the following.

EC2 (t3.micro) running 24/7 (actually less than 24/7, as it will be manually shut down sometimes)
EIP for the EC2
EBS for the EC2 (gp3 8GB)
Around 5 GB of internet egress (ingress is free) per month

I entered the details in the AWS cost calculator. Here are the results.

The estimate is $162.84/year. Which is $13.57/month. In India it is ₹1,280.89/month and ₹15,370.71/year. You can check it out here (this link will expire in 1 year, here is the json export in case it does expire).

{
    "Name": "Telegram Proxy Server singular",
    "Total Cost": {
        "monthly": "13.57",
        "upfront": "0.00",
        "12 months": "162.84"
    },
    "Metadata": {
        "Currency": "USD",
        "Locale": "en_US",
        "Created On": "20/06/2026",
        "Legal Disclaimer": "AWS Pricing Calculator provides only an estimate of your AWS fees and doesn't include any taxes that might apply. Your actual fees depend on a variety of factors, including your actual usage of AWS services.",
        "Share Url": "https://calculator.aws/#/estimate?id=ff8e02fad667c558874ab361764f3189427d0c64"
    },
    "Groups": {
        "Services": [
            {
                "Service Name": "Amazon EC2 ",
                "Description": "Proxy Server",
                "Region": "Asia Pacific (Thailand)",
                "Status": "",
                "Service Cost": {
                    "monthly": "9.23",
                    "upfront": "0.00",
                    "12 months": "110.72"
                },
                "Properties": {
                    "Tenancy": "Shared Instances",
                    "Operating system": "Linux",
                    "Workload": "Consistent, Number of instances: 1",
                    "Advance EC2 instance": "t3.micro",
                    "Pricing strategy": "On-Demand Utilization: 24 Hours/Day",
                    "Enable monitoring": "disabled",
                    "DT Inbound: Internet": "5 GB per month",
                    "DT Outbound: Internet": "5 GB per month",
                    "DT Intra-Region:": "0 TB per month"
                }
            },
            {
                "Service Name": "Amazon Elastic Block Store (EBS)",
                "Description": "default attached to EC2",
                "Region": "Asia Pacific (Thailand)",
                "Status": "",
                "Service Cost": {
                    "monthly": "0.69",
                    "upfront": "0.00",
                    "12 months": "8.28"
                },
                "Properties": {
                    "Number of volumes": "1",
                    "Average duration of volume": "730 hours per month",
                    "Storage amount per volume": "8 GB",
                    "Snapshot Frequency": "No snapshot storage",
                    "Provisioning IOPS per volume (gp3)": "3000",
                    "General Purpose SSD (gp3) - Throughput": "125 MBps"
                }
            },
            {
                "Service Name": "Public IPv4 Address",
                "Description": "TProxyVPC",
                "Region": "Asia Pacific (Thailand)",
                "Status": "",
                "Service Cost": {
                    "monthly": "3.65",
                    "upfront": "0.00",
                    "12 months": "43.80"
                },
                "Properties": {
                    "Number of In-use public IPv4 addresses": "1"
                }
            }
        ]
    }
}

This cost estimate is not for free tier accounts.

Step by step process to connect to the proxy server you deployed

Steps to deploy

Check the README of the GitHub repo I linked in the top of this blog.

Steps to connect to the proxy

Visit the public EIP of your EC2 instance in a browser (as the container runs in port 80).
The connection details for MTProto client will be visible.
Follow these steps to enter those details into a Telegram client
You will be able to use Telegram over a proxy

What I normally do for the above mentioned security implications

I deploy it
I open the public IP in a browser
I note down the connection details
I then remove the allow 22 and allow 80 rules from the security groups. By commenting this part in terraform and doing terraform apply again.

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = [ "0.0.0.0/0" ]
  }

Conclusion

I successfully created an AWS Terraform project for one click deploying a singular Telegram MTProto proxy server. I did this out of necessity, as government is banning Telegram currently in my area. Telegram is a private messaging app not owned by the government or Mark Zuckerberg and that is why they are trying as much as they can to stop people from using it, I already covered this in my previous blog post.

Now with this repo, anyone in the world can deploy a proxy server for Telegram easily and help their friends who are being censored from the internet. Right now this cannot handle massive load as I have mentioned above but I plan to improve this architecture in the near future by using auto scaling groups and AWS Network Load Balancer (load balance per TCP connection) between the proxy servers, bastion based SSH management, and lambda based manual scheduling and starting and stopping of servers, and the NLB DNS name will be used as the hostname in Telegram clients. But this is enough for a few number of people.

How to circumvent the Telegram ban in India

Shoban Chiddarth — Wed, 17 Jun 2026 08:17:18 +0000

Introduction

The Indian government has banned Telegram, a secure and private messaging app not owned by Mark Zuckerberg nor controlled by the Indian government for a week, from June 16 to June 22. The reasons they stated are someone used Telegram to leak the NEET-UG exam papers.

Source:

https://www.bbc.com/news/articles/cn074j04l3eo

The leaks have moved over to other apps and the 150 million (15 crores) civilians who use Telegram as a messaging service so that they can have privacy from the spying eyes of Meta and government are punished instead.

This is what the IFF (Internet Freedom Foundation) had to say regarding the ban:

In case you are not able to view the tweets I have copy pasted them below

IFF Tweet: Statement : Shutting down Telegram is a band aid solution and is a disproportionate answer to exam fraud

The Internet Freedom Foundation objects to the directions announced today in the National Testing Agency's press release on action against the Telegram platform. On the NTA's istry of Electronics and Information Technology has, under Section 69A of the Information Technology Act, 2000, restricted access to the whole of Telegram in India until 22 June 2026, and has separately ordered the platform to switch off message-editing for every Indian user until 30 June 2026. This is a blunt, nationwide measure aimed at the conduct of rampant fraud rackets, and on the Government's own admission is constitutionally incompatible.

At the outset it is important to note that Section 69A and the Blocking Rules of 2009 framed under it allow the Government to block access to specific “information” on a computer resource. They do not extend to switching off an entire intermediary, still less to ordering a company to redesign its product by removing a feature for a whole country. In Shreya Singhal v Union of India, the Supreme Court upheld Section 69A because it is narrow and hedged with procedural safeguards. Reading it to authorise shutting down a platform that lakhs use is an overbroad restriction by the NTAs own admission. For the message-editing direction the release identifies no source of power at all. If one exists, the order must say so.

The release argues against itself

A restriction on access has to be the least intrusive measure that achieves its aim as per the constitutional test of proportionality laid down in Justice K.S. Puttaswamy v. Union of India (2017) and applied in Anuradha Bhasin v. Union of India (2020). The NTA's own narration shows the block fails its nodal agency, the release says, “has secured the prompt take-down of a substantial number of Telegram channels, groups and bots”, and this targeted work “is the reason the harm caused by these rackets has been contained to the extent it has”. If channel level takedown contained the harm, the case for a blanket block collapses and hence the Government has reached for a heavier tool while conceding that a lighter one was working. The collateral cost sits on the record too as noted in the press release. The block, the NTA accepts, “affects lakhs of citizens who use the Telegram platform for legitimate personal, educational, professional and informational purposes”. The release also says there is "no such paper available outside the secured examination chain" and that “the security of the examination is unaffected by the action taken”. If the exam is secure and no leak exists, what is being suppressed is rumour, and rumour cannot justify closing a platform when specific blocking and criminal prosecution remain available.

Students use of Telegram

The block of telegram is reactive and ineffective and will punish ordinary users instead of addressing the systemic source of exam leaks. This blocking comes in the final days of NEET preparation, when thousands of students depend on Telegram for study groups, doubt-clearing, and shared resources. Also, it is important to consider that the source of exam papers leak will occur from inside the system, among insiders and across the printing and logistics chain, with the platform being the most downstream channel for distribution. Hence, switching off Telegram, is merely a deflection from the repeated failures that will continue while media attention is directed towards this Telegram ban.

Lack of transparency

At present only a press release from the NTA has been provided, which recommended the block but the reasoned order of MeitY, the authority that issued it, has not been released. The Anuradha Bhasin decision requires that orders restricting access be published so they can be tested in court. Here the order, and the reasoning of the committee behind it, stay out of view, and we do not know whether Telegram was heard at all. An announcement of a block is no substitute for an order the affected party can challenge.
Blunt to enforce and very easy to evade
Usually, app-level blocks run through IS-level DNS and IP filtering. They are over inclusive, sweeping in lawful use, yet simple to evade as a determined exam leak racket moves to a VPN or a mirror within minutes while ordinary users lose the service for a week.

We ask the Government to:

1) Publish the MeitY Section 69A order and the NTA recommendation behind it, with reasons;
2) State the legal basis for the message editing direction, or withdraw it;
3) Confirm whether Telegram was given a hearing under the Blocking Rules, and place the committee's record before any court that hears a challenge; and
4) Lift the platform-wide restriction and rely on the targeted takedowns the NTA itself credits with containing the harm.

We emphasise that the NEET (UG) 2026 re-examination is worth protecting and it concerns the future of lakhs of aspirants. It requires securing the entire process of examination rather than reaching for purported band aid solutions that instead cause more harm. The State cannot switch off a service used by lakhs to answer the wrongdoing of a few, and cannot do it through an order no one affected is allowed to read. On its own facts, the Government has done both.

New Delhi, 16 June 2026.

Images attached:

IFF Video: Banning Telegram won't fix a broken examination system.

// Detect dark theme var iframe = document.getElementById('tweet-2066864224966738196-656'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2066864224966738196&theme=dark" }

How to circumvent the ban

The government argues they are shutting down Telegram to stop the spread of leaked exam papers and the people involved in the illegal stuff have already found ways to circumvent it and move to other apps, so why shouldn't you, a law abiding citizen not have as much freedom as the criminals? Assuming you are a regular law abiding civilian who is dependent on Telegram for communicating with other people and you don't want the government or Meta to look at your private messages, here are the ways you can circumvent the ban.

1. Use a VPN

Any VPN app that lets you connect to a VPN server in a different country will do. I recommend Proton VPN because you don't even have to sign up for an account and still get unlimited data. I am using it right now to access Telegram, without a Proton VPN account, and it works. Download the Proton VPN app, and then connect the VPN, and open Telegram.

https://protonvpn.com/

2. Use a Telegram Proxy

In case the government also banned VPNs or you are not able to use a VPN for any reason, you can use a proxy for Telegram. Here is how to add a proxy.

And here are a bunch of public proxy servers ready to use : https://mtpro.xyz/mtproto

There are more and you can find them easily on Google. Just note that using a proxy makes you less private as the proxy server admins can easily see your traffic meta data and etc, I will publish another blog on how to run your own Telegram proxy server. Until then, proton VPN and cloudflare WARP is free to use.

3. Cloudflare WARP

Even if you are in India, Cloudflare WARP can circumvent Telegram ban. It is a VPN like app that routes your traffic through Cloudflare servers.

Download it here: https://one.one.one.one/

Conclusion

This is an action directly targeted to remove privacy and freedom of the Indian people step by step.

This is not the first time Indian authorities have reached for a blunt instrument over a narrow problem. Access Now's #KeepItOn coalition has tracked 771 government-ordered internet shutdowns in India between 2016 and 2023, more than any other country in the world, for five consecutive years running. Jammu and Kashmir alone endured a 552-day blackout starting in August 2019, the longest internet shutdown ever recorded anywhere. The stated justification has shifted each time, protests, communal violence, exams, unrest, but the underlying pattern repeats: a blunt, platform-wide or region-wide shutdown standing in for narrower, targeted enforcement.

It has also gone beyond blocking apps. Jammu and Kashmir has criminalized the circumvention tools themselves, banning unauthorized VPN use under Section 163 of the Bharatiya Nagarik Suraksha Sanhita. Around 800 people have already been penalized through phone searches for using banned applications.

Telegram is being switched off this week over exam fraud. The justification will be different next time. The willingness to reach for this tool, and the tools themselves, have already been demonstrated repeatedly. People should understand how VPNs, proxies, and circumvention work before they need them, not after. The Indian government is your enemy and cannot be trusted. They previously planned on banning the entire proton suite because someone sent a fake bomb threat using a proton mail address (which I suspect is an inside job from the government to make up an excuse to ban proton in order to reduce people's freedom and privacy) and also any VPN server running in India is legally required to store logs and share them with the government, which is one of the reasons ProtonVPN moved away from India.

Sources:

Reliance also tried to block Telegram outside of India, more on that in the next blog.

On Age Verification

Shoban Chiddarth — Wed, 27 May 2026 02:09:33 +0000

Introduction

If you have been living under a rock (good for you), several states in America and the country of Brazil have introduced a new law that forces operating system developers to implement "age attestation" of the user, you will have to provide your age and then an age bracket will be stored which will be broadcast to every app and service you use in your operating system, and app stores (apt sources) are required to acknowledge this and filter software based on age, and assume lowest age bracket if the age is not given.

Age verification tracker: https://github.com/BryanLunduke/DoesItAgeVerify/ (fork that maintains links to original developer statements: https://github.com/softcookiepp/DoesItAgeVerify). This has all information regarding it.

In this blog post, I will share my opinions on it and explain why it is impossible to enforce these laws as well as impossible to comply with these laws. It is actually illegal to follow the US law according to the US law, I will explain below.

Facebook

Meta is behind this. Meta is pulling the strings and getting the law makers to pass such laws. Here is the proof:

Since Mark Zuckerberg is the mastermind behind all these, and due to how trustworthy he is

it is logical to expect the very next step from the lawmakers is to make you upload your government issued ID photo to the operating system before setting up the account. So that every action you take in the computer, every local text file you save, every message you send in end to end encrypted messaging apps, every local file you save, every email you send by gpg encrypting it, every social media post you make from an anonymous account, can be pinpointed to who exactly you are and your location, so that the government can keep a social credit score for people and arrest anyone that disagrees with the government and enforce a totalitarian regime like 1984 or present day China.

This is their plan. It is a slippery slope. It is Facebook after all. Now they push for "age attestation" which is "just a minor thing" according to some people and after it is accepted as a "usual thing" they push for a little more like precise age numbers and then you end up with ID.

Linux

The law keeps definitions of "Operating System", "User", "Account" as vague as possible to enforce it into as many places as possible. And anyone with a functioning mind would think the entire Linux community, built around privacy and security, would be vehemently opposed to this law and refuse to follow it and try as much as possible to get this law deleted. But that is where you are wrong. At least most of the people, the users, are against the law.

Ubuntu will comply and Debian will help downstream distros implement it (it is in the tracker). And Arch Linux, an OS literally made to give you full control over your computer, says opposing age verification is violation of code of conduct. There is more on Lunduke's (the only journalist covering these kinds of tech news you wouldn't find on mainstream media) channel. And also systemd, an init process that is supposed to start the system, has a module called userdb and it previously stored a lot of PII like name and email and now it stores user birthdate to comply with the law so that xdg-desktop-portal can use it as a reference to implement the age attestation (PR link). And also linux reddit censors age verification related posts.

systemd

When I started out with Linux I did not understand the hate around systemd. I thought it was just a normal piece of software with unnecessary drama and also it worked kinda fine like it took care of things and was programmable so I didn't understand why people did not like it and moved away from it. But now I do. It is owned by RedHat and is extremely bloated and does things it is not required to do for no reason at all. I hated it more and more as I was going deeper into computers and Linux. It has a local DNS middleman server for god knows why the system needs another middleman when I run my own DNS server. I had to configure a lot of things to make sure the systemd-resolved stays shut down. An init process storing user PII, and modifying it to comply with privacy invasive freedom restricting laws, and resolving DNS, managing IP addresses of network interfaces (systemd-networkd) is too much for an init process, it increases the attack surface and adds too much unnecessary bloat to the system.

Distro hopping

The only developers who oppose this law are listed in the tracker I shared above. I personally use Linux Mint and Mint is currently not affected by systemd storing user birthdate because Mint does not ship with systemd-userdbd (Source) so even if upstream software like xdg-desktop-portal implement it, it will have no point of reference for the user birthdate. However, that is only true for the current state of the OS (22.3 zena). The developers of Mint have not made any public statements regarding age verification and assuming the worst, if they implement age verification by shipping the next update with systemd-userdbd or in some other way, I can simply refuse the dist upgrade. Also I am currently refusing all updates to systemd related packages using this command.

sudo apt-mark hold *systemd*

So the dist upgrades have been refused and systemd related packages have been held back from updating, meaning I have a lot of time to switch to an operating system that publicly opposes age verification as well as does not have systemd. I am choosing to go with Artix (Arch without systemd) for my laptop as it gives full control over my computer, and Devuan (Debian without systemd) for my server for stability. If you are using a Linux distro that is going to implement age verification like Ubuntu or Fedora consult the above tracker to make a decision on the OS that fits your needs and opposes age verification and does not have systemd and switch to it as quick as possible. If you are using Windows switch to Linux, it is a corporate controlled proprietary OS and they already do a lot of spying on you and also Zuckerberg, Bill Gates are all a part of the Epstein class and they are all in this together.

Why is it impossible to enforce this law?

Obviously, Linux is open source and if the OS adds age verification, someone will just fork it and create a "libre" version that doesn't have it. And good luck to government jarheads trying to arrest everyone, you won't have enough room in prison.

Why is it impossible to comply with this law?

Even if every single person in America is willing to comply with this law, it is literally impossible. The law is very very vague about the definitions of an Operating System, an Account, and a User. So almost everything that is technically a "computer" falls into this law. And almost everything that is a computer (that probably runs linux) includes your laptop and desktop and servers (obviously), your smart TV, your smart watch, your calculator (probably), your "smart" washing machine, fridge, dishwasher and other smart devices, your robot vacuum cleaner, your router, raspberry pis that are part of iot devices, any and all forms of iot devices, your CCTV cameras, your baby and dog monitor, believe it or not switches (the layer 2 network devices) are also technically a computer because they have an OS (Cisco IOS), Nintendo Switch console, the gas station pump, your car probably, the bar code scanner at Walmart, traffic signals, public surveillance cameras, your smoke detector, and a lot of things, the list is so long that it cannot be fit in this blog post.

If everyone in America wanted to comply with the law by entering their age into all "computers" they own, the entire internet will break, several people will die, and a lot of things will be broken. So many things in this world are computers.

Right to Repair

Also it is illegal to comply with this law. DMCA Law in the US states that you are not allowed to use technical skills to circumvent DRM on a device (you are legally not allowed to modify a device you own and paid money for) or to "hack" it to run whatever software you want. You could face 5 years in jail or $500,000 fine for changing the electric circuits of a physical device you purchased with money and own in your hand.

Nintendo used this law to sue people breaking into Nintendo Switch (the gaming console) to run custom software. BMW implemented subscription based heated seat, using electricity from the battery of the car that you paid for, generated by the fuel you paid for, which costs the company $0 to produce some heat yet they charge users monthly for it. And it is backed by the law, if you circumvent it to have unlimited heated seat then you go to jail. And Tesla implemented a pay walled battery, you have to pay money to use 100% of the battery that you own. BMW is a horrible company by the way they patented BMW screws that can only be purchased from their vendors to make sure you always come to them for repairs and don't repair on your own, that is a completely different story but America is slowly becoming this corpo owned hell hole.
Sources:

Coming back to what I was saying, it is illegal to open up your robot vacuum cleaner and flash a custom operating system into it, in the place where the current linux distro of it is running, by somehow wiring it up with a keyboard mouse and display. So you are not allowed to do it or you face prison. But the age verification law says you are required to enter your age into all "computers" you own and the only way to enter it into your robot vacuum cleaner is to circumvent its DRM by breaking it open, which is illegal. (this applies to not just robot vacuum cleaners).

America has finally made it. It is illegal to follow the law. Welcome to land of the free baby, where you are legally not allowed to modify devices you paid money to own and cannot have anonymity and privacy.

Louis Rossmann (the man behind the clippy movement) has been shouting about the "Right to Repair" for a very long time. Please pay attention to that one: https://www.youtube.com/@rossmanngroup/videos and https://consumerrights.wiki/w/Main_Page

Cloud is up there above us

And almost nobody on the internet has covered the cloud side of things related to age verification.

Docker containers are also technically a computer since it is an OS (alpine mostly). Are people required to enter their age inside docker containers too? Are you only required to enter your age when pushing a docker container to the internet or whenever creating it like dev or testing? What about Virtual Machines? Amazon Web Services offer an OS called "Amazon Linux" so they are also operating system developers. So by law they are required to implement age attestation in their OS, I am not sure what they are gonna do about it.

AWS is the biggest cloud provider where majority of production infrastructure lives. Since the law requires every "user" that has an "account" on every "computer" to enter their age, will Jeff Bezos be required to enter his age into every single EC2 instance created in American regions?

Even if he is willing to, let's assume it takes Jeff Bezos 3 seconds to enter his age into 1 EC2 instance (type 2 numbers + enter key + window switching). So that is 86,400/3=28,800. He will be entering his age into 28,800 EC2 instances per day which is a frighteningly low amount of EC2 instances compared to how much actually exist and is being created every day, assuming he is willing to work 24 hours.

Most of the real production infra does not have EC2 instances manually created and provisioned from the console, they are all automated using tools like Terraform. And 28,800 EC2 instances does not count the several internal "technically a computer" servers that are used for things like lambda, ECS, Fargate, EKS and there is still a ton more including other cloud providers, on prem data centers many companies use, and also the on prem network devices (like switches and routers I mentioned above). Now you see why the entire internet will break, it is impossible for the owner of the "computer" to enter their age into every "computer" they own due to the laws of physics.

The law is extremely vague about the definitions either because lawmakers are stupid and think cloud means where we get the rain from or they are evil and want to strip away as much people's rights as possible and I don't know which is worse or it could be both.

Why should someone in India (me, and you, even if you are not in India) care about some American law?

Brazil is a country that is not America yet Facebook pulled strings and got the law passed over there. India is next. Indian government isn't exactly pro consumer rights or pro privacy, law requires VPN services to store logs and share them with the government, that is why ProtonVPN moved away from India. And there were talks about the government banning entire Proton suite from India because some idiot sent a fake bomb threat somewhere using proton email address and they were not able to find him. Call me paranoid but I think the someone is the government making up reasons to ban proton mail.

And even if the law hypothetically never comes to India, if I am using Ubuntu (thankfully I am not) and Ubuntu pushes an update on the day the law takes effect forcing me to enter my age or else lock my drive, I will have no choice but to either comply with the law (which is bad and is a slippery slope like I said above) or to mount the hard drive, somewhere else, copy the files, and reinstall another OS that doesn't have age verification which will be tedious to do after the law has been implemented, hopping to another distro now is easy. This is the same as disaster recovery in Cloud Computing, we don't wait until disaster happens to recover resources, we plan in advance and provision multi AZ or multi region so if disaster affects on AZ or an entire country we would still have other areas up and running.

Here's what you are gonna do

Get as many normies to switch to Linux
Tell everyone you know about age verification
Increase awareness about the importance of privacy, anonymity, security, and right to repair
If someone already uses Linux, get them to switch to an OS that doesn't support age verification (see tracker)

Documenting my Physical Home lab in Packet Tracer

Shoban Chiddarth — Tue, 05 May 2026 17:09:00 +0000

Repo link: github.com/ShobanChiddarth/physical-homelab-in-packet-tracer

Introduction

I recently finished my 3rd year end sem exams and I am in my summer holidays. I am preparing for the CCNA certification so I decided to recreate my physical home lab in Cisco Packet Tracer.

To download the packet tracer lab file you can visit the GitHub repo linked in the top of this post and look at the README.

Technical Details

Setup

I used a WRT300N router to simulate the Tenda AC6 router, and a 1941 (non wireless) router to simulate the Jio Fiber router. I did not need to connect any wireless devices to the Jio router in this packet tracer lab and also in Packet tracer connecting the WAN port (Internet port) of a wireless router to the LAN port of another wireless router wouldn't work like in real life, it refuses to form a connection. So I went with static IPs for the Jio Router's LAN port and Tenda Router's WAN port.

Devices inside Tenda router's LAN

As shown in the previous entries of this series, there is a ThinkCenter M81 (represented by Server PT) connected through ethernet to the Tenda router, in which HTTP and DNS services have been enabled (Pi-hole). And my laptop and my smartphone are connected over Wi-Fi to the Tenda router.

Devices outside Tenda router's LAN (inside Jio router's LAN)

We will not be worrying about this part as I do not control the Jio router and guests and other family members will be using it. There are mobile phones and a TV connected to it. There was a smart vaccum cleaner connected to it long ago like in the same Jio LAN without any isolation and it stopped working but if I was in charge of managing the network I would have set up proper isolation for IOT devices like this one by putting them on a separate VLAN, setting up guest network and blocking them from communicating with other devices using ACLs.

Internet Access

Real internet is not possible inside Cisco Packet tracer so assume the cloud up above is the real internet.

IP Configuration

IP configuration is the exact same as my lab in real life

Jio LAN = 192.168.29.1/24
Tenda WAN = DHCP
Tenda LAN = 192.168.1.1/24
ThinkCenter M81 (Pi-hole) = 192.168.1.2
My Laptop = DHCP
My Phone = DHCP

Screenshots

Full Lab

Pi-hole DNS records

Pinging ThinkCenter M81 from My Laptop

Accessing Pi-hole dashboard from My Laptop

I edited the default index.html in HTTP server a little bit, this is not an actual computer so installing Pi-hole is not possible. The DNS resolution works that is what is important.

Accessing Pi-hole dashboard from My Phone

Conclusion

Therefore I successfully created a simulation of my real home lab inside Packet Tracer. I am currently preparing for CCNA certification and this packet tracer lab has helped me map a network whose behaviour I already know onto Packet Tracer's environment. When you build a network from scratch in a simulator, you have no reference point, but when you recreate something you physically own, you immediately notice where the simulator behaves differently from reality and understand its limitations, and that gap is where the actual learning happens.

AWS Terraform infrastructure for a FastAPI+PostgreSQL backend

Shoban Chiddarth — Mon, 23 Mar 2026 14:47:31 +0000

Introduction

This blog post showcases the AWS infrastructure written in Terraform for the backend of alumni-connect, a MVP of a college project written in FastAPI with a PostgreSQL database.

The terraform repo: https://github.com/ShobanChiddarth/alumni-connect-terraform
The backend repo: https://github.com/ShobanChiddarth/alumni-connect-backend

Architecture

VPC Design

Since this is an MVP, I went with the absolute minimal for everything. 1 VPC exists on ap-south-1. It has an internet gateway. Frontend is hosted in netlify, so API requests as well as management traffic (SSH) will enter through the internet gateway.

Subnet Design

There are 4 subnets in total.

A public subnet to handle management traffic (ap-south-1a)
2 private subnets for backend and database EC2 instances (ap-south-1a)
Another public subnet to satisfy AWS's hard requirement of multi AZ for load balancers (ap-south-1b)

The management subnet:

Contains the bastion EC2
Contains a NAT gateway for EC2 instances in the private subnet to reach the internet

Load Balancer

The backend EC2 has no public IP and sits in a private subnet. Its security group only accepts port 8000 from the ALB security group - there is no direct path from the internet to the backend. The ALB is the only entry point.

listens on port 80 for HTTP traffic from the public internet
spans across ap-south-1a (management subnet) and ap-south-1b (empty subnet) - AWS requires an internet-facing ALB to span at least 2 AZs
forwards the traffic from the internet to port 8000 in the backend EC2

Security Groups Design

SSH traffic from the internet is allowed only to the bastion EC2
SSH traffic to the backend and database EC2s are allowed only from the bastion EC2
HTTP traffic from the internet is allowed only to the load balancer
HTTP traffic to the backend is allowed only from the load balancer
Database traffic (port 5432) to the database EC2 is allowed only from the backend EC2

SSH Keys

Bastion EC2's SSH private key stays on the local computer of the person deploying this
Other EC2s SSH private key stays in the bastion

EC2 instances

Backend EC2 is set to pull and run docker image shobanchiddarth/alumni-connect-backend:0.0.2
Database EC2 is set to pull and run docker image postgres:16

NAT Gateway Cost Problem

I wrote a LinkedIn post about this. Click here to view it.

If you are not able to see it, here are the contents of the post:

I recently faced a problem with making EC2 instances communicate with the internet while deploying a FastAPI+Postgres backend architecture on AWS using Terraform. NAT Gateways exist to solve this - a NAT gateway can be placed in a public subnet and traffic can be routed through it.

But NAT Gateways are costly. ~$0.045/hr just to exist, plus data transfer charges.

The solution I used: keep the NAT gateway in the Terraform code, but destroy it immediately after deployment. Private instances lose internet access after packages are updated, Docker images are pulled, and containers are running.

terraform destroy -target=aws_nat_gateway.alumni-nat-gw -target=aws_eip.nat-gateway-elastic-ip

I also tried a NAT instance - an EC2 that acts as a router - but ran into configuration issues getting it to actually forward traffic. Ended up not going down that path for this project.

This temporary NAT gateway approach is good enough for a college project MVP with almost no users that gets destroyed in a few hours anyway.

Has anyone dealt with this in production? Is there a cleaner pattern for private subnet internet access beyond NAT gateway or NAT instance?

#Terraform #AWS #VPC #CloudComputing #IaC #CloudCost

Steps to Deploy

Clone the repo

git clone https://github.com/ShobanChiddarth/alumni-connect-terraform
cd alumni-connect-terraform/infrastructure

Set AWS credentials

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

Set the database password
```
export TF_VAR_db_password="..."
```
Deploy
```
terraform init
terraform apply
```

Destroy the NAT gateway after apply

terraform destroy \
 -target=aws_nat_gateway.alumni-nat-gw \
 -target=aws_eip.nat-gateway-elastic-ip

To tear down everything:

terraform destroy

Proof of Deployment

These are screenshots I took when it was live. I then destroyed the whole infrastructure.

I archived the API landing URL (first image) in Wayback Machine. Here is the link: https://web.archive.org/web/20260322130840/http://alumni-alb-backend-83642402.ap-south-1.elb.amazonaws.com/

Conclusion

This is the full Terraform infrastructure for the alumni-connect backend.

IAM Development Lab in Keycloak

Shoban Chiddarth — Fri, 20 Mar 2026 17:17:13 +0000

Introduction

This is the ultimate IAM development and employee lifecycle management lab I am doing where I will be making use of the skills I learnt from the TATA virtual internship via Forage: Cybersecurity Analyst - IAM Developer to develop and implement an IAM solution for a fictional organization.

I chose Keycloak for this lab instead of SailPoint with Oracle Identity Manager because Keycloak is fully open source. This is a standalone lab independent of OpenLDAP.

The internship covered

IAM fundamentals
Digital identity
Authentication
Authorization
SSO
least privilege principle And then walked through designing and planning a full IAM implementation for a fictional enterprise called TechCorp (but the fictional org we will be representing is called Acme). The proposed solution used
SailPoint for automated user lifecycle management and
Oracle Identity Manager for RBAC with a four-phase implementation plan covering deployment, testing, training, and ongoing monitoring.

This lab takes those same requirements and implements them end-to-end:

A structured org with departments and roles
RBAC enforced at the role level
Full user lifecycle management from provisioning to offboarding
MFA
SSO via OIDC
Email-based verification flows
Brute force protection
Audit logging All running on-premises in VirtualBox with no external dependencies. ## Pre-Requisites

Build Log

Keycloak Server Initialization

I cloned a debian server VM, put it in the current VirtualBox host only network I have, assigned a static IP (192.168.57.8), Then I edited its hostname, and mapped DNS record keycloak.acme.internal -> 192.168.57.8 in Pi-Hole.

debian@keycloak:~$ sudo ifconfig enp0s3
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.57.8  netmask 255.255.255.0  broadcast 192.168.57.255
        inet6 fe80::43b5:ca52:a96d:134a  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:8a:4a:29  txqueuelen 1000  (Ethernet)
        RX packets 28569  bytes 3772704 (3.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28550  bytes 2712767 (2.5 MiB)
        TX errors 0  dropped 2 overruns 0  carrier 0  collisions 0

debian@keycloak:~$ nslookup keycloak.acme.internal
Server:     192.168.57.3
Address:    192.168.57.3#53

Name:   keycloak.acme.internal
Address: 192.168.57.8

debian@keycloak:~$

Then I installed java on it because Keycloak requires it.

sudo apt install default-jre -y

Java version 21 btw

debian@keycloak:~$ java --version
openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)

Then I downloaded Keycloak from GitHub, extracted it and put it in /opt

debian@keycloak:~/Downloads$ ls
keycloak-26.5.6.tar.gz
debian@keycloak:~/Downloads$ tar -xzf keycloak-26.5.6.tar.gz 
debian@keycloak:~/Downloads$ ls
keycloak-26.5.6  keycloak-26.5.6.tar.gz
debian@keycloak:~/Downloads$ sudo mv keycloak-26.5.6 /opt/keycloak
debian@keycloak:~/Downloads$ cd /opt
debian@keycloak:/opt$ ls
keycloak
debian@keycloak:/opt$

And created a new user and set appropriate permissions.

sudo useradd -r -s /sbin/nologin keycloak
sudo chown -R keycloak:keycloak /opt/keycloak

Local CA certificates for Keycloak

I did the usual, created certs for keycloak.acme.internal and moved them to the Keycloak server and pointed Keycloak to it.

debian@keycloak:~/acme-certs$ ls
keycloak.acme.internal-key.pem  keycloak.acme.internal.pem
debian@keycloak:~/acme-certs$ sudo mkdir -p /opt/keycloak/conf/certs
debian@keycloak:~/acme-certs$ sudo cp keycloak.acme.internal.pem /opt/keycloak/conf/certs/keycloak.crt
debian@keycloak:~/acme-certs$ sudo cp keycloak.acme.internal-key.pem /opt/keycloak/conf/certs/keycloak.key
debian@keycloak:~/acme-certs$ sudo chown -R keycloak:keycloak /opt/keycloak/conf/certs
debian@keycloak:~/acme-certs$ sudo chmod 640 /opt/keycloak/conf/certs/keycloak.key
debian@keycloak:~/acme-certs$ sudo nano /opt/keycloak/conf/keycloak.conf 
debian@keycloak:~/acme-certs$ cat /opt/keycloak/conf/
cache-ispn.xml  certs/          keycloak.conf   README.md       truststores/    
debian@keycloak:~/acme-certs$ cat /opt/keycloak/conf/keycloak.conf | head -5
hostname=keycloak.acme.internal
https-certificate-file=/opt/keycloak/conf/certs/keycloak.crt
https-certificate-key-file=/opt/keycloak/conf/certs/keycloak.key
http-enabled=false

debian@keycloak:~/acme-certs$

Keycloak initial build

sudo -u keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=admin123 /opt/keycloak/bin/kc.sh build

Output:

debian@keycloak:~/acme-certs$ sudo -u keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=password /opt/keycloak/bin/kc.sh build
WARNING: Usage of the default value for the db option in the production profile is deprecated. Please explicitly set the db instead.
INFO: The following run time options were found, but will be ignored during build time: kc.https-certificate-key-file, kc.http-enabled, kc.hostname, kc.https-certificate-file

Updating the configuration and installing your custom providers, if any. Please wait.
2026-03-19 20:00:27,827 INFO  [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 10529ms
Server configuration updated and persisted. Run the following command to review the configuration:

    kc.sh show-config

debian@keycloak:~/acme-certs$ /opt/keycloak/bin/kc.sh show-config
Current Mode: production
Current Configuration:
    kc.log-level-org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup =  null (Derived)
    kc.log-level-io.quarkus.config =  null (Derived)
    kc.hostname =  keycloak.acme.internal (keycloak.conf)
    kc.log-console-output =  default (classpath application.properties)
    kc.log-level-io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor =  null (Derived)
    kc.log-level-liquibase.database.core.PostgresDatabase =  null (Derived)
    kc.optimized =  true (Persisted)
    kc.version =  26.5.6 (SysPropConfigSource)
    kc.log-level-io.smallrye.openapi.runtime.scanner.dataobject =  null (Derived)
    kc.https-certificate-file =  /opt/keycloak/conf/certs/keycloak.crt (keycloak.conf)
    kc.log-level-org.jboss.resteasy.resteasy_jaxrs.i18n =  null (Derived)
    kc.log-level-io.quarkus.arc.processor.BeanArchives =  null (Derived)
    kc.log-level-io.quarkus.deployment.steps.ReflectiveHierarchyStep =  null (Derived)
    kc.http-enabled =  false (keycloak.conf)
    kc.log-level-org.hibernate.SQL_SLOW =  null (Derived)
    kc.https-certificate-key-file =  /opt/keycloak/conf/certs/keycloak.key (keycloak.conf)
    kc.log-level-io.quarkus.arc.processor.IndexClassLookupUtils =  null (Derived)
    kc.log-file =  /opt/keycloak/bin/../data/log/keycloak.log (classpath application.properties)
    kc.log-level-org.hibernate.engine.jdbc.spi.SqlExceptionHelper =  null (Derived)
debian@keycloak:~/acme-certs$

Keycloak daemon build (systemd)

I created a file /etc/systemd/system/keycloak.service with contents

[Unit]
Description=Keycloak Identity and Access Management
After=network.target

[Service]
User=keycloak
Group=keycloak
Environment=KEYCLOAK_ADMIN=admin
Environment=KEYCLOAK_ADMIN_PASSWORD=admin123
ExecStart=/opt/keycloak/bin/kc.sh start
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

And enabled the service

debian@keycloak:~/acme-certs$ sudo systemctl daemon-reload
debian@keycloak:~/acme-certs$ sudo systemctl enable --now keycloak
Created symlink '/etc/systemd/system/multi-user.target.wants/keycloak.service' → '/etc/systemd/system/keycloak.service'.
debian@keycloak:~/acme-certs$ sudo systemctl status keycloak
● keycloak.service - Keycloak Identity and Access Management
     Loaded: loaded (/etc/systemd/system/keycloak.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-03-19 20:05:40 IST; 6s ago
 Invocation: cde0a8f017a24bac8dd23934aa7a5bf2
   Main PID: 3250 (kc.sh)
      Tasks: 29 (limit: 2301)
     Memory: 269.9M (peak: 270.2M)
        CPU: 6.151s
     CGroup: /system.slice/keycloak.service
             ├─3250 /bin/sh /opt/keycloak/bin/kc.sh start
             └─3322 java -Djava.util.concurrent.ForkJoinPool.common.threadFactory=io.quarkus.bootstrap.forkjoin.QuarkusForkJoinW>

Mar 19 20:05:40 keycloak.acme.internal systemd[1]: Started keycloak.service - Keycloak Identity and Access Management.
Mar 19 20:05:46 keycloak.acme.internal kc.sh[3322]: 2026-03-19 20:05:46,328 INFO  [org.hibernate.orm.jdbc.batch] (JPA Startup Th>
debian@keycloak:~/acme-certs$

Keycloak admin dashboard

I visited https://keycloak.acme.internal:8443 from where the rootCA.pem was trusted in the OS as well as browser certificate store.

Then signed in.

And then created a permanent admin account as it says. I created a new user with username administrator, set a password, and then assigned admin role to it. Then logged in with that user and deleted the temporary admin user.

Then I created a realm for our fictional org - acme - with display name "Acme Corp", user self-registration disabled (admin-provisioned org), and email verification enabled.

Mailpit initial setup

Since this is a local lab with no real mail infrastructure, I used Mailpit - a lightweight fake SMTP server that catches all outbound emails and displays them in a web UI instead of actually delivering them. This lets me test Keycloak's email flows (verification, password reset, OTP) without setting up a real mail server or domain. I ran it on the same VM as Keycloak since it's a single binary with minimal resource usage.

I installed mailpit from GitHub, on the same VM as Keycloak.

wget https://github.com/axllent/mailpit/releases/download/v1.29.3/mailpit-linux-amd64.tar.gz
mkdir mailpit
tar -xzf mailpit-linux-amd64.tar.gz -C mailpit
cd mailpit
sudo mv mailpit /usr/local/bin/
sudo chmod +x /usr/local/bin/mailpit

And then verified it

$ mailpit version
mailpit v1.29.3 compiled with go1.26.1 on linux/amd64
Error checking for latest release: failed to fetch releases: received status code 403

And I created a new user for it

sudo useradd -r -s /sbin/nologin mailpit

Mailpit daemon build (systemd)

I put the following contents on /etc/systemd/system/mailpit.service (copied the previously generated keys to /etc/mailpit/certs and changed ownership of that folder to mailpit)

# /etc/systemd/system/mailpit.service
[Unit]
Description=Mailpit SMTP and Web UI
After=network.target

[Service]
User=mailpit
Group=mailpit
ExecStart=/usr/local/bin/mailpit --smtp 0.0.0.0:1025 --listen 0.0.0.0:8025 --ui-tls-cert /etc/mailpit/certs/keycloak.acme.internal.pem --ui-tls-key /etc/mailpit/certs/keycloak.acme.internal-key.pem
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

And ran

sudo systemctl daemon-reload
sudo systemctl enable --now mailpit
sudo systemctl status mailpit

It works

debian@keycloak:~/Downloads/mailpit$ sudo systemctl daemon-reload
sudo systemctl enable --now mailpit
sudo systemctl status mailpit
Created symlink '/etc/systemd/system/multi-user.target.wants/mailpit.service' → '/etc/systemd/system/mailpit.service'.
● mailpit.service - Mailpit SMTP and Web UI
     Loaded: loaded (/etc/systemd/system/mailpit.service; enabled; preset: enab>
     Active: active (running) since Fri 2026-03-20 15:37:36 IST; 67ms ago
 Invocation: 1046374b8fb24c4f92c8a6fe9683cb5f
   Main PID: 2010 (mailpit)
      Tasks: 3 (limit: 2301)
     Memory: 8.7M (peak: 8.7M)
        CPU: 13ms
     CGroup: /system.slice/mailpit.service
             └─2010 /usr/local/bin/mailpit --smtp 0.0.0.0:1025 --listen 0.0.0.0>

Mar 20 15:37:36 keycloak.acme.internal systemd[1]: Started mailpit.service - Ma>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
debian@keycloak:~/Downloads/mailpit$

Keycloak to use Mailpit for email

After I created the ACME Corp realm on Keycloak, I went to Realm Settings, email, entered these values to make use of Mailpit as email service.

Then I visited Mailpit dashboard at https://keycloak.acme.internal:8025/

It works.

Password Policy in Keycloak

I went to Authentication -> Password Policy -> Password Policies and set the password requirements to have

Minimum 10 characters
Minimum 1 Uppercase
Minimum 1 Lowercase
Minimum 1 Digit
Minimum 1 Special Character
Password history: 3 (prevents reuse of last 3 passwords)

I also configured brute force detection under Realm Settings -> Security Defenses -> Brute force detection:

Brute Force Mode: Lockout permanently after temporary lockout
Max login failures: 5
Maximum temporary lockouts: 1
Strategy to increase wait time: Multiple
Wait increment: 1 minute
Max wait: 15 minutes
Failure reset time: 12 hours

After 5 failed login attempts the account locks out temporarily. If login failures continue through the temporary lockout, the account gets permanently locked and requires an admin to manually re-enable it. This will be demonstrated later in the user lifecycle section using Burp Suite to capture the login request and a Python script to simulate a brute force attack with a wordlist.

Organization Structure

I created the above organization structure in Keycloak - four groups for departments, three realm roles (employee, manager, it-admin), and seven users provisioned and assigned accordingly.

All users:

Group Engineering:

Group Finance:

Group HR:

.png)

Group IT:

Role employee:

Role manager:

Role IT Admin:

Enforcing MFA via TOTP (Google Authenticator)

I set up password based logins for users (Something You Know). Now I will set up Google Authenticator based 2FA (Something You Have). For this lab, I will be using gauth.apps.gbraad.nl, a browser based Google Authenticator app implementation, on the host machine, as my Google Authenticator client.

I duplicated the default browser authentication flow in Authentication -> Flows, named it acme browser, and set the Browser - Conditional OTP step from Conditional to Required. Then under Authentication -> Bindings, I set the Browser flow to acme browser. This forces TOTP on every login for all users in the acme realm.

I also enabled the following required actions under Authentication -> Required actions:

Update Password
Verify Email
Configure OTP

These are applied to all users, so on first login every user is forced to change their temporary password, verify their email via Mailpit, and set up TOTP before they can access anything.

jsmith is forced to setup Google Authenticator login in next successful login:

jsmith added key to Google Authenticator

jsmith enters the OTP value and logs in successfully. Every other account did the same.

OIDC Client and SSO Demo

To demonstrate SSO, I registered a client in the acme realm pointing to the official Keycloak demo app hosted at https://www.keycloak.org/app/. Since it's a static page that runs entirely in the browser, it talks directly to my local Keycloak instance - no server-side component needed.

Client settings:

Client type: OpenID Connect
Client authentication: Off (public client)
Valid redirect URIs: https://www.keycloak.org/app/*
Valid post logout redirect URIs: https://www.keycloak.org/app/*
Web origins: https://www.keycloak.org

On the demo app, I pointed it at my Keycloak instance by entering the server URL, realm, and client ID.

Clicking Sign In redirected to the Keycloak login page, went through the full authentication flow - password then TOTP - and landed back on the demo app showing jsmith's authenticated session with the decoded token.

Employee lifecycle management

To demonstrate the full employee lifecycle, I walked through four real-world IAM events using mclark from the HR department.

1. mclark gets promoted to HR manager

mclark was promoted from HR employee to HR manager. In Keycloak, this meant removing the employee role and assigning manager under the user's Role Mappings tab.

Before:

After:

2. mclark takes a vacation (account disabled)

mclark went on an extended leave of absence. Rather than deleting the account, it was disabled - access is immediately revoked but the account and its data remain intact for when the employee returns.

3. mclark returns (account enabled)

mclark returned from leave. The account was re-enabled, restoring access with all roles and group memberships unchanged.

4. mclark quits (account deleted)

mclark resigned. The account was permanently deleted from the realm.

Confirmation:

mclark is no more:

Brute Force Protection

Now I am going to do a brute force attack on jsmith's account. I am going to manually type in some random password values and hit enter multiple times to see what happens.

As you can see from the admin dashboard, jsmith is now temporarily locked.

Event log

Keycloak captures two categories of events per realm. Login events record every authentication-related action - successful logins, failed attempts, logouts, and token operations. Admin events record every administrative action performed on the realm - user creation, role assignments, deletions, client configuration changes, and so on. Both are visible under Events in the admin console.

Login Events

Here is a snippet of lwilson signin related events

Admin Events

Here is a snippet of admin events related to jsmith getting promoted

Conclusion

The internship asked for a designed IAM solution and an implementation plan. This lab is that plan executed.

Every requirement from the Tata Forage simulation is covered here in a working deployment:

Keycloak handles identity and access management for Acme Corp the same way SailPoint and Oracle Identity Manager would handle it for TechCorp.
RBAC is enforced through realm roles mapped to job functions.
User provisioning and de-provisioning follow the same lifecycle model - onboarding with required actions, role changes on promotion, account suspension on leave, and full deletion on resignation.
MFA via TOTP enforces the "something you know + something you have" authentication standard.
SSO via OIDC demonstrates seamless access across applications from a single authenticated session.
Mailpit handles all email flows locally.
Brute force protection is configured and verified.
Admin and login events are captured in the audit log.

The entire stack - Keycloak, Mailpit, TLS via a local CA, DNS via Pi-hole, and network routing via pfSense - runs self-contained in VirtualBox, making it fully reproducible as a home lab without any cloud dependency or paid tooling.

Integrating a local mail server into my LDAP lab

Shoban Chiddarth — Thu, 19 Mar 2026 07:38:19 +0000

GitHub Repo: @ShobanChiddarth/postfix-dovecot-mailserver-in-openldap-lab

Introduction

This is the second stage of my OpenLDAP home lab. I set up a mail server to work with existing LDAP configuration.

Pre-Requisites

Setup Process

Mail Server Install

In the existing setup, I cloned another debian server VM, gave it static IP 192.168.57.7, set its hostname to mail-server.acme.internal and then added the DNS record in Pi-hole. Then I went ahead and installed the required packages for postfix and dovecot to work with LDAP.

sudo apt install -y postfix postfix-ldap dovecot-core dovecot-imapd dovecot-ldap dovecot-lmtpd

Then I chose "Internet Site" in the postfix install prompt asking about which type of mail server to install and set the domain to acme.internal.

Postfix Config

I edited /etc/postfix/main.cf to have this configuration:

myhostname = mail-server.acme.internal
mydomain = acme.internal
mydestination = $myhostname, $mydomain, localhost
mynetworks = 192.168.57.0/24 127.0.0.0/8
inet_interfaces = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
local_recipient_maps = ldap:/etc/postfix/ldap-recipients.cf

mailbox_transport hands mail delivery off to Dovecot via LMTP. The smtpd_sasl_* settings let Postfix use Dovecot for SMTP authentication. local_recipient_maps tells Postfix to look up valid recipients in LDAP instead of the local user table - without this, Postfix rejects mail to LDAP users with "User unknown in local recipient table".

I created /etc/postfix/ldap-recipients.cf for the recipient lookup:

server_host = ldaps://ldap-server.acme.internal
bind = yes
bind_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
bind_pw = SSSDPass123
search_base = ou=users,dc=acme,dc=internal
query_filter = (&(objectClass=posixAccount)(mail=%s))
result_attribute = mail

Then reloaded Postfix:

sudo systemctl reload postfix

Local CA Config on Mail Server

I copied rootCA.pem that I created earlier to this server and trusted it.

debian@mail-server:~/acme-certs$ ls
rootCA.pem
debian@mail-server:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@mail-server:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@mail-server:~/acme-certs$

Dovecot TLS Config

I generated a TLS cert for mail-server.acme.internal using mkcert and copied it to the server:

sudo cp mail-server.acme.internal.pem /etc/dovecot/private/mail-server.crt
sudo cp mail-server.acme.internal-key.pem /etc/dovecot/private/mail-server.key
sudo chown root:dovecot /etc/dovecot/private/mail-server.key
sudo chmod 640 /etc/dovecot/private/mail-server.key

Then updated /etc/dovecot/conf.d/10-ssl.conf:

ssl_server_cert_file = /etc/dovecot/private/mail-server.crt
ssl_server_key_file = /etc/dovecot/private/mail-server.key

Dovecot LDAP Config

I changed dovecot auth settings to use LDAP auth instead of system auth by editing /etc/dovecot/conf.d/10-auth.conf - commented out auth-system.conf.ext and uncommented auth-ldap.conf.ext.

debian@mail-server:~/acme-certs$ cat /etc/dovecot/conf.d/10-auth.conf | grep "include auth"
#!include auth-deny.conf.ext
#!include auth-master.conf.ext
#!include auth-oauth2.conf.ext
#!include auth-system.conf.ext
#!include auth-sql.conf.ext
!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-static.conf.ext

Dovecot 2.4 changed the config syntax from older versions, so the standard examples online did not work. After checking the example config the package ships with, I set /etc/dovecot/conf.d/auth-ldap.conf.ext to:

ldap_uris = ldaps://ldap-server.acme.internal
ldap_auth_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
ldap_auth_dn_password = SSSDPass123
ldap_base = ou=users,dc=acme,dc=internal

passdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  ldap_bind = yes
}

userdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  fields {
    uid = vmail
    gid = vmail
    home = /var/mail/vhosts/%{user | username}
  }
}

This reuses the same read-only service account from the LDAP lab. ldap_bind = yes means Dovecot verifies passwords by actually binding to LDAP as the user rather than fetching and comparing the hash. The userdb block maps all mail storage to a dedicated vmail system user instead of running as the LDAP user's UID.

Note: ldap_auth_dn_password is stored in plaintext, but /etc/dovecot/conf.d/auth-ldap.conf.ext is owned by root and not readable by other users.

Dovecot Mail Storage and Postfix Integration

Since LDAP users don't have home directories on the mail server, I created a dedicated vmail system user to own all mailboxes and set up a central mail storage directory:

sudo adduser --system --no-create-home --group vmail
sudo mkdir -p /var/mail/vhosts
sudo chown -R vmail:vmail /var/mail/vhosts
sudo chmod 770 /var/mail/vhosts

I updated /etc/dovecot/conf.d/10-mail.conf to use this path:

mail_driver = maildir
mail_home = /var/mail/vhosts/%{user | username}
mail_path = %{home}/Maildir
first_valid_uid = 100

Then I configured the LMTP and auth unix sockets in /etc/dovecot/conf.d/10-master.conf so Postfix can hand off incoming mail to Dovecot and use Dovecot for SMTP authentication.

In the service lmtp block:

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

In the service auth block:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Then restarted Dovecot:

sudo systemctl restart dovecot

Verification

Sending mail

I sent a test mail from jsmith to adoe over SMTP from a desktop VM on the same network:

debian@debian:~/acme-certs$ curl -v --url "smtp://mail-server.acme.internal:25" \
  --mail-from "jsmith@acme.internal" \
  --mail-rcpt "adoe@acme.internal" \
  --upload-file - <<EOF
From: jsmith@acme.internal
To: adoe@acme.internal
Subject: Test from jsmith

Hello Alice, this is John.
EOF

Postfix accepted it and delivered it to Dovecot via LMTP:

250 2.0.0 Ok: queued as 98B624018B

Verified the mail landed in adoe's mailbox on the server:

debian@mail-server:~$ sudo ls /var/mail/vhosts/adoe/Maildir/new/
1773903163.M693787P7845.mail-server.acme.internal,S=560,W=576

Retrieving mail over IMAPS

I verified that adoe can authenticate and retrieve mail over IMAPS using their LDAP credentials:

debian@debian:~/acme-certs$ curl -v --url "imaps://mail-server.acme.internal/INBOX" \
  --user "adoe:Password456"

* SSL certificate verify ok.
* Connected to mail-server.acme.internal (192.168.57.7) port 993
< A002 OK Logged in
< * LIST (\HasNoChildren) "." INBOX
< A003 OK List completed (0.001 + 0.000 secs).

TLS handshake succeeded using the mkcert CA, LDAP authentication worked, and the INBOX is accessible.

Thunderbird Verification

Thunderbird has its own certificate store separate from the system trust store, so I had to manually import rootCA.pem into Thunderbird settings before it would trust the IMAPS connection.

adoe sends an email to jsmith

jsmith opens it

jsmith sends a reply email to adoe

adoe views the reply email

Conclusion

Postfix and Dovecot are now running as a mail server for acme.internal. Users defined in the OpenLDAP directory can send and receive mail using their LDAP credentials. Postfix looks up valid recipients in LDAP so it accepts mail for LDAP users. Dovecot authenticates over LDAPS using the same read-only service account from the LDAP lab and stores mail in a central directory owned by a dedicated vmail user. IMAP access is over TLS only.

This mail server will be used in the next part of this series as the SMTP backend for Keycloak notifications.

DEV Community: Shoban Chiddarth

I did an ettercap MITM Home Lab

Introduction

About the lab

Things I learnt from this lab

Conclusion

I finished the SIEM Wazuh Home lab

Introduction

Further reducing the scope

Reducing the size of VMs for video recording

Future of this project

Conclusion

Day 1 of Cybersecurity

Introduction

Designing the Network Architecture

pfSense behaves differently with non LAN adapters

The Next Day

Wazuh Installation and Re-installation on Debian server VM

Ubuntu static IP issue

Ubuntu not seeing the whole disk

Accidental VirtualBox basic mode

Configuring pfSense+Suricata IDS/IPS as a log source

My PC hanged

pfSense DNS resolve host override subdomain field confusion

Reducing the scope of this project

Deploying the agents

Conclusion

I recently learnt how to setup a NAT instance instead of NAT Gateway in AWS

Introduction

Architecture

NAT Instance config

1. source_dest_check = false

2. Security Group config

3. Route table (of private subnets)

4. user_data

5. Make sure the NAT instance has an Elastic IP

Demo

Cost Calculation

NAT Gateway

NAT Instance

Comparison

When NAT Gateway is better

Conclusion

Telegram Ban in India has been lifted, for now

Deploying a Telegram MTProto Proxy on AWS with Terraform

Introduction

Architecture

The Proxy Server

MTProto

Region choice explanation

Security implications

Port 22 open to internet

Anyone who has the public IP of the EC2 can connect to the Telegram proxy (Port 80 open to the internet)

Other issues

Current architecture can't handle enormous load

The instance runs 24/7

Cost Calculation

Step by step process to connect to the proxy server you deployed

Steps to deploy

Steps to connect to the proxy

What I normally do for the above mentioned security implications

Conclusion

How to circumvent the Telegram ban in India

Introduction

IFF Tweet: Statement : Shutting down Telegram is a band aid solution and is a disproportionate answer to exam fraud

IFF Video: Banning Telegram won't fix a broken examination system.

How to circumvent the ban

1. Use a VPN

2. Use a Telegram Proxy

3. Cloudflare WARP

Conclusion

On Age Verification

Introduction

Facebook

Linux

systemd

Distro hopping

Why is it impossible to enforce this law?

Why is it impossible to comply with this law?

Right to Repair

1. `source_dest_check = false`

4. `user_data`