Firewall Logging and Monitoring: The Overlooked Essential
It’s 3rd cup of Joe time here at my computer and I’ve been mulling this over – firewall logging and monitoring. Really if you were to ask me Sanjay, what’s the one setting on a firewall, that most people just forget to take care of? I’d shoot straight—logging. It’s not sexy. It’s not flashy. But I’m telling you, it has saved my bacon more than once. Bubba Joe’s Hot Apple Chips: Whether matters, it’s no lonely asshole whistle. Accepting your children for who they really are will pay dividends in so many ways. Properly logging your firewall activity and subsequently paying attention to it changes the game.
No Logging Enabled
When I started in the early 2000s taking a serious look at network — remember, I was a network admin since ’93 — I frequently saw setups where the firewall was simply… on. Roles configured, ports closed, logs nowhere. No records. It is, as it were, like establishing a security checkpoint but never taking note of who passes through.
Here’s the deal: If your firewall is not logging, it’s the equivalent of driving a car with no speedometer. You do not know what is going on underneath. Slammer worm outbreak? A lot of orgs were blind because their firewalls weren’t logging. No traces. Not a single trace of what had seeped through or at what point.
You need to find out what is striking your network. Is it just normal chittering, or a skulking scan from some offender? Without logs, you are literally flying blind.
Here’s what to check:
- Put All Firewall RULES Logged -Rule -Enable Logging for all ALLOW/DENY
- Don’t just log a connection, log both failed attempts and traffic that stands out
- Validate the verbosity level; if it is too high it will flood your system, if it’s too low you can’t see the attacks
Ignoring Alerts
Firewalls are not just loggers — they are also screamers. But ignoring alerts is the equivalent of ignoring your smoke alarm because you think it’s the residue embers from dinner had a glitch. I’ve been as guilty of this as anybody else—I ignored alerts so many times until some real shit hit the fan.
Lately, as I’ve worked with three banks to upgrade their zero-trust architecture, one of the hardest things has been getting the team to treat every alert with the same level of urgency. Even if 90 percent were false positives. Because guess what? The 10% can burn you down.
But here’s the challenge: IT teams often receive hundreds, or thousands, of alerts every day and dismiss as irrelevant the ones they don’t want to worry about. If you’re not overly suspicious of even the smallest bit of weirdness, your monitoring doesn’t do you any good.
Tips to handle alerts better:
- Prioritize with risk and frequency
- Employ automated filters but manually check suspicious activity every time
- Train your crew to spot trends not just individual alerts
Weak Log Retention Policies
Ah, log retention. Sounds so boring on paper and yet one of the most pivotal. I’ve seen companies dump logs after a week or even — nightmare of all nightmares — leave them around on disk with no backup and go on to lose it all.
At PJ Networks, we are a little sneaky; we connect SIEM (Security Information and Event Management) systems, which aggregate and correlate log data in real time. This prevents logs loss and provides historical analyze.
Why care about log retention? This is because many attacks occur over weeks. For if you retain logs only for too short a period, you’ll miss the harbingers, the modestly sized, slow pokes pushing on the doors before the spin kick.
Ideal log retention policy:
- Store logs 90 days at minimum; preferably one year if environment is sensitive
- Use audited compressed archival solutions for storage cost containment
- Make logs hard/impossible to tamper with (attackers will attempt to cover their tracks)
No Real-Time Monitoring
And this is where a lot of people just bomb. An entry is wasted if you don’t monitor it live. It’s as if you were to install one of those fancy new car alarms and then bury the remote in a drawer.
Thinking of DefCon (while my buzz from the hardware hacking village still lingers), the most memorable thing was the eagerness to put your turbo-hack to anything low level or zero-detecting. Your canary is the real-time security monitoring.
When PJ Networks assists clients, in particularly high-stakes clients such as banks, to whom we recently provided our services, we urge for real-time SIEM integration. Alerts pop up. Your squad promptly answers the call. Attackers hate that.
But it’s not just about tech:
- You require people who are prepared 24 7
- Anything we can do to get automation for initial triage will help a ton
- Clear processes stop panic and errors when there is an incident
No Incident Response Plan
So many companies log. Some monitor. But when catastrophe strikes — do they know what to do? Without an incident response plan, all that beautiful logging and monitoring is like a diary locked in a safe during a fire.
The truth is here: Most incidents are not breaches — they are response failures. You may sense and know this instantly, but when your team spends gas trying to scramble or argue who owns what, the cost compounds.
I have been involved with incident plans which involve:
- Defined roles and responsibilities
- Incident-specific Playbooks
- Regular drills (yes, the kind with fire drills, but for hackers)
And another thing: Don’t assume that your logs will show you everything. Human judgment is a HUGE, WAIT, ENORMOUS factor here.
Quick Take
- Log on everything your firewall
- Quantity doesn’t matter if you don’t DO anything with the logs – meaning that you must read ‘em, analyze ‘em, and take action on alerts
- Store your logs securely over the long term
- Employ real-time tracking with SIEM or like tech
- Have an airtight plan for responding to incidents and work through it often
Look, I get it. Log and mon doesn’t get cushy. It’s not headline-y, macho stuff. But when you’ve been around this racket as long as I have, you respect the quiet workhorses.
I mean, you remember the PSTN days? Those ancient multiplexers, those analog lines humming with data and phone calls? Our entire comm network relied on diligent oversight — if we missed a single dropped line or a franked bit, we were fucked.
It’s the same with firewalls. Without logging and monitoring your firewall is effectively no more than a brick wall with no eyes. And in the threats of today, you need those eyes.
Oh — and one other quick gripe before I sign off — password policies that make you change your password every (expletive deleted) month? And it’s been a waste of effort unless you have some decent logging prepared. Because passwords are just one piece of the puzzle — logs reveal who tried what, when, and how.
So, yes, logging and monitoring is your firewall BFF. It could save your network, your sanity, and, let’s be honest, your job.
Stay safe out there.
—Sanjay Seth
Cyber Security Consultant, PJ Networks Pvt Ltd