Signup abuse detection and blocking

Signup abuse detection and blocking [Paid] 1.16.11

No permission to buy ($45.00)
I have 'Country language - Unknown' set to: Score 1

But when unknown browser language is detected it does not giva a point.
 
How do I tune this to stop VPN? With default settings and the ASN set to "Rejected" all my tested VPN connections are let in.
 
VPN is probably best blocked in cloudflare if you have it. You can add a page rule for the registration page.
 
How do I tune this to stop VPN? With default settings and the ASN set to "Rejected" all my tested VPN connections are let in.
You need to add the various ASN's to the reject list, the default list probably is missing a lot of VPNs as they are constantly using new ISPs

Is it possible to deactivate the Country IR does not match registration country messages to approval ?
Search for the "GeoIp content spam check action" option and set it to allowed.
 

I get a lot of false positives on our forum on signup and people send us inquiries via the contact page:

Your registration has been rejected as it resembles spam-like or automated behavior. Please contact the administrator for further information or assistance.

Can you please advise what triggers this rejection? I'd like to adjust the parameters.
 
Can you please advise what triggers this rejection? I'd like to adjust the parameters.
You need to show an example from the User Registration Log to show what part of their registration is being rejected.
../admin.php?logs/user-registration/

Example: (We're looking for lines with 'rejected')
rejection-sample.webp
In this example above, this user was rejected because of the source network (ASN).
There's also a moderation flag fo IP thread score, but this would not trigger a direct rejection in this example.

If you can show us an example, we can help ID the reason for rejections.
My immediate guess is the IP scoring, since that's a common one.
 
  • Like
Reactions: Xon
You need to show an example from the User Registration Log to show what part of their registration is being rejected.
../admin.php?logs/user-registration/

Example: (We're looking for lines with 'rejected')
View attachment 318118
In this example above, this user was rejected because of the source network (ASN).
There's also a moderation flag fo IP thread score, but this would not trigger a direct rejection in this example.

If you can show us an example, we can help ID the reason for rejections.
My immediate guess is the IP scoring, since that's a common one.

I got it; it's mostly people from the Philippines that I blocked country-wide due to prior abuse. Thank you!!!
 
I'm getting a lot of users either rejected or placed onto moderation because they are using the Apple iCloud Private Relay. This, on its own, wouldn't be enough to trigger sufficient points on my setup, however I've ended up with someone else being rejected and now pretty much every registration generating additional points because they share an IP address with another rejected user.

I'm not sure how Apple iCloud Private Relay allocates IPs, but it seems to be picking from a fairly small pool.

Is there a way to sort this, for example temporarily allowing Apple iCloud Private Relay IPs?
 
I'm not sure how Apple iCloud Private Relay allocates IPs, but it seems to be picking from a fairly small pool.

Is there a way to sort this, for example temporarily allowing Apple iCloud Private Relay IPs?
From our data, iCloud private relay tends to come from spaces owned by Cloudflare and Akamai. Look at your registration log see if the IP threat score is the rejection reason or something else. If it's the IP threat score, you would have to lower that threshold.

I would also recommend deleting the accounts where there are rejected users, too many IP's are shared these days, so this tends to be a false alarm (shared IP with rejected). We flush out rejected accounts once per day... if the same person comes back, the cookie detection is usually triggered.

If you want to dive into the data of outbound IP's for private relay, take a look here: https://mask-api.icloud.com/egress-ip-ranges.csv
 
  • Like
Reactions: Xon
From our data, iCloud private relay tends to come from spaces owned by Cloudflare and Akamai. Look at your registration log see if the IP threat score is the rejection reason or something else. If it's the IP threat score, you would have to lower that threshold.
Thanks for reply. The reason for rejection is shared IP with previously rejected user. That original user was rejected for another reason, but it now seems to be blocking most users that are signing up with iCloud Private Relay (as expected).

I was wondering if there was a way, to temporarily disable checking for IP match with rejected user (this seems to be different to the Ip match with duplicate account unless I’m missing something).
 
I was wondering if there was a way, to temporarily disable checking for IP match with rejected user (this seems to be different to the Ip match with duplicate account unless I’m missing something).
What do you have set for this one? ../admin.php?options/groups/spam/#approveSharedBannedRejectedIp

1738311746961.webp
 
Thanks for that, l was looking for this option in the Signup abuse... Add-on, not the default options! l've set to 7 days already, may reduce further.
 
If a user hasn't logged in for "X" months, and creates a new account, will this still report them as a duplicate account?
 
If a user hasn't logged in for "X" months, and creates a new account, will this still report them as a duplicate account?
As long as the cookie remains intact, yes. More often than not, this is the case as I have seen people trying to make new accounts and forgot they had an existing account. (Sometimes weeks apart, sometimes months...) The detection method is usually cookie based.
 
As long as the cookie remains intact, yes. More often than not, this is the case as I have seen people trying to make new accounts and forgot they had an existing account. (Sometimes weeks apart, sometimes months...) The detection

So, if a user logged in six months ago, I install the addon today, the user makes a new account, I won't get notified because they (old account) don't have the cookie?
 
So, if a user logged in six months ago, I install the addon today, the user makes a new account, I won't get notified because they (old account) don't have the cookie?
Correct. The cookie has to be set and then they will be eligible for detection. But, you will have still have the chance to detect by IP address.
It's entirely possible that they could login on two different accounts from the same IP, that will trigger an IP detection. (Of course, this is all subject to how you configure the addon.)

Personal recommendation would be to get the "Multiple Account to Thread" reporting setup and create a sub-forum in an admin area, where your multiple account detections can be recorded and tracked. This all logged anyway in the ACP anyway, but the sub-forums gives easy visibility.
 
Correct. The cookie has to be set and then they will be eligible for detection. But, you will have still have the chance to detect by IP address.
It's entirely possible that they could login on two different accounts from the same IP, that will trigger an IP detection. (Of course, this is all subject to how you configure the addon.)

So I purchased this, set up the options. I see this under the IP checking, "IP matches are considered a low quality signal and will not trigger a multiple account match by themselves."

Signing up without a cookie being present on the browser does not trigger a duplicate account thread.
 
Back
Top Bottom