DEV Community: Greg B

Logged My Traffic for 24 Hrs One IP Hit Me 13,000

Greg B — Fri, 10 Apr 2026 18:43:28 +0000

I’ve been working on a small side project to analyze traffic logs and surface bot activity in a way that’s actually useful.

Not a full security platform. Just something simple that answers:

who is hitting my site
how often
and what they’re trying to access

I pointed it at one of my endpoints and let it run.

Here’s what showed up in a short window:

20.48.232.178 → 13,777 hits
20.104.201.101 → 7,916 hits
20.151.229.110 → 7,427 hits
20.220.232.240 → 7,096 hits
20.220.213.131 → 5,188 hits
162.158.62.142 → 2,979 hits
104.23.253.15 → 2,926 hits
162.158.154.75 → 2,616 hits

Most of these were hitting common scan paths like:

/scanner.php
/wp-admin
random probe endpoints

Nothing fancy. Just constant noise.

What stood out

It wasn’t one attacker. It was volume.

Thousands of requests from single IPs. Repeated scans. Same patterns over and over.

If you’re not looking at raw logs, you don’t really see it.

And most small projects don’t have anything in place to filter or summarize this.

What I built

I put together a lightweight tool that:

logs traffic
aggregates hits per IP
tags common scan patterns
surfaces “top offenders” quickly

No heavy infra. Just a small service and a database.

The goal wasn’t to block everything automatically.

It was to make the data obvious enough that you can decide what to do:

block at firewall
add nginx rules
ignore known noise
or just understand what’s hitting your app
Why this matters (especially early)

If you’re running:

a side project
a VPS
a self-hosted app

you’re getting hit like this too.

You just don’t see it yet.

Free access (early users)

I’m opening this up for testing.

First 100 people can use it free for 3 months.
No credit card.

Code: DTO2026
https://blockabot.com

After that it’s around $5/month for full access (logs, threat feed, etc).

This Is What’s Really Hitting Your Website (Hint: Not People)

Greg B — Thu, 02 Apr 2026 23:38:01 +0000

This Is What’s Really Hitting Your Website (Hint: Not People)

I wanted to understand how much of our traffic was actually human, so I pulled and analyzed 48 hours of raw request logs.

No filters, no analytics layer, just direct log data.

Time Frame

Start: 2026-03-31 10:00 UTC
End: 2026-04-02 10:00 UTC

All requests within that window were grouped by path patterns and behavior.

Traffic Breakdown

Requests were classified into four categories:

WordPress probing (paths containing wp)
XMLRPC access attempts
PHP endpoint probing
General scanning and enumeration

Results:

WordPress probes: 34 percent
XMLRPC attempts: 18 percent
PHP probes: 27 percent
Other scanning: 21 percent

Roughly 79 percent of requests were not normal user activity.

Sample of Active IPs

Below is a subset of IPs with the highest request volume or repeated attack patterns during the window:

185.220.101.45 WordPress login brute force patterns
45.146.165.12 XMLRPC pingback attempts
103.248.70.33 PHP endpoint scanning
91.134.23.198 Multi-path probing (/admin, /login, /.env)
176.65.148.92 High-frequency requests consistent with botnet behavior
198.54.117.210 Credential stuffing attempts
5.188.62.76 Known scanner signature patterns
194.147.142.88 Repeated wp-login hits
212.83.150.120 PHPMyAdmin probing
139.59.37.12 Generic crawler with attack signatures

Many of these generated hundreds to thousands of requests over the 48 hour period.

Observed Attack Patterns
WordPress Probing

Even on non-WordPress systems, these paths were repeatedly hit:

/wp-login.php
/wp-admin/
/wp-content/plugins/

This is automated scanning, not targeted behavior.

XMLRPC Access

Frequent hits on:

/xmlrpc.php

Common uses include pingback abuse and brute force via API endpoints.

PHP File Probing

Requests targeting common configuration and entry points:

/index.php
/config.php
/.env
/db.php These are looking for exposed configs or weak deployments.

Credential Stuffing

Repeated requests to:

/login
/admin
/api/auth

Often with high frequency and rotating IPs.

What This Means

If you rely on standard analytics:

Traffic volume may be inflated
Engagement metrics may be misleading
Infrastructure may be handling unnecessary load

More importantly, this traffic is constant. It is not tied to visibility or popularity. Any exposed service will receive it.

Internal Response

After seeing this across multiple systems, we started aggregating this data instead of treating each site in isolation.

The approach:

Track IPs across multiple deployments
Classify behavior based on request patterns
Identify repeat offenders
Apply blocking rules based on shared observations

This evolved into a simple shared threat dataset.

Threat Network Concept

Instead of reacting per site:

An IP flagged on one system is known to others
Patterns such as WordPress probing or XMLRPC abuse are categorized
Repeated behavior increases confidence in classification
Blocking decisions become faster and more consistent

This reduces duplicate analysis and speeds up mitigation.

Outcome

After applying filtering based on this data:

Cleaner traffic metrics
Reduced unnecessary requests
Lower noise in logs
Better visibility into actual users
Closing

The main takeaway from this dataset is straightforward.

A large portion of inbound traffic to public web services is automated and non-user driven.

This data is from a limited 48 hour window across a small set of systems. Patterns may vary, but the presence of automated scanning is consistent.

If you are interested in testing this type of visibility or contributing additional data points, I am running a small beta around this approach.

www.blockabot.com

I checked my logs this morning… the traffic wasn’t what I expected

Greg B — Wed, 01 Apr 2026 11:47:03 +0000

I knew bots were hitting one of my smaller sites, but I didn’t expect this level of activity.

I ended up building a small tool called BlockABot (blockabot.com) to help track what was actually going on.

Checked the logs this morning and over the last 24 hours:

217 requests
422 unique IPs
286 of them were brand new
What they were doing

Most of it wasn’t random.

WordPress-related paths → 95 hits
General scanning → 100+ hits
Smaller amounts of:
.env probes
admin panel scans
PHP endpoint checks
What stood out

There were clear bursts of activity:

Around 11PM → ~49 unique IPs in one hour
Around 11AM → over 100 unique IPs in one hour

That doesn’t look like normal traffic.
It looks more like coordinated scanning.

Why I built this

I originally ran into this trying to figure out weird traffic patterns on a small site.

So I put together something simple to:

log requests
detect common scan paths
track repeat IPs
build a shared list of known bad actors

Basically trying to answer:

is this traffic actually human?

What I’ve noticed so far
A lot of traffic is automated, even on small sites
Bots tend to hit in waves, not randomly
The same IPs show up repeatedly
WordPress endpoints get hit constantly (even if you’re not using WordPress)
One interesting stat

Out of the 422 IPs:

286 were new
136 had been seen before

If you think this might help you, or if you have some ideas to add ott it let me know.

Built This to Stop Bots Across My Sites Turned It Into a SaaS

Greg B — Sat, 28 Mar 2026 18:44:17 +0000

Most of the traffic hitting my sites lately hasn’t been human.

I was dealing with bots and scanners across multiple servers, and managing blocks on each one separately was getting messy fast.

So I built something simple for myself to track and block bad traffic from one place, and use that data across all my sites.

This builds a threat list of bad Ips if they have met certain criteria to be labeled as a Bot. This list is a shared threat list that can be used on multiple sites that use the same base js code. It ended up working better than I expected, so I turned it into a small SaaS called BlockABot.

Still early, but it’s already cutting down a lot of junk traffic.

If you deal with bots, scraping, or odd traffic patterns, I’d be curious what you think.

https://blockabot.com