Firewall Log Analyzer

Firewall logs cluster around two shapes: UFW's [UFW BLOCK] entries and iptables' DROP/ACCEPT prefixed lines, both stuffed with SRC= DST= PROTO= SPT= DPT= tokens. Firewall Log Analyzer pulls the signal out of either format — action, protocol, endpoints, ports, and interface — into aligned rows.

Ranked sources, destinations, and destination ports immediately expose repeated scan patterns and the services they were probing, while the action summary shows the allow/block split.

Under the hood, each line is first stripped of an optional leading timestamp and hostname (either syslog-style Jun 11 14:00:01 host kernel: or ISO 2025-06-11T14:00:01 host kernel:), then the remaining body is checked for a bracketed action like [UFW BLOCK] — the last word inside the brackets becomes the action — or, failing that, a bare leading token such as DROP, REJECT or ACCEPT the way plain iptables LOG rules emit it. Whatever is left is scanned for KEY=VALUE pairs, so IN=, OUT=, SRC=, DST=, PROTO=, SPT= and DPT= are picked up regardless of their order or which other keys (MAC, LEN, TOS, TTL, flags like SYN/ACK) sit alongside them. Lines that carry none of kernel:, IN=, SRC=, DST= or PROTO= are skipped rather than misparsed, so pasting a mixed syslog dump only pulls out the actual firewall events.

• UFW + iptables — both kernel formats, with or without timestamp/hostname prefixes.
• Token extraction — SRC, DST, PROTO, SPT, DPT, IN/OUT parsed as key/value pairs.
• Action taxonomy — blocked (BLOCK/DROP/REJECT/DENY/INVALID) vs allowed (ALLOW/ACCEPT), with per-action counts.
• Scan rankings — top source IPs, top destination IPs, top destination ports and top source ports.
• Protocol mix — TCP/UDP/ICMP breakdown alongside the endpoint rankings.
• Copyable report — plain-text summary ready for a ticket.
• Local only — nothing uploaded, the whole log stays in the browser tab.

1. Paste firewall lines — UFW or iptables, raw kernel ring output or already-extracted syslog/journal lines.
2. Analyze. Every recognizable line aligns into a time/action/protocol/endpoint/port row; rankings render below it.
3. Scan the blocked list and top target ports — a single port dominating the list usually means one service is being probed repeatedly.
4. Copy the report for the ticket, incident writeup, or a firewall rule change request.

Example 1 — Port scan. A single source appearing in the top-sources ranking while one destination port dominates the top-ports list is the classic scan signature — for example dozens of DPT=22 hits from one address means an SSH brute-force sweep, not routine traffic.

Example 2 — Policy check. The allow/block split confirms whether a rule change actually took effect — if you tightened a security group and still see ALLOW entries for the port you closed, the rule did not deploy the way you expected.

Example 3 — API hardening. Repeated DPT=22 or DPT=3389 attempts with varied source IPs surface distributed brute-force sweeps that a single-source view would miss, since each individual IP looks low-volume on its own.

Example 4 — Interface sanity check. Comparing the IN/OUT interface on ALLOW rows against your expected topology (for example traffic that should only ever arrive on a VPN interface) catches misrouted or spoofed packets before they become an incident.

• Format-agnostic — UFW and iptables in one pass, no need to pre-normalize the log.
• Endpoint clarity — who hit whom, on what port, over which protocol.
• Action aware — allowed traffic is separated from blocked, so policy questions get a direct answer.
• Scan radar — source, destination and port rankings expose repeated-hit patterns a raw log hides.
• Private — all processing happens client-side; nothing is sent to a server.