{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
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.
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
Keep this low for short incident samples and higher for noisy daily exports.
denies
Keep enough rows to prove parser coverage without making the tab unwieldy.
lines
{{ header }}Copy
{{ cell }}
No rows for the current input.
Tags: Networking, Security
Export to PDF Fullscreen
Customize
Advanced
:

Firewall deny logs record traffic that a policy, rule, or packet filter refused. A single line may show the source address, destination address, protocol, destination port, policy, device, and action that produced the block. Those details matter because repeated blocks to a watched service can mean something very different from a one-off deny to an unused port.

During incident triage, access-request review, and firewall cleanup, the first useful question is usually where the denied traffic is concentrated. A source repeatedly hitting SMB, RDP, SSH, or a database port deserves a faster look than a scattered set of low-volume perimeter drops. Counts help, but only when they stay tied to the original direction, service, and policy evidence.

Flow diagram showing firewall deny lines parsed into fields, classified by direction, scored by repeated watched services, and summarized for rule review.

Denied traffic is not automatically malicious. Default-deny rules, expired change windows, misconfigured clients, and scanning activity can all create the same broad action words. The useful review keeps the block evidence close to business context: who owns the source, whether the destination service should be reachable, whether the policy already explains the denial, and whether the pattern repeats enough to need action.

A good deny review also protects against the opposite mistake: ignoring a noisy set of blocks because each line looks routine. Lateral SMB denies between internal networks, repeated RDP from the internet, and outbound SSH from a workstation are all worth checking before changing a firewall rule or closing an alert.

Technical Details:

Firewall deny analysis starts by reducing mixed log rows to a common event shape. Key-value traffic logs, JSON alert records, Linux packet-log rows, and simple CSV records can all describe source, destination, protocol, port, action, policy, service, device, and reason with different field names. The review becomes reliable only after those names are normalized enough to compare the same source-service pair across formats.

Deny detection depends on action wording. Events are counted as denied when the action, verdict, event type, or raw row contains a configured deny token such as deny, drop, reject, blocked, or block. Allow-style words such as allow, accept, permit, and pass prevent raw-text fallback from turning ordinary allow rows into deny events when no action-field deny token matched.

Direction classification is based on IPv4 CIDR membership. The default private ranges are the RFC 1918 blocks 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. A source and destination inside the configured ranges is treated as lateral traffic. External to internal is ingress, internal to external is egress, both outside is perimeter, and missing or invalid address data becomes unknown.

Rule Core

Hotspots are grouped by source, destination, protocol, and destination port. Each group receives a simple priority score so repeated watched services rise above scattered low-volume blocks.

Score component Points When it applies
Deny count 2 per deny Every matched deny event in the same source, destination, protocol, and port group.
Watched service 9 The destination port appears in Watch ports, such as 22, 445, 3389, or 1433.
Repeat threshold 6 The group count is greater than or equal to Repeat threshold.
Ingress direction 7 The source is outside the internal CIDRs and the destination is inside.
Lateral direction 6 Both source and destination are inside the internal CIDRs.
Egress direction 4 The source is inside the internal CIDRs and the destination is outside.
Perimeter or unknown direction 2 or 1 Both addresses are outside the internal CIDRs, or the row lacks enough address data to classify the path.

The priority label comes from the final score, not from a threat-intelligence lookup. Critical starts at 24 points, High starts at 16, Medium starts at 9, and anything below 9 is Low. That makes the label a review queue signal, not proof that a source is hostile or a rule should be changed.

Input shape Common fields used Important caution
FortiGate-style key-value logs srcip, dstip, dstport, proto, action, policyid, service, and devname. A policy value of 0 or an unmapped policy can still be useful evidence, but it needs owner review before policy changes.
AWS Network Firewall or Suricata EVE JSON src_ip, src_port, dest_ip, dest_port, proto, alert.action, verdict.action, and alert.signature. An alert action and final verdict can differ, so both action and verdict fields are considered when detecting dropped or blocked traffic.
iptables, nftables, or UFW-style rows SRC, DST, SPT, DPT, PROTO, and block words such as UFW BLOCK. Kernel packet logs often omit policy names, so source, destination, port, and line evidence become more important.
CSV rows Headers such as src, dst, dport, proto, action, policy, and service. A detected header row is skipped and appears in the parse ledger instead of being counted as traffic.

Service labels are derived from an explicit service field when present; otherwise common destination ports are named with familiar service labels such as SSH, SMB, RDP, MSSQL, MySQL, PostgreSQL, Redis, and HTTPS. Unrecognized ports still remain visible as protocol and port pairs, so review does not depend on a complete service dictionary.

Everyday Use & Decision Guide:

Start with a focused firewall slice around one alert, change window, interface, source group, or policy question. Paste rows into Firewall deny logs, drop a supported text file, or choose Browse log. The file reader accepts one LOG, TXT, JSON, JSONL, or CSV file at a time and stops at 4 MB, so large daily exports should be filtered before review.

Leave Log family on Mixed syslog / JSON / CSV unless a handoff note needs to show a specific family label. The current parser still accepts JSON, key-value rows, and CSV-like records in the same run. If a vendor export uses unusual field names, Parse Ledger is the fastest place to check whether source, destination, port, action, and policy were extracted as expected.

Keep Deny action tokens narrow. Values such as deny, drop, reject, blocked, and block match common firewall wording. Do not add allow-style words unless the input is a special export where permit rows really mean blocked traffic.

  • Set Watch ports to services your team reviews quickly, such as SSH, Telnet, SMB, RDP, MSSQL, MySQL, PostgreSQL, or another sensitive internal port.
  • Keep Internal CIDRs aligned with the network being reviewed. Add routed private ranges, lab prefixes, or site-specific blocks when the default private ranges do not cover the environment.
  • Use Hotspot rows to control visible table and heatmap size. The JSON output keeps the parsed deny evidence even when the table is capped.
  • Lower Repeat threshold for a short incident excerpt. Raise it for noisy daily exports so one or two expected blocks do not crowd the review queue.
  • Increase Parse ledger limit only when parser evidence needs more row-level proof. It affects display length, not the aggregate deny counts.

Read Deny Snapshot first. It shows parsed deny events, ignored non-deny lines, unparsed lines, watched-port denies, top direction, and top hotspot. Then use Deny Hotspots for source-to-destination-service concentration and Rule Review Queue for the recommended follow-up wording.

A high-priority row should slow down rule changes, not speed them up blindly. Confirm source ownership, destination service owner, policy intent, and related alerts before relaxing a block. For unknown-direction rows, fix missing source, destination, or port extraction before drawing conclusions from the score.

Step-by-Step Guide:

Use one review question per run so the summary describes a coherent firewall slice.

  1. Choose Log family. Use Mixed syslog / JSON / CSV for most pasted excerpts, or select FortiGate traffic logs, AWS Network Firewall / Suricata EVE, or iptables / nftables style when the label should match the source export.
  2. Check Deny action tokens. If the summary later says No denied, dropped, rejected, or blocked events matched the configured deny action tokens, compare the source action wording against this field.
  3. Set Watch ports to the services that should rise in the queue. Ports can be comma-separated values or ranges, and invalid text is ignored rather than treated as a service.
  4. Set Internal CIDRs. If the page reports Ignored invalid internal CIDR value(s), correct the bad prefix before trusting ingress, egress, lateral, perimeter, or unknown direction labels.
  5. Paste rows into Firewall deny logs, choose Browse log, drop a supported file, or press Load sample. Use Normalize spacing when copied rows contain blank gaps or trailing spaces.
  6. Open Advanced when the visible result needs tuning. Set Hotspot rows, Repeat threshold, and Parse ledger limit before reviewing the tabs.
  7. Read the summary and Deny Snapshot. Confirm that Parsed deny events, Ignored non-deny lines, and Unparsed lines match the slice you expected.
  8. Open Deny Hotspots for grouped source, destination service, direction, share, policy, signal, and recommended action. Use Rule Review Queue when you need the same evidence arranged by priority.
  9. Use Source Service Heatmap when many sources touch several destination services, then keep Parse Ledger nearby for row-level evidence before handing off any rule review note.

Interpreting Results:

The most important result is the top hotspot, because it combines source, destination service, direction, count, watched-port status, policy, and recommended action. A single repeated lateral SMB deny can deserve more attention than a larger set of unrelated perimeter drops when the source and destination are both inside the network.

Do not read Critical, High, Medium, or Low as threat certainty. The label means the group matched scoring conditions such as watched port, repeat count, and direction. It does not confirm compromise, approved change intent, or whether a firewall exception should be added.

Visible cue Best first reading What to verify next
Parsed deny events is zero No row matched the configured deny action tokens. Check action wording, JSON verdict fields, and whether the excerpt contains allow or permit rows instead.
Watched-port denies is high Many denied events hit ports the team marked for closer review. Confirm that the watch list reflects current policy and not only default demo ports.
Top direction is Lateral deny Internal-to-internal blocks dominate the current slice. Check host ownership, segmentation intent, and whether the denied service should be reachable at all.
Unparsed lines is greater than zero Some rows stayed in evidence but did not produce structured source, destination, or port fields. Fix row format or narrow the input before using the queue in a ticket.
Source Service Heatmap has one strong cell One source-service pair dominates the displayed top sources and services. Compare that cell with Deny Hotspots and original line numbers before deciding whether it is scanning, misconfiguration, or expected policy enforcement.

A quiet run is also limited. If Deny Snapshot looks clean but the source alert came from another system, widen the time range, add the missing internal CIDRs, adjust deny tokens, or confirm that the firewall actually logged the action you meant to review.

Worked Examples:

Mixed sample with lateral SMB and watched ports

The sample input contains FortiGate-style key-value rows, one AWS or Suricata-style JSON alert, a UFW block row, a raw blocked egress row, a CSV header, a CSV drop row, and one permit row. With default deny tokens, watch ports, internal CIDRs, and repeat threshold, Deny Snapshot reports 7 parsed deny events, 2 ignored non-deny lines, 0 unparsed lines, and 7 watched-port denies. The top hotspot is 10.44.80.10 -> 10.55.10.10 SMB (TCP/445) with 2 deny events and a Watched service signal.

Ingress RDP from a public source

A Linux-style row such as [UFW BLOCK] SRC=198.51.100.40 DST=10.44.90.50 PROTO=TCP SPT=49152 DPT=3389 becomes an ingress deny when 10.44.90.50 is inside Internal CIDRs. With 3389 in Watch ports, Rule Review Queue can label the row High even with one deny event. That means the exposure path and source reputation should be checked before relaxing the block.

Repeat threshold boundary

Two denies from one workstation to 10.55.10.10 SMB (TCP/445) can still be high because SMB is watched and the path is lateral. With Repeat threshold at 3, the signal remains Watched service. If a third matching deny appears, the same group changes to Watched repeated deny, gains the repeat bonus, and may move above other rows in Rule Review Queue.

Bad CIDR before policy review

If Internal CIDRs contains 10.0.0.0/8,172.16.0.0/33, the invalid prefix is ignored and an error appears. Direction labels may still be produced from the remaining valid range, but ingress, egress, and lateral counts can be wrong for networks that depended on the bad prefix. Correct the CIDR, then compare Top direction and Deny Hotspots again before using the output in a rule-change discussion.

Responsible Use Note:

Firewall deny rows can contain internal addresses, device names, policy identifiers, hostnames, and enough timing context to reveal network design. Paste only the slice needed for the review, remove unrelated sensitive values when possible, and keep copied tables or JSON output inside the same handling rules used for security logs.

The analysis is a triage aid. It groups and scores deny evidence already present in the supplied rows, but it does not query firewall state, inspect packets, validate whether a source is hostile, or confirm whether a rule exception is approved.

FAQ:

Does the analyzer upload my firewall logs?

No. Pasted rows and selected file contents are parsed in the browser. The tool does not send the log text to a server for the analysis, but the result should still be handled as sensitive security data after you copy or download it.

Why did an allowed row appear in the parse ledger?

Parse Ledger keeps non-deny evidence visible so you can confirm why rows were ignored. Allow, accept, permit, pass, CSV header, and unmatched rows can appear there without contributing to Parsed deny events.

Can this replace a SIEM search or firewall audit?

No. It is best for a focused triage slice where you need source, destination service, direction, watch-port, and policy evidence quickly. Use your SIEM, firewall manager, asset inventory, and change records to confirm scope and owner context.

Why are some rows marked as unknown direction?

Unknown direction usually means the row lacks a source, destination, or valid internal CIDR basis for classification. Check field extraction in Parse Ledger, then correct Internal CIDRs or the source row format.

Which input format should I choose first?

Use Mixed syslog / JSON / CSV first unless the result needs a source-family label for handoff. Then inspect Deny Snapshot and Parse Ledger to confirm that deny counts, ignored lines, and extracted fields match the source excerpt.

Glossary:

Deny event
A row whose action, verdict, event type, or raw text matches the configured deny tokens.
Watched port
A destination port that should rise in the review queue when denied traffic repeats or points to a sensitive service.
Lateral deny
A denied flow where both source and destination are inside the configured internal CIDR ranges.
Ingress deny
A denied flow from outside the internal CIDRs toward an internal destination.
Egress deny
A denied flow from an internal source toward a destination outside the internal CIDRs.
Hotspot
A grouped source, destination, protocol, and port combination used for counts, priority scoring, and recommended action text.

References: