Access Log Forensics Skill

access-log-forensics

A Claude Code skill that performs forensic triage of Apache/Nginx access logs (combined log format) and produces a short, evidence-backed incident report.

Installation

Copy this folder into one of Claude Code's skill directories:

# per-project
cp -r access-log-forensics .claude/skills/

# or globally, for all projects
cp -r access-log-forensics ~/.claude/skills/

Usage

Invoke it explicitly:

/access-log-forensics analyze /var/log/apache2/access.log

Or just ask naturally — Claude picks the skill up automatically when the request matches its description:

Can you check attack.log for signs of an attack?

What it does

0. Runs scripts/redact.sh first: client IPs are replaced with stable pseudonyms (ip-042) before any log content enters the LLM conversation (GDPR data minimization). The pseudonym↔IP mapping is written to <logfile>.ipmap.tsv (chmod 600) and stays on your machine — resolve a pseudonym locally with grep -P '\tip-042$' <logfile>.ipmap.tsv. All later steps operate on <logfile>.redacted only.
1. Runs scripts/summarize.sh for one-pass baseline stats (timeframe, status codes, top IPs with error/URL counts, user agents, paths, req/min peaks).
2. Sweeps the log for attack signatures (SQLi, path traversal, WordPress/Drupal probing, secret hunting, XSS, scanner user agents).
3. Applies behavioral heuristics (distributed floods, scraping, brute force, attempted vs. successful attacks).
4. Writes forensics-report.md — capped at one page / ~400 words, with a verdict, key findings, notable source IPs, and prioritized actions.

GDPR notes

Practical guidance, not legal advice — for public-sector or high-volume processing, involve your DPO.

What's legitimate:

• IP addresses in access logs are personal data (CJEU C-582/14, Breyer), but analyzing them for attack forensics is expressly covered: Recital 49 GDPR names network and information security as a legitimate interest (Art. 6(1)(f)). You do not need consent to investigate a DDoS, brute force, or intrusion attempt.
• Keeping logs for a limited, defined retention period for security purposes is fine; so is blocking or rate-limiting the offending IPs.
• Sharing pseudonymized logs (this skill's .redacted output) with an LLM is a strong data-minimization measure (Art. 5(1)(c)): the analysis works identically, and no real IP leaves your machine.

What needs care:

• Sending raw logs to a cloud LLM makes the provider a processor and, for US processing, a third-country transfer (Chapter V). That requires a DPA and a transfer mechanism (SCCs / EU-US Data Privacy Framework) with the provider, recorded in your records of processing — and note that consumer chat plans and commercial/API terms differ on data handling. Redacting first (step 0) sidesteps most of this.
• The .ipmap.tsv mapping file re-identifies every pseudonym: treat it like the raw log (restricted access, same retention, never share or upload it).
• Purpose limitation: logs collected for security should not be reused for marketing/analytics profiling without a separate legal basis.

What isn't legitimate:

• Publishing or sharing reports containing real client IPs beyond those who need them (use the pseudonymized report; resolve IPs only where action requires it, e.g. a firewall block or an abuse report to the ISP).
• Keeping raw logs indefinitely "just in case" — set and document a retention period.
• Enriching log IPs with third-party data to identify individual people (as opposed to identifying attack infrastructure) — that exceeds the security purpose.

Requirements

Standard Unix tools only: bash, awk, grep, sort, uniq. The script can also be run standalone without Claude:

bash scripts/summarize.sh /path/to/access.log