Recently I’ve added in crowdsec a scenario to ban IP that connect to my web server with particular User-Agents. Listing crowdsec alerts, I see that it banned its own IPv6 (server has both v4 & v6).
Digging in the logs I see that this IPv6, owned by the internet-facing eth interface of the server, appears as client address for TONS of requests, with hundreds different UA (most of them belonging to bots). And it has started years ago.

Digging further (#splunk) I see that this traffic is ~100% GET, 100% targets are pictures or pure text (jpg, png, txt, etc.), and ~100% yield to a 404 status.
Also, 100% of those events happens on my Wordpress blog, no other web site on the same server.

Running FreeBSD, I used truss and ktrace on Apache: nothing interesting, except that, apparently, the client IP is really server’s own IPv6.
Then I used ktrace on php-fpm, and there I found something interesting: the real REMOTE_ADDR seen by php is not the server IPv6, it’s a real client IP (say Google Bot IP, for example).
Building on this, I was able to trace what happens, but the «how» and the «why» remain a mystery:

• the bot connects to my WP blog, fetch a web page (an article), I get it’s real IP in the apache log file.
• then it tries to fetch medias from the article but URLs are wrong (like «/blog/blog/...» instead of «/blog/...», those requests appear in the log with server’s IP as client IP.

As far as I can say, this URL «mixup» never happens with real users visiting the blog. I’m quite lost!

Any hint / idea appreciated

#apache #php #wordpress #freebsd