Skip to main content
Recent Posts
Feature Discussion / Re: Bad Behavior Feature
Last post by Steeley -
As I read through this, and my own logs, I'm glad I have the forum running in a protected directory that nobody can access unless they request it (requires two steps - email validation, and then personal justifying information for access credentials).  The process is homespun using simple html coding.

Email validation is just "enter your email address and submit".  Upon submit, the applicant gets an html page that says to check their email, and when received, click the link on that page that goes to the next step).  My server sends an email response to that addy that includes a random 6-digit number (along with apologies if the addy is not the right one for the submitter) , and I get a copy that goes into my "access pending" folder.

The 2nd step is a series of questions on a form - includes a space to enter their email address and the number that was sent, along with their answers to the questions.  When the applicant submits, they get another page that says to watch their email for credentials (could be a day or two), and that form comes to me in an email - I then can match the email address and number from the first and second emails to verify the supplied addy is real, and decide whether the applicant gets access to the forum area. If so, I email their credentials to the directory (unique for each - username and password related to their personal information)  to them, and the link to the forum home page where they can register for the forum...

As a result I have virtually no forum moderation tasks to perform, subsequently - no "bad behavior' to concern myself with.

And for the record, my questions themselves screen out a lot of undesirable folks, the questions pertain to the subject of the forum and if they aren't familiar with the subject they can't answer them appropriately - I rarely get a 2nd step response from someone who is subsequently denied access,  and my ratio of first email to second email is about 5 to one.   :)

My logs show quite a few "gets" on the menu page that has the application link - maybe 200 a day from unique IPs - about 30% being spiders - and I'll get maybe 5 emails a week from the 1st application step.

My process (for the particulars of *my* forum) weeds out the bad actors and 'lookie-loos', before they ever get to the forum - or even complete the process.

So @Spuds, I posted this in response to your query "Since 1.0 we have provided "Bad Behavior" anti spam functionality included.  I'm curious if this is still useful to anyone.",  so you would understand why I wasn't responding to it..  :D 

[if anyone is curious to see this in action, PM me for a link]
Feature Discussion / Re: Minutes to stay logged in
Last post by Arantor -
So what I have is a persistence token; it contains a server-generated alphanumeric string plus the user id, generated and stored when the user logs in (if they ticked 'always stay logged in'), and I let whatever session cleanup Symfony does do its thing - so that when the user presents a session ID that isn't recognised, we can look for this persistence token and if it's still valid, repopulate the session. Naturally, all the usual keepalives will keep the session alive, and will renew the persistence token if it's getting close to expiry.
Feature Discussion / Re: Bad Behavior Feature
Last post by Spuds -
Kind of says its not really doing much, its those outside services that are doing the bulk of the lifting.  The rest could be done with a couple of simple checks -or- blocked at the server level for those that can make changes there.

I think I have data access to another site, so I'll take a look at its logs and see what/why of the blocking.

I've tended to use some nginx items "conn_limit_per_ip",  "req_limit",  "php_limit"  to throttle requests / activity.  The only things that seem to trip those limits are bots.  Then I have a couple of fail2ban rules, so if you trip those breakers a few times in a given period, you get blocked for some period of time.
Feature Discussion / Re: Minutes to stay logged in
Last post by Spuds -
I just finished removing that option in favor of only the "stay logged in".   If you don't check that then its whatever the admin set in the control panel for TTL.  At least the login form now looks normal.

Setting the "forever" sets the cookie for some very long period of time, TBH I'm not sure what that is, 1 year sounds right.  I remember in some areas it was in seconds and other minutes.

It still uses that same basic data scheme, the cookie is a hash of the hashed password + user salt.  Probably the only deltas are type of hash and salt length.  Now i'll be looking into this a bit as well.

Feature Discussion / Re: Bad Behavior Feature
Last post by Arantor -
Huh, interesting stats.

I'd also be curious which user agents you're blocking because what I'm finding is that there are a host of 'search engine bots' that are pretty awful and unlikely to return much traffic, e.g. Aspiegel/Petalbot, Mauibot, Ahrefsbot, to the point where I block them entirely from even getting to the server if the user agent mentions that.

But I think we can agree that you don't need to integrate BB as is at this stage, and just do the integrations you do care about.

I will say that the measures I added to SMF on the CAPTCHA validations (especially registration) have proven reasonably effective at keeping things at the door without too much effort - time gating and a mandatory-empty field.
Feature Discussion / Re: Minutes to stay logged in
Last post by Arantor -
Personally I dropped it in favour of an 'always stay logged in' option - no tick: log out at end of browser window/60 minutes (but not just dropping people at 60 minutes, only after some inactivity), tick: keep them logged in for at least a month and let the cookie + session renew through that time.

There are various strategies for how this might work; the default solution in SMF is awful and if you're still using it, please kill with fire. (The method they (still) use is to make a long life cookie that really is long life, a year or more IIRC, and the basis of the cookie is username + password hash, rehashed, so that the cookie supplier can be reauthenticated.)
Feature Discussion / Minutes to stay logged in
Last post by Spuds -
This is another feature that I'm not sure is that useful, or not really used very often.  I get why it was there at one point. 

I was thinking to drop that user option and just set it to the default of 60 mins (or whatever you have entered into the ACP for cookie length)

Looking around I don't really see that option in other software packages, just seems like form clutter at this point.

So again, does anyone use this and if so why?
Feature Discussion / Re: Bad Behavior Feature
Last post by Spuds -
Checked this sites log (it does not have spamhaus enabled), had about 2K entries.

Honey Pot -  Logged as:  IP address found on http:BL blacklist ~50%
BB -  Logged as:  Required header 'Accept' missing ~25%
BB (SQL in url check) -  Logged as: URL pattern found on blacklist ~ 23%
BB (Blacklisted user agents) -  Logged as: User-Agent was found on blacklist ~ 2%

So just some data.   Could reject the missing accept at the server level as well.  I think for Nginx its would simply be
Code: [Select]
if ($http_accept = false) {
    return 403;
or maybe return 406 ... anyway easier then all of BB
Feature Discussion / Re: Bad Behavior Feature
Last post by Arantor -
It looks like it got some maintenance love in 2019 but that was the last trace of it (and it didn't make it to the 'official'(?) repo on GitHub. Post:

The accept header being missing used to be more relevant back in the day but I'm genuinely torn on the value of this now - it's been a while since I had any real honeypot data to look at to see if this is still relevant. For the mainstream browsers as far as I know they all still send it. Would agree there are many more fringe clients that don't use it now.

If you're relying on BB for just the blocklist integrations, you're probably better implementing those yourself at this point. I remember when Wedge did BB integration, we cut out a whole bunch of tests that simply weren't relevant. I think for the few that might still be relevant, they can be added as-is without the fluff that is the rest of BB's architecture.
Feature Discussion / Bad Behavior Feature
Last post by Spuds -
Since 1.0 we have provided "Bad Behavior" anti spam functionality included.  I'm curious if this is still useful to anyone. 

The BB software has not been seriously updated in some time, and many of the checks are very dated.  Bots are much cleaner now than when the core of BB was written to catch issues and the bots are no clumsy these days.

While scanning one set of logs, I found (3) main reasons to BB actions

1) The main one was "Required header 'Accept' missing".   TBH there are a share of these hits that are incorrect.  Several of checks that flag this issue are so-so at this point.  There are various exceptions for things like  like PlayStation 3 or Yahoo hot jobs Seeker, or Window ME among others, just listing those to show the patina on the code.  I know there are specific issues with mobile devices and this check.   

2) The next major BB block was not really BB, but calls made to the http:BL service provided by Project Honey Pot.  These are logged as "IP address found on http:BL blacklist"  This function could also easily be added without the need for BB

3) The last seemed to be "User-Agent was found on blacklist"  This is detected since BB simply checks IP's with SBL / XBL lists. That is easy to add without having to rely on BB.

I've also seen a few "URL pattern found on blacklist" which is generally someone trying to inject sql via the url, that would not go anywhere w/o BB anyway.

So for those of you using BB,  useful or not?  What detections are you seeing?