A persistent SSH scanner won’t stop. An open relay keeps hammering a customer’s contact form. A pile of failed logins all trace back to a /24 you’ve never seen before. The fix is rarely to add another firewall rule — by the time you’re writing rules for individual addresses, you’ve already lost. The fix is to find the network operator responsible for that range and escalate. The PortJar IP WHOIS & ASN tool tells you exactly who to contact, in one query.
What the tool does
It runs a WHOIS query against the regional internet registry (ARIN, RIPE, APNIC, LACNIC, AfriNIC) for the address, parses out the allocation range, the assigned organisation, and the abuse contact email, and pairs that with the ASN ownership from Team Cymru. The output is the answer to “who allocated this IP block, to whom, and what is the autonomous system carrying its traffic” — which is the level at which abuse reports, takedown requests, and BGP escalations are handled.
How to use it
Open portjar.com/tools/ip-whois, paste the offending address, and submit. The tool returns the registry record and the ASN side-by-side. The abuse-mailbox (or OrgAbuseEmail / irt: block depending on registry) is the address to write to. The ASN gives you a fallback path: if abuse mail bounces or goes unanswered, the upstream peering relationships of that AS are public record and can be used to escalate.
When you’d reach for it
- Writing a non-junk abuse report. Abuse desks at hosting providers and ISPs ignore mail that doesn’t include the offending IP, a timestamp with timezone, the affected service, and log excerpts. IP WHOIS gives you the right recipient so the report doesn’t sit unread in a generic
info@mailbox. - Recognising a hostile hoster. Some networks are notorious for sheltering scanners and credential-stuffing operations. Seeing the same ASN repeatedly in your block lists is a signal to consider blocking the entire AS at the edge rather than playing whack-a-mole with individual /24s — the PortJar ASN Lookup tool will tell you the prefix list to use.
- Verifying a customer’s claim that they own an address. A client says “rule 22.33.44.55 in — that’s our office.” WHOIS tells you whether that address is allocated to their organisation, their ISP’s pool, or a completely unrelated network — which is the difference between a long-lived allowlist and one that breaks the next time a DHCP lease rotates.
- Triaging traffic from a “scanner” that turns out to be a legitimate research project. Networks like Censys, Shodan, BinaryEdge, and university security groups are documented in WHOIS with explicit research contact information. Recognising them prevents over-blocking infrastructure that the security community relies on.
- Tracing the upstream behind a DDoS or sustained probe. When you need to escalate beyond the immediate hoster, the registry record names the parent allocation; the ASN tells you the immediate carrier; together they give you two paths to find a human.
What to make of the output
The WHOIS record reflects allocation, not the current tenant. A large hosting provider may have been assigned a /16 by ARIN, and may then sublet /28s to thousands of customers — WHOIS will name the provider, not the customer. That’s fine: the abuse contact at the provider is the right escalation path, because they have the contractual relationship with the actual tenant and the operational ability to suspend them. Read the created and last-modified dates to confirm the allocation is current; very old records sometimes name organisations that have since been acquired or dissolved. When the WHOIS and ASN disagree on who’s “in charge” — for example, an address allocated to a small ISP but announced by a major transit carrier — both are correct, and your abuse report should go to the ISP, not the transit carrier.
For environments where source-IP investigations need to feed back into firewall policy, allowlists, and abuse-handling runbooks, Stack Harbor weaves these checks into monitoring and support.