Recently a client exported three days of firewall threat logs for us — 1,080 alerts — and asked a very practical question: “do we need to deal with these?”
After analyzing them, our answer was: hold off on working through the alerts, because this batch of logs itself has three problems that make it nearly unusable.
These three problems are not unique to this client — they are extremely common among small and mid-sized businesses, and they all share one trait: the firewall appears to be working normally, alerts arrive every day, the reports look good, and yet at the critical moment it is of no use. Below we walk through the three findings and the matching self-check methods.
Finding 1: for 88% of the alerts, you cannot tell who did it
The first thing we did was tally the “attacker” field: of the 1,080 alerts, the sources of 952 of them (88%) come down to just 11 IPs.
That is not normal. Real internet scanning should come from hundreds of scattered IPs.
Then look at what those 11 IPs are — every one of them is an internal gateway address. In other words, the “attacker” the firewall recorded is the company’s own gateway device.
Cause: before the traffic reaches the firewall, an upstream device has already performed address translation. The real source IP is replaced at this step with the gateway’s own address, so the firewall only sees the translated result.
The consequence is very real: you see an IP attacking hundreds of times and want to block it — what you block is your own gateway, and blocking it takes the whole company offline. This is also why many companies “have alerts but have never acted on them”: because they cannot.
This is not a firewall problem, it is a logging-pipeline problem. The device itself is working fine, but the information it receives has already had key parts erased upstream. Of the 1,080 entries, only 128 actually show a public-internet source.
Finding 2: 34% only alert, they do not block — including high-risk ones
First, let us correct a very common misunderstanding: when many people see alerts on the firewall, their first reaction is “good thing it blocked that.”
Quite the opposite. A firewall takes two kinds of action against a threat: block and alert only. “Alert only” means — it saw it, logged it, and let it through.
In this batch of logs, 369 entries (34.2%) have an action of “alert only” — that is, one third of the threats were let through.
More importantly, 6 of them are high-risk. The group that most deserves attention: a single public IP, within ten seconds, repeatedly attacked two publicly disclosed high-risk vulnerabilities (a vulnerability in a database management tool and a vulnerability in a network device authorization component) — all allowed through.
Why does this happen? Usually it is not that someone deliberately switched blocking off; rather:
- The default configuration is “alert only.” Many security policy templates ship in a conservative state to avoid blocking legitimate business traffic, and nobody changes them after installation.
- It once blocked legitimate business traffic by mistake, so it was switched back to alert mode. This is very common — a false block once made a printer unusable or a system unreachable, so the fix was to loosen that policy, and then it was never switched back.
- Different zones use different profiles, some strict and some loose, and nobody compares them on a regular basis.
Finding 3: the most numerous type of alert is a false positive
Sorted by type, the largest share is one category of injection attack: 316 entries, 29.3%. If you only look at this ranking, the conclusion would be “we are being hit by a massive injection attack,” and you would dive straight into investigating it.
But we took one extra step. Split open, these 316 entries are two groups:
- One group of 158 is outbound (an internal host → an external address)
- The other group of 158 is the return direction (that address → the same host)
- Intersecting the timestamps of the two groups: 158 matches 158 exactly, one-to-one, with not a single entry left over
→ This shows that the same traffic was logged twice; the real count is only about 158, not 316.
Then we looked at the addresses at both ends and found something more interesting: the initiator and the target are actually the same host — it looped out through its own public address to reach one of its own service ports. And the database behind that port has a query interface that happens to put the query statement in the URL.
So the firewall rule matched: “a query keyword appeared in the URL.” Judged as an injection attack.
In other words: the “number one threat,” which accounts for nearly a third of all alerts, is the company’s own normal traffic being misjudged — and counted twice on top of that. The handful that genuinely deserve attention are buried under this pile of noise.
From 1,080 to 6: the gap between alert volume and real workload
What this chart is saying is not “the alerts are all useless” — it is that the number 1,080 both exaggerates and conceals the problem. It exaggerates because it contains a large amount of false positives and duplicates; it conceals because the few entries that most need immediate action sit mixed in with the noise in one table, and sorting by volume will never bring them to the top.
The right order for reading logs: look at the action first, not the severity
The first thing most people do when they open a threat log is sort by threat severity and start from “high risk.” That order is wrong. The correct order is:
- Step one: look at the “action” column. Pull out everything that is not blocked first. Anything already blocked counts as “handled” no matter how severe it is; what was not blocked is the gap that is currently open. This column matters far more than threat severity.
- Step two: confirm whether you can attribute it. Check whether the source IP is a public address or your own internal address. If they are all internal gateways, fix the logging pipeline first — otherwise every analysis that follows is built on wrong information.
- Step three: rule out false positives before sorting. Verify the one or two largest categories separately — especially those where both the source and the target are internal, or that map to your own business ports. Remove the confirmed false positives first, then prioritize what remains.
- Step four: decide on each unblocked high-risk item, one by one. Block what should be blocked, patch what should be patched, and tune the rules for what turns out to be a false positive. The list at this step is usually short — a few items to a few dozen — and it is a workload you can actually finish.
Self-check list for small and mid-sized businesses
| What to check | How to check it | What normal looks like |
|---|---|---|
| Can the sources be attributed? | Export the threat log and count how many distinct IPs appear in the “attacker” field | A large number of scattered public IPs; if they cluster on a few internal addresses, the link has a problem |
| How many events only alerted and were not blocked? | Group and count by the “action” column | High-risk events should mostly be blocked; if more than 30% were not blocked, the policy needs review |
| Is the top-ranking category a false positive? | Look at the source and destination of the number-one category — are they all your own assets or your own business ports? | If it is your own assets talking to each other, it is very likely a false positive; verify before treating it as a threat |
| Is anything being counted twice? | Split the same type of alert by direction and compare the timestamps on both sides | If they match up one to one with none left over, a single communication was logged twice |
| Has any policy been loosened? | Compare the security profiles of each zone and check whether the action settings are consistent | Differences in strictness between zones should be deliberate, not historical leftovers |
A Few Common Questions
Q: We already have a firewall installed — doesn’t that mean we don’t need to worry about any of this?
A: Installing it is only the first step. In this example the device itself was running normally and alerts were being generated as usual, yet one third of the threats were allowed through, nine out of ten sources could not be attributed, and the top alert was a false positive — none of which anyone will proactively tell you. You only find out by exporting the logs and analyzing them once.
Q: How often should we review firewall logs?
A: We suggest exporting them once a month for statistics (not reading entry by entry, but looking at the ratios above). In addition, you must review them after every change to a security policy — because the most common problem is loosening a policy so it won’t block business traffic, and then forgetting to tighten it back.
Q: Why is there double counting? Is the device broken?
A: No. The same traffic can be logged separately as it crosses different zone boundaries — once outbound and once on the return path — which makes sense in the device’s own logic. The problem is that if you don’t de-duplicate when compiling statistics, the numbers come out inflated by as much as double, which then skews how you prioritize.
Q: If I find a high-risk event that is only set to alert, can I just switch it to block?
A: Don’t just change it. First confirm whether that rule has ever wrongly blocked business traffic. The safe approach is to confirm in observation mode that every hit is a genuine threat, then switch it to blocking, and watch business traffic for a few days afterwards. The most common accident with security policies is not a missed block — it is blocking the wrong thing and taking business down.
Want to know how much of what is in your firewall logs is a real threat and how much is noise?
Siwenlide provides integrated network security and IT operations services for small and medium-sized businesses in Beijing and the surrounding area: we export the threat logs and run the statistical analysis, starting by clarifying three things — whether sources can be attributed, how many events only alerted without blocking, and whether the top alert is a false positive — then give you an actionable remediation list and policy tuning recommendations, instead of handing you a table of hundreds of alerts. Firewalls, network devices and day-to-day operations can be managed as a package. Visit siwenlide.com or call 400-686-2011 to talk it over.
