[TAC] Fool Bot Honey Pot

[TAC] Fool Bot Honey Pot [Paid] 3.0.32

No permission to buy ($29.00)
Overview Updates (79) Reviews (28) History Discussion
None of the bots get passed the fbhp classical fields .. yet .. unless they re-attempt with a fresh ip address (and some do), these bots only get one attempt with one ip address when fbhp is around, but they're switching ip addresses too

I've realised the reason for this, the bots are looking at the request responses, the responses were set up in the original fbhp, I'll add them back in
I'm still testing Browser Bot Detection, hopefully it's on it's way in the next version too.
 
I've now created a 3.0.03 version (not officially released yet)

@MattW and @Deebs are testing it

It adds back in the responses for fbhp honeypots (making bfhp honey pots harder to target, these bots that re-attempt shouldn't know what to look for now)
- These new bots do a lot of sanity checking, so it's essential to make honeypots as much like real fields as possible

I have also added secret ingredient 2 to this version, it was only added for logging information, I've added a little bit of a check, so it might prevent all/some/none Browser Based Bots, but it will hopefully be improved once I get some logs back from MattW and deebs

So we now have:
1) Brower Based Bot Detection
2) Non Browser Based Bot Detection
3) New types of classical fbhp honey pots that are harder to target

The combination of 1 & 2 will prevent 100% of bots
3 is just an extra set of methods to hammer this home

- The new wave of bots will be prevented completely once again, and this will be done elegantly with no human impact, fbhp has done it before, it will do it again!
 
Last edited:
These methods are very thorough at detecting bots, once we know, we really know they are bots (that's why fbhp can then block them with htaccess)

Something occurred to me while looking at this thread, I think their sever / application got overloaded and crashed, either because it tried to download all 360000 versions of the customimgcaptcha, or simply that the one image was bigger than their application could handle (more likely the latter)

https://forum.gsa-online.de/discussion/6055/cb-hangs-on-xenforo

I believe their applications keep crashing when hitting certain images from customImgCaptcha
It then occurred to me,

xml bombing using an external source (It's usually a black hat technique used to bring down servers, but is it really naughty if we use it against bots?)

Sure we block the bots, but we could crash them too. I'm toying with the idea of really destroying these bots this time, not just blocking them, they upped their game, so will I.
 
Unfortunately htaccess doesn't do much for us nginx users. Which includes Xenforo.com.

Nice find though. So nice of them to publish this sort of thing for us.
 
The fbhp cache will still help to some degree, but yes I realised not everyone can auto update htaccess, and not everyone uses Apache (so, it's there as just an option).
I don't know much about nginx, is there an equivalent to htaccess (nginx.conf????)
 
tenants said:
The fbhp cache will still help to some degree, but yes I realised not everyone can auto update htaccess, and not everyone uses Apache (so, it's there as just an option).
I don't know much about nginx, is there an equivalent to htaccess (nginx.conf????)
Click to expand...


I'm actually not sure. All the rules I have are in the server config. @MattW might know and even better @eva2000 would know.
 
I actually didn't quite read your question right. Yes normally the rules go in a conf file. I think you can put something like it in a server directory.

Edit- "I would say" Worst case you could always say screw it and put an includes that has the path in the open. But it would only be read on server reloads.
 
Last edited:
MattW said:
What does an example entry in the .htaccess file look like?
Click to expand...

dedos example:

# Start DeDos Deny Block DO NOT MODIFY #
order allow,deny
deny from 128.52.128.105
deny from 5.199.130.188
deny from 37.187.85.172
deny from 67.205.146.164
deny from 171.25.193.131
deny from 138.197.96.251
deny from 5.166.252.234
deny from 163.172.209.46
deny from 109.126.241.254
allow from all
# End DeDos Deny Block DO NOT MODIFY #
 
You could include a conf file in the http or server block,

include blockips.conf;

Code: 
deny 128.52.128.105;
deny 5.199.130.188;
deny 37.187.85.172;
deny 67.205.146.164;
deny 171.25.193.131;
deny 138.197.96.251;
deny 5.166.252.234;
deny 163.172.209.46;
deny 109.126.241.254;

BUT, you would need to restart nginx each time an IP address was added to the block list, it's ready on each request like Apache does with .htaccess.
 
I'm starting to realise why most of the time, the core only catches bots with one honeypot (the rest of the time, bots bypass it). Earlier I said it was due to ordering, not because fbhp are necessarily better. That's not true, the core just about always only uses one good honeypot, wow! The core's honeypots aren't as good as I was expecting

Even if these weren't the new version of bots that bypass hidden fields (and are js enabled, and now bypass the reg timer),
an old version (crappy) bot would randomly get around the core honeypots every now and then anyway!

It's because only one core hp (username) displays all of the time (the rest only displays 1 in every 3) and only one (username) is a good honey pot name (username)
the rest of the honeypots are all named uuids (and all hidden in exactly the same way). That defies the point! Bots don't get bored, they re-attempt!!!!! they can re-attempt lots (unless you have fbhp installed, even then, they can switch ip address)
The core does nothing to stop this re-attempting on a very easy mechanism to by pass

They have made this incredibly easy to get around, and that's not the worst part, the core honey pots are incredibly easy to detect, they have effectively put a flag next to them saying "I'm a honeypot"

If you only have one good honey pot, when a bot re-attempts... guess what they are going to do, avoid the honeypot!!!!
Jeez, good code, appalling implementation of some very good ideas (damn it I wrote them all down on the front page, they really should have read / talked to me).

No wonder people have still been getting bots tricking through, even at early stages of xf 1.4, (these were bots, not humans), fbhp was always much better implemented, and really did always stop 100% of bots.
There is no way that the cores implementation did this.
I hadn't known, I assumed they would have done a good job, and now it's targeted, their core honeypots are useless.

I'm so impressed with the cores work usually, everything they do looks amazing, the code is clean, great methodology, but this implementation was appalling, it looks like I should have competed with the core.
I thought updating it would have only served a logging purpose, but their implementation had so many holes for bots to get through.

-sorry, I'm currently updating the fbhps logging functionality, digging into the core, the more I see, the more I'm shocked
 
Last edited:
I have a version that should stop the new js bots, I need logging information from it to improve it
Is anyone that suffers from bots around that is willing to try this version and send me back some logs?
 
MattW said:
You could include a conf file in the http or server block,

include blockips.conf;

Code: 
deny 128.52.128.105;
deny 5.199.130.188;
deny 37.187.85.172;
deny 67.205.146.164;
deny 171.25.193.131;
deny 138.197.96.251;
deny 5.166.252.234;
deny 163.172.209.46;
deny 109.126.241.254;

BUT, you would need to restart nginx each time an IP address was added to the block list, it's ready on each request like Apache does with .htaccess.
Click to expand...


You do no need to restart apache after updating the htaccess, the rules are dynamic, which is why this was so effective
Are you sure you need to do it on nginx? (if so, there is no point it repeating the same for nginx, these bots can come in so fast)
 
I've just stated to test and support xf 1.4 forums (next version)

and wow, the core honeypots offer no support at all, even against the basic bots ... oh, I've added more fbhp classical honeypots (different types compared to the core), because I hand't realised how few (1 .. sometimes 2) core honey pots were showing until I looked at the code. It's almost always the case that core honeypots are bypassed, and these aren't even the recent nasty js enabled / reg-timer bypassers:

upload_2017-2-11_17-23-39.webp
 
Last edited:
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

SMASHED IT - now detects browser based bots, non browser based bots, extra honey pot mechanism

So,

I've added some extra alternative honey pot mechanisms in
I've added honey pots that specifically detect browser based bots
I've added honey pots that specifically detect non browser based bots (so these two alone should catch 100%)

I've also updated it so it works with xf 1.4.x -> xf 1.5.x

This will prevent the new wave of Xrumer and GSA that detect classical core honeypots, that bypass the registration timer, that have clean IP's thus bypass APIs

TAKE THAT BOTS!
Click to expand...

Read the rest of this update entry...
 
For anti-spam reasons, I want to know more about these js bots (which I believe to be mostly the latest xrummer), so next version I'll be adding debugging info so that I can't tell more about them
(you'll see a finger print option in the logs when you click a log entry if js is enabled for that bot/user)

At the moment we should wipe out both browser based bots and non browser based bots (thats 100% of bots again)
As you will see from your logs, the core honey pots are being targeted by some bots, both types of bots are getting past them (this will become more common over time)
FBHP versions of classical honey pots are still working, but this wont hold be forever

... so while we still have a chance, I'm going to pick up everything I can about these new bots to use it against them in the future

... If you ever see a bot that hits any honey pots, but does not trigger either the "non browsers bot" detection, or the "browser bot" detection methods,
I would be very interested in this type of bot... simply because I don't think it exists

There are many types of bots, I'm understanding more about each one, but some bots are fairly unique

The ones that attempt to register on forums are:
  • Xrumer
  • GSA
  • A-Poster
  • SEnuke X
  • miniXrumer
  • magic submitter
  • buzzbundle
  • Sick Submitter
  • AMR
  • Money Robot
  • ... etc
.. to add to that list, there are custom designs (such as selenium )

So you can see there are quite a few, Xrumer and GSA are the most common and dangerous to xenforo
As far as I know, so far I think it is only Xrumer and custom designs that are js enabled

- fbhp now protects against all ... again
 
Last edited:
Not anymore,
the core honeypots have been targeted, it is needed again for xf > 1.4
I use different types of honey pots than the core, not just different styles of hidden fields, but different methodologies that now detect browsers and non browser based bots

I need to update that description, but better still, I'm updating the entire collection with all the latest addons
 
Last edited:
You must log in or register to reply here.
Top Bottom