How to Check a Suspicious IP Address in Your Server Logs Before You Block It

An unfamiliar IP address appears in your server logs, hitting your login page again and again, or probing pages that do not exist. The instinct is to block it at once. Sometimes that is the right call. Sometimes the same block locks out a whole office or mobile network, while the attacker moves to another address. A five minute check tells you which case you are looking at, and gives you evidence for a report if one is needed.

Start with what the log line actually says

One log line is rarely enough. Look at the pattern around it: how many requests, over how long, asking for what, with what result, and with what user agent?

A single visit from an unknown address is not suspicious on its own: people travel and use VPNs. A pattern is different: dozens of failed logins in a few minutes, or repeated requests for admin pages, backup files, or environment files. Note the first and last times, and keep the raw log lines. If you report the address later, the exact times and requests matter far more than your summary, and times should be in UTC so the receiving network can match them.

Also check whether the address is yours, or a service you run: your office IP, a monitoring service, or a search engine crawler can all look strange until you recognise them.

Step 1: Look up who owns the address

Run the address through our IP Location Lookup. You will get the organisation the block is assigned to, usually a provider or hosting company, the network number that announces it, known as the ASN, and an approximate location, usually a country and sometimes a city.

Read that as a classification, not an identification: residential broadband, mobile carrier, cloud or hosting company, or a network in another country. A login attack from a hosting ASN, where no ordinary visitor would sit, reads differently from the same requests from a residential provider where your customers live. The ASN also names the network to contact in a report.

Do not over-read the location. A lookup shows where the provider registered the block, not where a person is sitting, and city results can be well off, especially on mobile. It never reveals a name, a street address, or browsing history. Only the provider knows which customer used an address at a given time, and it discloses that only through a legal process.

Step 2: Check the reverse DNS name, then check it back

Next, run the same address through our Reverse DNS Lookup. It asks for the PTR record, the hostname the owner attached to the address. Normal DNS turns a name into an address; reverse DNS turns an address back into a name.

A generic generated name, the kind cloud providers assign by default, suggests a rented server rather than a home connection, which fits automated scanning. No PTR record at all is normal for many home and mobile connections, so its absence proves nothing. A hostname claiming to belong to a well-known service should not be trusted on the name alone, since anyone can set a PTR record to say almost anything. The check that matters is forward confirmation: resolve the hostname and see whether it points back to the same address. If it does not, treat the name as unproven and lean on the behaviour in the logs.

Step 3: Read the behaviour and the network together

Combine the two checks with the log pattern, and work through these questions in order.

Is it doing something harmful, repeatedly? Repeated failed logins, password guessing across many usernames, or probing for files and admin paths is abuse, whatever the network looks like.

Is it a service you recognise? A hostname and ASN matching a search engine, monitoring tool, or service you use, with requests that fit that service, is usually legitimate. If unsure, check the provider's own documentation for verifying its crawlers, and compare the ASN rather than trusting the hostname alone.

Could one block hit many innocent people? Many users share one public address behind carrier-grade NAT on mobile networks, and whole offices sit behind one address. Blocking it for one device's behaviour can lock out everyone sharing it. If the lookup shows a mobile carrier or large residential provider and the behaviour is unclear, rate limiting is safer than a full block.

Does it look automated? Requests at a steady machine pace, at all hours, with no normal browsing around them, point to a script. Requests mixed with normal browsing or a completed form are more likely a real person on a shared connection. When the pattern is mixed, watch first and block later.

Step 4: Block, slow down, watch, or report

Match the response to the evidence. For clear, repeated abuse from a hosting ASN, a block is reasonable, but start with a temporary one: it stops the noise and expires on its own if you misjudged. Tools that watch logs and ban automatically, such as Fail2ban, ban an address after a set number of failures in a set window, for a set time. Add your own addresses and monitoring services to the allow list first, so a mistyped password cannot lock you out.

For unclear behaviour, rate limiting is the middle path: slowing requests to the login path protects the service without cutting off a shared network. For a single suspicious visit with no repeat, watching is enough.

For serious or repeated abuse, report it as well as blocking it. Most providers publish an abuse contact for their address blocks. A useful report is short: the address, the exact UTC times, the requests made, and the raw log lines. State what you saw, not what you concluded about the person behind it. You can also run the address through our Blacklist Checker for context, though a clean result does not clear an address attacking your site now. Blocking stops your problem; reporting may stop it bothering the next site.

What to do first

Do not block on a country, a city, or a single log line. Check the log pattern, look up the network and ASN, check the reverse DNS name and whether it resolves back, then choose the smallest response that fits: watch, rate limit, temporarily block, or report. Keep the log lines and UTC times. The five minute check tells obvious automated abuse apart from ordinary traffic on a shared network, which a block would punish unfairly.