{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
SRC FW DST {{ firewallStage.directionLabel }} {{ firewallStage.portLabel }}
Use Mixed unless every line comes from one firewall export format.
Typical values include deny, drop, reject, blocked, and block.
Use commas or ranges, for example 22,3389,445,1433,3306.
Set the deny count that turns a source/service cluster into a rule-review candidate.
denies
Repeat gate slider {{ repeatThresholdRangeLabel }}
RFC1918 defaults are loaded; add site prefixes when the sample includes routed internal ranges.
Paste deny/drop/reject lines, JSONL, or CSV rows. Non-deny lines stay visible in the parse ledger.
{{ params.logs.length.toLocaleString() }} chars
{{ fileStatus || 'Drop LOG, TXT, JSONL, or CSV onto the textarea.' }}
{{ fileError }}
Use 5-15 for human review; larger values help when pasting filtered SIEM exports.
rows
Visible hotspot slider {{ topNRangeLabel }}
Keep enough rows to prove parser coverage without making the tab unwieldy.
lines
Ledger depth slider {{ ledgerLimitRangeLabel }}
{{ header }}Copy
{{ cell }}
No {{ tab.label.toLowerCase() }} rows are available
{{ emptyTableNote(tab.key) }}
Tags: Diagnostics, Networking, Security
Firewall Rule Review Report Review firewall rules for stale use, broad sources, expired access, missing owners, and privileged services with a scored cleanup queue.
Audit Log Anomalies Analyzer Analyze audit log exports in your browser, ranking failure bursts, privilege changes, source shifts, and after-hours activity with evidence.
Firewall Shadow Rule Checker Find shadowed firewall rules in ordered ACL exports, compare full and partial overlaps, and turn risky rule conflicts into a cleanup queue.
Port Exposure Summary Checker Summarize port exposure rows into a prioritized review list, flagging public high-risk services, missing owners, and host cleanup scope.
Customize
Advanced
:

Firewall deny logs are the record of traffic that reached a policy boundary and was refused. They usually contain a small set of clues: who appeared to send the packet, where it was headed, which protocol and destination port were involved, what rule or policy made the decision, and how the firewall described the result.

Those clues matter because a deny is not automatically bad news. A public internet scanner hitting remote desktop, a workstation trying to reach a database it should not use, a stale application still calling an old service, and a default-deny rule doing exactly its job can all create deny entries. The same word, such as deny, drop, reject, or blocked, needs network context before it becomes an action item.

Source
The address that appears to originate the denied traffic. It may be a host, a translated address, a scanner, or an upstream device.
Destination service
The destination address plus protocol and port, such as TCP/445 for SMB or TCP/3389 for RDP.
Action or verdict
The firewall's decision wording. Some log formats separate the alert action from the final packet verdict.
Direction
The path implied by internal address ranges: inbound from outside, outbound to outside, lateral inside the network, perimeter-only, or unknown.

Good deny review starts with grouping, not with individual lines. One rejected packet may be routine background noise. Repeated denies from the same source to the same service point to a configuration error, a blocked access request, a noisy scanner, or a source that deserves closer investigation. Direction changes the meaning too: an inbound SSH deny from the internet is different from an internal host repeatedly trying SMB across segments.

Firewall deny triage path Deny log lines become grouped traffic paths, then repeated and watched services move into the review queue. Deny lines drop reject block Tuple src dst proto port Path ingress lateral Queue priority Counts stay useful when they remain tied to the source, destination service, policy evidence, and direction.

A useful firewall deny review also keeps its limits visible. Logs can be incomplete, source addresses may be translated, and a device can log only the policy match it was configured to record. A high count is a strong triage signal, not proof of intent. A quiet log slice may simply miss the time window when the traffic occurred.

The safest response is often to confirm the block before changing it. A deny entry may lead to a firewall rule review, source-owner check, endpoint investigation, cleanup of an old application setting, or no change because the control is working as intended.

How to Use This Tool:

Use a focused log slice first, then broaden the sample only after the parser and direction settings look right.

  1. Choose Log family. Keep Mixed syslog / JSON / CSV for pasted samples from several sources, or select FortiGate, AWS Network Firewall / Suricata EVE, Cisco ASA, or Linux-style logs when the source format is known.
  2. Review Deny action tokens. The default tokens cover common deny wording such as deny, drop, reject, blocked, and block. Leave allow-style words out unless you are deliberately testing parser behavior.
  3. Set Watch ports for services that should be elevated during review. SSH, Telnet, SMB, RDP, Microsoft SQL Server, MySQL, and PostgreSQL are included by default.
  4. Set the Repeat threshold. A threshold of 3 means a source-service group needs at least three denies before it receives the repeat bonus.
  5. Check Internal CIDRs. The default private IPv4 blocks work for many networks, but routed data-center, cloud, or partner ranges should be added when they are internal for your environment.
  6. Paste logs, drop a text file, browse for a LOG/TXT/JSONL/CSV file, or load the sample. Use Normalize spacing when copied syslog text includes extra blank lines.
  7. Read the warning area before relying on the tables. Empty input, unmatched deny tokens, and invalid CIDR values can make the queue look cleaner than the data really is.
  8. Use the route visual as a quick check on the strongest current pattern, then compare the Deny Snapshot, Deny Hotspots, Rule Review Queue, Parse Ledger, and Source Service Heatmap. The summary should show a deny count, watched-port count, hotspot count, top direction, and log family before the result is ready to share.

If the result will be shared, use the copy, CSV, DOCX, chart image, chart CSV, or JSON export that matches the audience. Remove sensitive addresses, policy names, and host clues before sending evidence outside the team that owns the logs.

Interpreting Results:

The Deny Snapshot is the first confidence check. Parsed deny events show how many lines matched the current tokens. Ignored non-deny lines show allowed rows, CSV headers, or unmatched events that were kept out of the deny count. Unparsed lines show where the input did not yield enough structured fields.

Deny Hotspots groups denied traffic by source, destination, protocol, and destination port. High-count rows point to repeated paths, while the share column shows how much of the pasted slice each group represents. A hotspot row should stay connected to the original policy, line numbers, and source-owner evidence before any firewall exception is considered.

Rule Review Queue translates the same groups into a review order. The priority label is based on the score calculated from count, direction, watched-port status, and repeat threshold. It is not a threat-intelligence verdict and it does not replace change history or endpoint investigation.

Result pattern Likely reading Check before acting
Watched repeated deny A source-service group crossed the repeat threshold and touched a watched destination port. Confirm whether the service should ever be reachable from that source.
Lateral deny Both source and destination match configured internal CIDRs. Verify the CIDR list before treating the path as internal movement.
Unknown direction The row lacks enough valid address or CIDR evidence for path classification. Use the Parse Ledger to find missing source, destination, port, or CIDR data.
Dense heatmap cell One source and one service account for repeated denies in the visible sample. Compare the cell with source ownership, service criticality, and policy intent.
Many ignored lines The sample may include allowed rows, headers, or action words outside the token list. Adjust the log family or deny tokens before using percentages from the hotspot table.

The Parse Ledger is the audit trail for the pasted slice. Use it when a result seems surprising, when the queue is empty despite visible deny text, or when a policy name appears to be missing. Parser confidence should be settled before the result drives a ticket or rule change.

Technical Details:

Deny triage reduces varied firewall logs to a common traffic tuple. The most important fields are source address, destination address, protocol, destination port, action or verdict, policy or rule evidence, service name, and device context. Once those fields are normalized, repeated paths can be counted and ranked without treating every vendor format as a separate investigation.

Structured action and verdict fields deserve priority over raw message text because a log line can contain several words that look security-relevant. Allow-style words such as allow, accept, permit, and pass should prevent a row from being counted as denied when the structured decision says it was allowed. Raw text is still useful as a fallback for simple syslog rows that do not expose a separate action field.

Formula Core

Priority scoring is deliberately simple. It raises repeated, watched, and directionally sensitive deny groups while keeping the ingredients easy to audit.

priority = 2 × denies + directionWeight + watchPortBonus + repeatBonus

denies is the count for one source, destination, protocol, and destination-port group. watchPortBonus is 9 when the destination port is on the watch list. repeatBonus is 6 when the group count is greater than or equal to the repeat threshold. directionWeight is based on the inferred traffic path.

Rule Value Boundary
Ingress direction weight 7 Source outside the internal CIDRs, destination inside.
Lateral direction weight 6 Source and destination both inside the internal CIDRs.
Egress direction weight 4 Source inside the internal CIDRs, destination outside.
Perimeter direction weight 2 Source and destination both outside the internal CIDRs.
Unknown direction weight 1 Missing address data, invalid address data, or no usable CIDR list.
Priority label bands 9 / 16 / 24 Medium starts at 9, High at 16, and Critical at 24.

A group with four ingress SSH denies on the watch list and a repeat threshold of three scores 2 * 4 + 7 + 9 + 6 = 30, so it becomes Critical. That label means the pasted evidence deserves prompt review. It does not prove compromise, and it does not mean an allow rule should be added.

Parser and Field Map

Different firewall products name the same concepts differently. The parser accepts structured JSON records, key-value syslog, Cisco ASA deny messages, Linux packet logs, and simple CSV rows, then maps the observed fields into the same triage tuple.

Input shape Evidence commonly used Important limit
FortiGate-style key-value logs srcip, dstip, dstport, proto, action, policyid, service, and device names. A policy value explains the match, but change history is still needed before rule edits.
AWS Network Firewall or Suricata EVE JSON Source and destination IP/port fields, protocol, alert action, final verdict, signature, and firewall name. Alert action and final verdict can differ, so both pieces of evidence matter.
Cisco ASA deny syslog Deny messages with protocol, source interface/address/port, destination interface/address/port, and access-group evidence. Implicit denies may not appear unless logging is configured for the access control entry.
iptables, nftables, or UFW-style rows SRC, DST, SPT, DPT, PROTO, and block words such as UFW BLOCK. Kernel packet logs often lack a policy name, so line number and tuple evidence become more important.
CSV rows Headers such as src, dst, dport, proto, action, policy, and service. A detected header row is skipped from deny scoring and kept as ledger evidence.

Direction classification uses IPv4 CIDR containment. The default private ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Organizations that treat other prefixes as internal should add them before relying on ingress, egress, lateral, or perimeter labels.

The source-service heatmap is built from the top visible sources and top visible destination services. It is useful for spotting concentration in the pasted slice, but it is not a timeline, rate calculation, or reputation check.

Limitations and Privacy Notes:

The analyzer reads pasted text, dropped text, and browsed files in the browser. A selected file larger than 4 MB is rejected, and log contents are not uploaded for parsing, table generation, chart rendering, or exports.

Use focused samples rather than full raw firewall archives. Exported tables, chart files, DOCX reports, and JSON can contain internal IP addresses, policy names, rule names, signatures, and line-level evidence. Redact or limit distribution before sharing them outside the operational need.

The tool does not verify source reputation, user identity, NAT history, vulnerability exposure, asset ownership, or whether a firewall rule is correct. Treat the output as triage evidence to compare with SIEM searches, firewall configuration, change tickets, endpoint telemetry, and incident response notes.

Advanced Tips:

  • Keep the time window consistent. Hotspot shares are percentages of the pasted slice, not the whole firewall history. Compare runs only when the log source, time range, and filter are similar.
  • Tune deny tokens conservatively. Add vendor-specific block words when the Parse Ledger shows denied rows being ignored, but avoid adding allow, accept, permit, or pass unless you are testing a non-standard export.
  • Define internal CIDRs before trusting direction labels. Add routed cloud, VPN, data-center, partner, or lab prefixes that count as internal for your environment. A missing prefix can turn a lateral deny into ingress, egress, perimeter, or unknown.
  • Use display limits to keep review readable. Hotspot rows controls the visible top source-service groups and heatmap categories, while Parse ledger limit controls line-level evidence. The JSON export still carries the parsed deny events for deeper review.
  • Match the export to the audience. CSV is useful for tickets and SIEM follow-up, DOCX is useful for a compact review note, chart images are useful for showing concentration, and JSON is best when another analyst needs structured evidence.

Worked Examples:

Repeated lateral SMB: Three denies from 10.44.80.10 to 10.55.10.10 on TCP/445, with a repeat threshold of 3, become a watched repeated deny. The next check is source ownership and lateral movement context, not an immediate exception.

Inbound RDP noise: A row from 198.51.100.40 to an internal host on TCP/3389 becomes an ingress deny on a watched port. The block may be expected internet scanning, but repeated hits should still be compared with exposure path and source reputation data.

Outbound SSH attempt: A workstation denied on TCP/22 to an external address becomes an egress deny. The recommended review path is endpoint process evidence and change-ticket context before the traffic is allowed or suppressed as noise.

Parser mismatch: If visible deny rows produce zero parsed deny events, switch back to Mixed mode, check the deny tokens, and inspect the Parse Ledger. Rows may be ignored because the action field says permit, or they may be unparsed because the log shape lacks the expected source, destination, or port pattern.

FAQ:

Why are allowed rows visible in the Parse Ledger?

They are kept as parser evidence. Allowed, permitted, header, or unmatched rows do not count toward deny hotspots, but they help prove what was included in the pasted sample.

Can a Critical row be harmless?

Yes. Critical means the local scoring rules found a concentrated review signal. Known scanners, blocked vulnerability tests, expired access requests, and expected default-deny traffic can all score high.

Why did direction show as unknown?

Unknown appears when source, destination, or CIDR evidence is missing or invalid. Fix the internal CIDR list or inspect the source fields before using direction to rank the event.

Does the heatmap show time or rate?

No. The heatmap shows deny counts by source and destination service in the current sample. Use firewall logs or SIEM tooling for time-series rates and event windows.

What file size can I browse?

The browser file reader accepts one file at a time and rejects files larger than 4 MB. Use a focused log slice for review and keep the original export as the audit source.

Glossary:

Deny token
A configured action or verdict word that marks a row as denied traffic.
Watched port
A destination port that receives extra priority when denied traffic repeats.
Traffic tuple
The source, destination, protocol, and destination port used to group related deny events.
Lateral deny
A denied path where both source and destination match configured internal CIDR ranges.
Parse Ledger
The evidence table showing how each visible input line was parsed, ignored, or left unparsed.
Rule Review Queue
The prioritized list of source-service groups that deserve policy, ownership, or investigation review.

References: