Detecting and Blocking Botnet Activity Using Firewall Logs

Sanjay Seth Discusses his Experiences from P J Networks Pvt Ltd

Greetings, fellow listeners, I’m Sanjay Seth — a cybersecurity consultant, a network junkie since the early 90s, and that friend who still finds a local dial-up connection kinda nostalgic. I’m writing this at just my third coffee (yes, still awake) and on a caffeine high after just returning from DefCon — the hardware hacking village was insane! Enough about shiny gadgets, let’s turn to something that haunts my dreams at night: botnets.

I have been knee deep in firewall logs since the Slammer worm took down the PSTN (god I loved when it slowed down voice and data mux systems) That’s where I learned to detect strange patterns — things that raised the alarm, “attack!” Honing zero-trust architectures for clients from SMBs through to large banks — now I run PJ Networks Pvt Ltd. And botnets? They remain one of the nastiest beasts in the field.

So, today, I would like to discuss firewall logs and how to detect and block botnet activity. Because if you aren’t peering at those logs with hawkish vigilance — you’re basically giving your network to attacks.

What is a Botnet?

A botnet, at its most basic — is a network of compromised computers or devices (common term: zombies or bots) that is controlled remotely by a bad actor. These devices could be anything with an internet connection — desktop computers, servers, IoT devices… even smart fridges. Yeah, your fridge could be a weapon if you don’t update it.

The thing about botnets, though, is this:

• They’re all used for various kinds of nefarious activity: DDoS attacks, spam, data theft, cryptocurrency mining, you name it.
• The cleverest botnets lurk in plain sight — making minuscule, almost harmless connections so as not to raise alarms right away.
• The command & control (C2) servers are the brain of the botnets — they give instructions to the infected devices.

In the early 2000s I witnessed how the Slammer worm spread through networks, consuming bandwidth faster than a racecar on a straightaway. Modern botnets are vastly more sophisticated — and firewall logs are your early-warning radar to catch them.

Identifying Abnormal Traffic Patterns

This is where the real magic happens — and your firewall logs become your new best friend. If you’re not looking at your firewall logs daily or, at a minimum, setting up alerts, you’re flying blind.

Look for:

• Repeated connections to obscure or unknown IP addresses (it’s suspicious if they connect at 3 AM, while your team is asleep).
• Spikes in outbound traffic — botnets are fond of leeching off your bandwidth if they manage to get a foothold.
• A series of unsuccessfully attempts to connect or unusual activities for port scanning. This has the stench of reconnaissance.
• Devices generating unexpected DNS requests — many botnets rely on dynamic DNS or randomized domain requests to bypass detection.

I assisted three banks with recently updating their zero-trust configuration — and what prompted the review? One of our endpoints was silently attempting to communicate with a C2 server over strange ports that no one had approved. Firewall logs revealed a quiet but persistent pattern — and early detection spared them from a possible breach.

Quick pro tip: flag internal IPs suddenly starting to talk externally out of the ordinary port. Actual traffic? 99% sits on the common ports: 80, 443, 53, maybe a few VPN ports here and there.

Absorbing Command & Control Servers

After identifying suspicious outbound connections, the next step is to block the C2 servers that are controlling your infected bots. And don’t expect these servers to be easy to find. They employ things such as fast-flux DNS, proxying, tunneling, you name it.

Some things that help:

• Block the traffic to known bad IP addresses, or domain patterns using firewall rules.
• Use deep packet inspection if your firewall supports it — the payload may show telltale C2 command strings.
• Blacklist suspicious URLs or IP addresses seen in threat intelligence feeds (more on that later).
• If they’re not business-critical, block outgoing traffic on unusual ports.

Here’s one of mine: Blocking all “suspicious” looking stuff without checking it can bring business operations to its knees. You want it to be surgically precise — not a shotgun approach. What that means, in my book, is that you need to base your blocking strategies on datasets, threat feeds, and plain experience.

Using Threat Feeds

This is where some people become overzealous about AI-powered cybersecurity. My sense of it: take those claims with a grain of salt. AI can assist, sure — but threat intelligence is a human endeavor in its need for context.

At PJ Networks we ingest numerous threat feeds into our firewall and SIEM to cross-reference IPs and domains. Here’s why it’s important:

• Threat feeds provide current lists of C2 servers, known botnet nodes and active exploit kits.
• They automate blocking, availability alerts — they’re key for teams that can’t watch logs 24/7.

Some feeds provide reputation scores or risk levels to help prioritize which threats should be addressed first.

However… do not depend on threat feeds only. They’re reactive — if your firewall logs are screaming about funny stuff that’s not in the feed yet, that means: either a new botnet or a targeted attack. It is impossible to substitute human analysis and investigation.

Automating Botnet Detection

I mean, firewall logs can be HUGE. It’s like finding cooked meat in a factory where thousands of hamburgers are coming down a conveyor belt every second. That’s impossible if you’re doing it all by hand.

Fortunately, automation isn’t just attractive pie in the sky anymore:

• Set your firewall to sound alarms based on anomaly detection (e.g., unexpected traffic spikes, persistent links).
• Combine firewall logs with endpoint telemetry and DNS logs using correlation engines or SIEM tools for a more comprehensive picture.
• Develop scripts to parse logs and search for known indicators of compromise (IoCs) related to botnet activity.
• Generate playbooks for automated response — for example, isolating infected hosts or throttling of dubious connections.

PJ Networks just finished a custom parser and alerting system for a law firm that kept getting tormented by botnet traffic. Their incident response time was reduced by 75% No joke.

Quick Take — The Basics of a Botnet Firewall

If you’d like to leave here remembering only one thing today, here’s my coffee-powered condensation:

• Botnets conceal themselves amidst regular traffic. Interrogate firewall logs for subtle anomalies.
• Command & Control servers are the puppet masters — cut their strings ASAP.
• Rely on threat feeds — but don’t sleep on your own eyes.
• Automate Aug: Logs get too big after a while, so automate what you can.
• And, do not trust AI-powered as a panacea without human due diligence!

Final Rant (Sorry, not sorry)

Before closing this out, I need to vent about password policies. Many people pay attention to botnets and firewalls but fall short on password hygiene. A simple or reused password is just an invitation for botnets to come inside.

Imagine that your firewall is a high-performance car engine, but if you leave the keys under the floor mat (rookiemove), your whole security setup was a pointless endeavor.

MFA (multi-factor authentication) and strong, unique passwords are as important for botnet defense as firewall rules.

Conclusion

So botnet detection can be hard, yeah. But observed from that arc — the line from a single worm to the stealthy botnets of today — the tools have changed, and so should our vigilance. Logging, scrutinizing, blocking — and asking what the data can tell us.

For more on botnets, firewalls, or how your business can lock their cyber doors, hit me up at PJ Networks! Always happy to exchange war stories, lessons learned.

Until then, hold that coffee and those firewall logs tight.

— Sanjay Seth
Founder & Cyber Security Consultant, P J Networks Pvt Ltd
Fighting botnets one line in a log at a time since the days of PSTN mux to zero-trust.