I made an AI block

[Noah_S]

https://art-noah-s.eu/index.php/how-i-made#AIblock

It blocks AI. Here's a screenshot of an AI being asked about my website yesterday.



I named it victory vs AI. That's right bot, you're forbidden.

Dan Q wrote a followup with different options for different server configurations. Mine has some workarounds because it's a module in Joomla. And because I like the programming poetry of sending those bots to a forbidden page.

[Dan Q]

It's a very different approach, but I like the technical magic of the strategy taken by Heydon Pickering on his blog. Their approach is that they accepts scraping by well-behaved bots, but they actively sabotage those that don't behave well (which they define as e.g. doesn't respect rel="nofollow", etc.).

If you look at the end of any of their blog posts there's a link explicitly "for" LLMs, marked rel="nofollow", so any properly-behaving scraper (whether AI or not!) shouldn't follow the link. If you follow it, you get a "nonsense" version of the post... possibly generated using something like DaDaDoDo (which I wrote a summary of back in... 2004!). Which in turn links to a further-obfuscated version, and so on... so the deeper an LLM drills through rel="nofollow" links, the more it poisons its own training data with meaningless garbage. Hilarious.

Obviously it'd be possible to use a similar approach to poison all LLM scrapers, if e.g. you detected their user-agent and served them garbage pages. 

Which makes me wonder: would it be possible to implement a reverse-proxy in a webserver that detected particular kinds of scrapers (e.g. AI bots) on-the-fly and served them garbage. It's a much more-aggressive approach than just 403ing them, but it'd be hilarious.

[Dan Q]

Hey @Noah_S: is your site okay?

When I try to connect from home, I get my connection rejected, like you're blocking my IP? (Possibly I triggered some kind of block while I was experimenting with changing my user-agent, to see that you were blocking as you said?)

So I used a different IP address and ran curl htt​ps://art-noah-s.eu/index.php... and got a 403. Adding a header to spoof being Firefox got around it. So it looks like you're blocking... curl? It's not in your list, and it's possibly ill-advised: curl gets used by many legitimate RSS readers (including mine!)?

Anyway: if you want to tell me whether or not you've IP-banned me, that'd be nice! Thanks!

[Noah_S]

I have no idea what's happening with that. I haven't done anything with it since yesterday and it's working fine here?

[Dan Q]

Looks like it's me, specifically, that's getting blocked!

Here's an nmap port scan from some other IP I control:

Code

~ nmap -p 1-1024 185.45.149.138
Starting Nmap 7.93 ( https://nmap.org ) at 2026-09-15 10:31 UTC
Nmap scan report for webhost1.host-unlimited.de (185.45.149.138)
Host is up (0.021s latency).
Not shown: 1011 filtered tcp ports (no-response)
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
106/tcp open  pop3pw
110/tcp open  pop3
143/tcp open  imap
443/tcp open  https
465/tcp open  smtps
587/tcp open  submission
993/tcp open  imaps
995/tcp open  pop3s

Nmap done: 1 IP address (1 host up) scanned in 4.69 seconds

Here's the same port scan from my home IP address:

Code

~ nmap -p 1-1024 185.45.149.138
Starting Nmap 7.991 ( https://nmap.org ) at 2026-09-15 11:32 +0100
Nmap scan report for webhost1.host-unlimited.de (185.45.149.138)
Host is up (0.031s latency).
Not shown: 1011 filtered tcp ports (no-response)
PORT    STATE  SERVICE
21/tcp  open   ftp
22/tcp  open   ssh
25/tcp  open   smtp
53/tcp  open   domain
80/tcp  closed http
106/tcp open   pop3pw
110/tcp open   pop3
143/tcp open   imap
443/tcp closed https
465/tcp open   smtps
587/tcp open   submission
993/tcp open   imaps
995/tcp open   pop3s

Nmap done: 1 IP address (1 host up) scanned in 43.18 seconds

It looks like ports 80 (http) and 443 (https) are explicitly being blocked from being accessed by my IP address! Possibly firewall configuration?

Weird that it happened now, of course! (Which is why I initially wondered if I'd hit one of your anti-AI Bot things!)

[Noah_S]

I've contacted my host about it. I also thought about that AI block at first, that's why I asked about the lost fox on error 404 in the chat.

[Loebas]

Danq. I want to say to be carefull with doing random portscans at random webhosts. Their firewall can block/blacklist your IP adress, both at home, and your IP abroad.
It only takes an email to their abuse department.

As for the closed ports. It cannot be done by php, or any other websoftware. You usually dont have access to those resources on a shared account. And blocking software like fail2ban usually blocks all ports for said IP.
I dont know why specificially the HTTP ports are blocked, that goes beyond me.

You can always check your IP on abuseipdb to see if someone reported you, which cpuld be one culprit i can think of.

[Noah_S]

Dan Q's situation was resolved when I contacted my host and asked them to let him back in. Trouble shooting on my end resulted in my control panel telling me to contact my host.

[Dan Q]

Danq. I want to say to be carefull with doing random portscans at random webhosts. Their firewall can block/blacklist your IP adress, both at home, and your IP abroad.

I'm not sure what you mean by "IP address both at home and abroad", but anyway:

I'm not convinced that any large reputable webhost are doing long-duration IP blocks (e.g. via fail2ban) in response to a detection of port-scanning. Because doing so is a really, really bad idea and creates enormous potential for misuse. It's trivially easy for an attacker to trick a victim's web browser into acting in a way that "looks like" port-scanning in order to perform a denial-of-service attack: getting them banned from a service they use!

While the forum was closed yesterday I made a proof-of-concept of the problem and blogged about it. In my example, Bob has a favourite website, bobs-favourite.test, which implements port-scanning detection via kern.log coupled to a fail2ban permaban. Alice, in an effort to block Bob from accessing his favourite website, adds code to a web page that she controls (this code could be HTML, JS, CSS or even SVG, and probably others besides: that latter one's especially troublesome!) that results in a series of sequential port connections. Now, if Bob even looks at Alice's web page... he gets banned from his favourite website!

Here's Alice launching her website. Note how we're able to access Bob's Favourite website right up until we visit Alice's website, and then we're permabanned. A successful DoS attack made by targetting the user's browser. Oops:

Incidentally, you've got a similar vulnerability on your forum at forum.boykisser.nl, @Loebas! Your honeypots do nothing to verify that the links they produce were delivered to the same IP address as the IP of the person who clicks them. This means that it'd be possible for Alice to extract some honeypot links from a web page, embed them as e.g. invisible images in some other web page (or even on your own forum!), and when Bob's browser accidentally loads them... boom! He's permabanned!

I've made a proof-of-concept of this, too. Click the button below and your IP will be banned from forum.boykisser.nl (you might want to enable a VPN first so you can switch IP afterwards!). Note that the button is just there as a safety feature: this attack can work completely silently and invisibly!

Update: It looks like @Loebas has removed the honeypots from the forum, so the demo below won't work. Which I suppose means you can probably press the button with impunity! Yay?


Webgarden - https://danq.me/tmp/boykisser-ban/.

How do you prevent this kind of attack from turning your honeypot against you? Encode the IP address into the URL that you give out as honeypots, and then check it when one gets hit! This way, somebody can only get their OWN IP banned.

It looks like you're using PHP, so you might do something like this:

Code

<?php
/**
 * Randomly generate a secret key and put it here. This prevents an attacker spoofing
 * requests.
 */
define('IP_HMAC_KEY', 'replace-with-a-long-random-secret');

/**
 * Returns an IP address-linked token that can be tacked onto the end of a honeypot
 * URL. So you might go:
 * echo '<a href="/honeypot-url.php?any_other=parameters_you_need&ip_token=', honeypotIpToken(), '"></a>';
 * Optionally extend this by adding a datetimestamp to mitigate against predictable-future-IP attacks.
 * (But personally I think that's a step too far!)
 */
function honeypotIpToken() {
  // If you're behind a reverse proxy and you use a different way to get their IP, use
  // that instead of $_SERVER['REMOTE_ADDR']! (E.g. $_SERVER['X_FORWARDED_FOR'] etc.)
  $ip = $_SERVER['REMOTE_ADDR'];

  // Normalise IPv4 and IPv6 addresses the same way:
  $packed = @inet_pton($ip);
  if ($packed) { $ip = inet_ntop($packed); }

  // Create a HMAC hash that encodes the user's IP:
  return hash_hmac('sha256', $ip, IP_HMAC_KEY);
}

/**
 * Before treating a honeypot hit as valid, call THIS function. It returns the
 * IP if it's a valid honeypot hit (i.e. the link was triggered from the same IP
 * as the IP you GAVE the link to in the first place!), false otherwise.
 */
function honeypotIpTokenIsValid($ip_token) {
  if (!is_string($ip_token) || $ip_token === '') return false;

  // Same way of standardising IPs. Same limitations as above. You might like to
  // refactor this out into its own function I suppose?
  $ip = $_SERVER['REMOTE_ADDR'];
  $packed = @inet_pton($ip);
  if ($packed) { $ip = inet_ntop($packed); }

  // Validate that the hash matches. Note what we don't HAVE to use hash_equals()
  // in this case (I can't conceive of a timing-attack against this system), but
  // it's just good-practice when you're doing security work with hashes ANYWAY.
  $expected = hash_hmac('sha256', $ip, IP_HMAC_KEY);
  return hash_equals($expected, $hmac) ? $ip : false;
}

Anyway, that's how I'd try to prevent honeypot abuse. Your mileage may vary!

[Loebas]

@danq Thank you for the valuable feedback, and the extensive blogpost about it.

To prevent abuse of my honeypot system, i disabled it for now until i can properly remove the jail from fail2ban. So the webgarden will not trigger anything now!
(Because if it did, your IP will also get reported. Albeit under the "exploited host category", i dont want to make false reports)

I've also reverted the outdated chromium ban, and extended it to chrome 152.

For those wondering about the honeypot. It is an extension for phpbb which was recommended in a thread about the whole botnet thing. So modifying the whole spiel requires a lot more than a php file, but thank you anyways.

I'm going to make followup post in it over on my blog.

Remember i'm still learning, and with this whole thing i learned a lot about it!

[Dan Q]

Remember i'm still learning, and with this whole thing i learned a lot about it!

We're all still learning! Don't trust anybody who claims to know it all already: they're either misguided, lying, or - worse - have given up on their future growth!

Good luck with the bots. They're a nightmare for me right now over on geohashing.site, which gets absolutely hammered by them. I've not had to resort to honeypots yet, but we're getting to the point where we might need a more-serious proof-of-humanity (e.g. "email one of us or turn up in our Discord server to say hi and introduce yourself") to block unwanted bot account registrations!

[Noah_S]

One method for forums is to have only one place where new users can post. That gets all the bots into that one place instead of spamming all over, and new users can introduce themselves there and then manually be given access to the rest of the forum.

[Dan Q]

One method for forums is to have only one place where new users can post.

It's a bit more-complicated than that for Geohashing. It's a MediaWiki-powered wiki rather than a forum, and while I could do some restrictions on where "new" users can write, the biggest reason we're trying to keep the bots out is that they keep hammering expensive read endpoints like history, diffing, and search. Which we do want new (human) users to read because they - especially search - are super-useful for new players. It's tough