Incident Response IP Triage: A Fast Checklist

An IP address on its own is the least informative part of an alert. Before enriching it, read the event that produced it: the WAF rule or detection that fired, the endpoint and method, the user agent, the headers, the payload category and the exact time. The same address can appear in harmless and harmful events within the same minute, so the address only means something in the context of what it did.

NIST's incident response guidance (SP 800-61 Rev. 3) frames response as a cycle that runs from preparation through detection and analysis to containment, eradication, recovery and lessons learned. IP triage sits in the analysis step: its job is to turn an alert into a decision about scope and action, quickly and reversibly, while preserving what a later investigation will need.

Record the timestamp in UTC using the RFC 3339 format, and note the timezone of any log you copied it from; incidents that span systems in different zones lose hours to conversion mistakes. Record the request ID or correlation ID, the full headers, the endpoint, the account or session involved, the user agent and the observed behavior.

Record the source IP together with how it was determined. If the request passed through a load balancer, CDN or proxy, the socket address is the proxy and the client address came from a forwarded header; the X-Forwarded-For guide explains which value to trust. An investigation built on the wrong address blocks the wrong thing.

Preserve the raw logs before you enrich anything. NIST SP 800-86, on integrating forensic techniques into incident response, describes the sequence as collection, examination, analysis and reporting, and stresses keeping the original data unaltered and documenting who handled it and when. Copy the relevant log segments to a location where retention and access are controlled, hash the copies, and work from the copies.

Ownership and abuse contact. An RDAP query returns the registered network range, the organization and the abuse contact for the address, in the JSON format defined in RFC 9083. The WHOIS and RDAP guide walks through a query, and the abuse contact guide covers what to send.

ASN. The autonomous system tells you what kind of network the address sits in: a consumer ISP, a mobile carrier, a hosting provider, a corporate network. That shapes both the likely explanation and the blast radius of a block; see the ASN lookup guide.

Geolocation. Country is usually right, city is an estimate, and the coordinates are the center of an area, not a building. Treat location as context for whether the traffic is plausible for the account, and read the accuracy guide before quoting a city in a report.

Reputation. Blocklist hits, recent abuse reports and a high fraud score raise the prior that the traffic is hostile. They are indicators about the address's recent history, not evidence about the request in front of you, and a shared address inherits whatever its last occupant did.

Reverse DNS. The PTR record for the address, from the in-addr.arpa or ip6.arpa tree defined in RFC 1035, often names the provider or the host role. A hostname that says the address is a residential pool, a mail server or a cloud instance is useful context; the reverse DNS guide explains how to read it and why it can be missing or misleading.

Tor, VPN and proxy indicators. The Tor Project publishes a list of current exit relay addresses, and commercial data flags VPN exits and open proxies. Anonymized traffic is not itself an attack, but it changes what a block would achieve: the person behind it will be on a different address in a minute. The VPN and proxy checker shows which flags apply.

History. Search your own logs for the address, its /24 and its ASN over the preceding weeks. Clusters, such as the same ASN, the same endpoint, the same payload, or repeated targeting of one account, are what turn a single alert into a pattern worth acting on.

A WAF alert records that a request matched a rule, not that the request was malicious. Rules that inspect for SQL injection or path traversal fire on legitimate input all the time: a customer pasting a code snippet into a support form, a search for a product name that contains a quote character, a security scanner you hired. Check the rule's history in your environment before treating a match as hostile, and look at what the same address did around it.

The contrast that matters is between a hosting address probing administrative URLs it was never linked to, and a logged-in customer who triggered one rule once in a normal session. The first is a pattern; the second is a tuning item. Keep examples of both, with the request details, so the next analyst can tell them apart faster.

If the request touched an account, the account is where the answer is. Was there an authenticated session, and how old is the account? Did the activity follow a password reset, a new device or a change of recovery email? Did it go straight for the things account takeover is for: payout details, data export, API key creation? Compare the address with the account's own history; an unfamiliar country is a weak signal on its own and a strong one alongside a new device and a recovery-email change. The impossible travel guide covers how to weigh distance against those signals.

The options run from doing nothing, through monitoring, challenging the traffic and tuning the rule, to blocking one address, blocking a range, blocking an autonomous system, and escalating to legal or abuse reporting. Choose the narrowest control the evidence supports.

One IP is right when the abuse is coming from a single dedicated host. A CIDR range is right only when your logs show the abuse spread across the range; blocking a /24 because one address in it misbehaved takes out up to 254 unrelated hosts. An ASN block removes every customer of that network and belongs to consumer-only surfaces facing a hosting provider whose traffic you never expect, never to a residential or mobile ASN. The firewall blocking guide goes deeper on scope.

Make the block temporary by default. Attackers move addresses within hours, while the address you blocked returns to an ISP pool and is handed to someone else. Set an expiry, put the rule on a review list, and record the reason code and the incident reference with it, so that a rule nobody remembers cannot outlive the incident that created it. For shared addresses, mobile gateways and carrier NAT ranges, prefer a challenge or a rate limit to a block; the CGNAT guide explains how many people one address can represent.

For every action, write down what was observed, what was decided, who decided it, when it takes effect and when it expires. Store the preserved log copies, their hashes and the enrichment results at the time of the decision, because RDAP records, reputation scores and geolocation data all change, and a review months later needs to know what you saw, not what a lookup says now. NIST SP 800-92 covers protecting the logs themselves: restricted access, integrity checks and a retention period that matches how long incidents take to surface.

If the incident may involve law enforcement or a dispute, keep a chain of custody for the evidence from the start; it is far easier to maintain than to reconstruct.

The commonest false positives are structural rather than malicious: a carrier NAT address shared by thousands of subscribers, a corporate egress point, a partner's integration server that changed address, a monitoring service you forgot about, a mobile gateway that places a customer in the wrong city, or a penetration test someone else in the company commissioned. Each looks alarming in isolation and obvious in context.

Build the reversal path before you need it: a way for a blocked customer to reach support, a review of expiring rules, and a habit of checking what else lives behind an address before acting. A narrow, reversible control applied quickly is almost always better than a broad one applied with certainty you do not have.