Logging into Firewall to Detect DDoS Attacks

From the Desk of Sanjay Seth you are here: Home / Real Experiences From the Desk of Sanjay Seth | P J Networks Pvt Ltd

Here I am. Third cup of coffee down — still buzzing from DefCon’s hardware hacking village — and I am thinking about something that has been in my mind since the early 2000s when I first started delving into the realm of the network admin. All the way back in ’93 I dealt with PSTN muxes carrying voice and data (ah yes, the bygone days) before everything went cloud. Since then, I’ve witnessed cyber threats develop from benign probing to the DDoS monsters that pummel today’s networks.

Here’s the thing: Identifying a Distributed Denial of Service (DDoS) attack before it knocks out your critical services should have nothing to do with high faluting AI (that frankly, I’m doubtful about). This is about putting your hands into the dirt of the firewall logs, the digital footprints your network leaves behind. Nothing magic, just clever analysis.

Quick Take

• Check your logs for unusual traffic spikes or repeated connection attempts from the same sources
• Set baseline traffic patterns so shades are obvious
• Block malicious IPs fast and efficiently using your firewall
• Automate your response to DDoS attacks to reduce damage and facilitate recovery
• Don’t count on just your firewall — use anti-DDoS solutions for multi-layered protection

1. Identifying DDoS Patterns

IF YOU’VE hung around networks like me, you know a firewall log isn’t merely rows upon rows of gobbledygook bits. It’s a story — sometimes a thriller — about who is knocking on your door and how hard.

DDoS attacks usually bombard your network with traffic that seems suspiciously… pattern-like. But here’s what trips people up: it isn’t necessarily large packets or large-bandwidth flows from a single source. Nope. It’s distributed. You should consider that instead of one furious bumblebee, it’s a swarm of mosquitoes. Many small slaps from lots of IPs but enough to drive you crazy.

I have previously assisted banks in deploying upgrades to zero-trust architectures, so one of the earliest indicators from that experience is this:

• Increases in SYN requests or connection attempts
• Your TCP stack gets flooded with repeat failed handshakes
• Specific endpoints being hammered with traffic
• New or odd source IPs for your normal traffic profile

In the days of Shut the Slammer worm these patterns were somewhat easier to see — given that the worm assaulted the network with pure volume. But the attackers have grown craftier. Sometimes they’ll alternate attack vectors — mixing protocols, or sending malformed packets to confuse your firewall.

The trick is to become familiar — really familiar — with your normal logging patterns. Only then can you see the oddities.

2. Monitoring Traffic Surges

You cannot manage what is not measured. That’s been the mantra since I designed network monitoring systems that monitored voice and data simultaneously. Detection of DDoS follows the exact same logic.

Your initial task is to set a baseline. Explore firewall logs to learn:

• What does normal peak traffic look like versus off-peak?
• What IPs are frequent, and what are one-and-dones?
• Common packet sizes and protocols in use daily

When your firewall logs (and performance metrics) start to show traffic spikes well beyond this baseline — alarm bells should be ringing.

Pro Tip: If you just deployed new services or migrated systems (my most recent oversight were bank zero-trust upgrades) then watch them like a hawk. New services means new traffic patterns, which can either mask attacks or mimic them.

Case from the trenches: One bank’s firewall logs recorded an increased volume of UDP traffic concentrated on specific port ranges. It seemed benign until I noticed the packets were identical, originating from hundreds of IPs around the world. Classic DDoS.

3. Blocking Malicious IPs

Think of firewalls as gatekeepers. You see a bad actor in the logs and want to slam that gate shut, fast. But it’s tricky. Blocking just by IP is a double-edged sword.

Here’s why:

• Attackers typically utilize botnets with a large pool of switching IPs
• Block_dives too strong, and you end up blocking legitimate users—especially in zero-trust situations
• The admin headaches of over-blocking

But ignoring malicious IPs? Recipe for disaster.

So what do I do?

• Blocklists based on firewall logs, not static blocklists
• Apply rate limiting for partner ranges which generate suspicious requests
• Use geo-blocking only when business operations permit
• Cross-check suspicious IPs with threat intelligence feeds before blocking (We always blind-block around here)

My preferred method is automation, followed by manual check. You automatically deny obvious, noisy IPs, you get alerts for borderline cases. Keeps you sharp.

Once, during a nasty DDoS campaign against a client bank, this combo reduced attack traffic by over 70% within mere minutes. And those logs are your best friend.

4. Automating DDoS Response

I’m old enough to remember when automation was a batch script or a clunky alert system that beeped annoyingly on night shifts. Today? Automation is your first line of defense—for DDoS attacks in particular.

Your firewall logs should not only be historical records. They should trigger actions:

• Immediate bans for failing to connect multiple times or sending malformed packets
• Rate limiting thresholds used in firewall rulesets
• Log Real-time alerts to your SOC team with rich logs for investigation
• Onboarding with your network devices for dynamic traffic re-direction or throttling

But automation doesn’t mean to “set it and forget it.” I learned this one the hard way — once I was caught off guard when my scripts blocked a legitimate migration server. Oops.

Make sure you’re ready to tune your automation, investigate false positives, and always maintain a human in the loop.

5. Implementation of Firewalls with Anti-DDoS Solutions

“I hear some people swear by standalone anti-DDoS appliances or cloud scrubbing services. And yes, they add value. But if you ask me — and I’m sure many agree and many don’t agree — that your firewall is not a door stop. It’s the first line of defense, the bouncer who inspects credentials before anything can get in.

Add in purpose-built anti-DDoS solutions, and you have layered protection — like a car with seatbelts and airbags.

Here are the steps I generally recommend to clients (and followed myself at P J Networks):

• Deploy firewall capable of granular logging and supporting custom rules for DDoS vectors.
• Hook up with behavioral analytics (BA) tools which identify abnormal traffic patterns prior to the triggering of the Firewall
• Use cloud-based scrubbing services for volumetric attacks that exceed on-premises capacity
• Keep reviewing firewall logs and correlate with threat intelligence for new attack signatures

If your firewall vendor claims AI-powered DDoS detection, use salt – a lot of it. Sure, machine learning is good at that — but if it’s a black box, how do you really know what is happening inside? Using Instagram and Facebook also does not suit my preference for openness and control. (Yeah, call me old school — but I like seeing what’s under the hood.)

Wrapping Up

Your eyes and ears when defending against DDoS attacks are firewall logs. In my decades in cybersecurity, from stopping Slammer worm breakouts from slamming down to locking down banks’ zero-trust implementations, I’ve picked up this lesson:

• Glance at your data and know your network’s normal like you know the sound of your car’s engine
• Monitor traffic spikes as closely as a hawk stalking its prey — no curious upticks
• Block bad IPs intelligently, don’t just blindly slam the door shut
• Automate to stay ahead, but keep your eyes peeled
• Firewalls in combination with specialized DDoS solutions for that additional layer of security

And if you ever think that firewall logs aren’t very useful, never forget — they aren’t logs. They are a story of your garden’s survival. Show them the respect that they are owed.

Well, if you’ll excuse me, my fourth coffee is calling. And perhaps a few more tweaks to some new router firmware I grabbed at DefCon…

Stay safe. Stay curious. And keep those logs close.

– Sanjay Seth
Founder & Cyber Security Consultant | P J Networks Pvt Ltd
Defending networks in the trenches since 1993