Access Blocker Support Thread

swguy:

I quite agree it would be risky to attempt to update the .htaccess file as part of storefront processing (because of the danger of having it done simultaneously by multiple threads). But what if the logic was to add these bad IPs to a table, and have a separate process regenerate the .htaccess from a cron job ?
That's outside of the scope I intended for this module.

Right - this would be done as a separate project.

I've just submitted v1.1.1 of the Access Blocker to the Zen Cart moderators for review; I'll post back here when it's available for download.

This release corrects the generation of PHP notices when one or more of the submitted form-fields is missing; see GitHub issue #8.

lat9:

I've just submitted v1.1.1 of the Access Blocker to the Zen Cart moderators for review; I'll post back here when it's available for download.

This release corrects the generation of PHP notices when one or more of the submitted form-fields is missing; see GitHub issue #8.
Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=2237

lat9:

Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=2237

I thought I understand what this mod can and cannot do, but it doesn't seem to be working.

So I found a list of 249 2-letter country codes, picked 22 countries where I have, or theoretically could, sell product, and then I compiled a comma-delimited list of the remaining 227 countries. I then put this list (AF,AL,DZ,AS,AD,AO,AI,AQ,AG,AR,AM,AW,AZ,...BY...) in the block by country list. I also put in my API and enabled Access Blocker.

I should also add that previously, as a short-term solution, I had temporarily disabled new account e-mail confirmations, but I still get my copy. I tested this and it is working. Using a real e-mail address, and "Bogus Name," I get my 'shop copy,' but Bogus' email gets nothing. BTW, I also updated the success page so it does say that a confirmation will NOT be coming . . . .

An hour after I set up Access Blocker, I received another new account notification from an IP address based in a blocked country. I confirmed that Belarus (BY) was indeed on my list, but still this 'Belarusian' bot was able to set up a new account.

I'm stumped. Have I missed something?

Do you have the Access Blocker's debug enabled. That will create a month-by-month list of accesses blocked, so you can get a feeling for what's going on.

What version of Access Blocker and what version of Zen Cart?

lat9:

Do you have the Access Blocker's debug enabled. That will create a month-by-month list of accesses blocked, so you can get a feeling for what's going on.

What version of Access Blocker and what version of Zen Cart?

I'm on ZC 1.5.3 and Access Blocker 1.1.1. There is no change at all in volume of new accounts - in fact, it is on the rise. We've gone from 2-3 fake accounts per day to 7-8. I can't see that this mod is doing anything at all. One thought I did have was perhaps it lies with the format of the list. Is it supposed to be AA,AB,AC . . . or with spaces, as in AA, AB, AC, . . . my list has no spaces. I'll try that now while I wait for some hopefully great suggestions, ;)

smcelligott:

I'm on ZC 1.5.3 and Access Blocker 1.1.1. There is no change at all in volume of new accounts - in fact, it is on the rise. We've gone from 2-3 fake accounts per day to 7-8. I can't see that this mod is doing anything at all. One thought I did have was perhaps it lies with the format of the list. Is it supposed to be AA,AB,AC . . . or with spaces, as in AA, AB, AC, . . . my list has no spaces. I'll try that now while I wait for some hopefully great suggestions, ;)
Access Blocker, as indicated by its readme, supports Zen Cart 1.5.5 and later. That's due to the additional notifications that are now present in the base Zen Cart, which make this a drop-in plugin.

What's happening is that while it's listening for create-account, login and contact-us captcha notifications, they're not being issued.

Argh, that was silly of me. I didn't even look at that. I always resist doing Zen Cart upgrades because the process is so very painful. Each time I complete an upgrade, I vow that I will just migrate to another platform, but then I get on with things, and become complacent until I am faced with the next painful upgrade.

smcelligott:

Argh, that was silly of me. I didn't even look at that. I always resist doing Zen Cart upgrades because the process is so very painful. Each time I complete an upgrade, I vow that I will just migrate to another platform, but then I get on with things, and become complacent until I am faced with the next painful upgrade.
Using the info at https://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading will have you saying, "No worries."

v1.5.5f php7.1 access blocker v1.1.0

Hi Cindy I hope you and yours are coping with the virus scenario.

This is likely just coincidence - I had OPC switched off on a particular website and with access blocker activated was not getting any spam accounts - I re-activated OPC a few days ago and the site is now being swamped with spam accounts.

I contacted ipdata.co and asked if the API code was still valid / functional and they have responded that it is all good. The last log I have for access blocker is dated 26/9/2019 - I installed it on 16/8/2019 - enable debug has been set to true from that date. I have no other debug logs relating to access blocker or account creation etc.

in OPC configuration I have Enable Account Registration (Do you want your store's create_account processing to create a registered rather than a full account?) set to TRUE whereas the default is FALSE ..... would that have any effect? .... to be honest I am not sure what the difference is registered / full account and what it actually does ??

Like I say, likely just coincidence but thought the longshot was a connection?

Stay Safe

cheers Mike

shags38:

v1.5.5f php7.1 access blocker v1.1.0

Hi Cindy I hope you and yours are coping with the virus scenario.

This is likely just coincidence - I had OPC switched off on a particular website and with access blocker activated was not getting any spam accounts - I re-activated OPC a few days ago and the site is now being swamped with spam accounts.

I contacted ipdata.co and asked if the API code was still valid / functional and they have responded that it is all good. The last log I have for access blocker is dated 26/9/2019 - I installed it on 16/8/2019 - enable debug has been set to true from that date. I have no other debug logs relating to access blocker or account creation etc.

in OPC configuration I have Enable Account Registration (Do you want your store's create_account processing to create a registered rather than a full account?) set to TRUE whereas the default is FALSE ..... would that have any effect? .... to be honest I am not sure what the difference is registered / full account and what it actually does ??

Like I say, likely just coincidence but thought the longshot was a connection?

Stay Safe

cheers Mike
Mike, all's good here in southern Florida (hopefully the same in Australia).

The account-registration feature of OPC enables a customer to register and receive newsletters and product notifications without providing any address-related information. When an account is 'registered', OPC fires the same notification as the base 'create_account' processing, so that Access Blocker should be picking up on those attempts as well.

Note, too, that the Access Blocker is currently at v1.2.0; that change to support OPC could have been added in the transition from v1.1.0 -> v1.2.0.

lat9:

Mike, all's good here in southern Florida (hopefully the same in Australia).

The account-registration feature of OPC enables a customer to register and receive newsletters and product notifications without providing any address-related information. When an account is 'registered', OPC fires the same notification as the base 'create_account' processing, so that Access Blocker should be picking up on those attempts as well.

Note, too, that the Access Blocker is currently at v1.2.0; that change to support OPC could have been added in the transition from v1.1.0 -> v1.2.0.

Hi Cindy,

I changed configuration to 'false' for 'registered' account on a couple of websites on 9th May and it stopped the spam accounts - so registered was allowing spam account creation - I will upgrade to 1.2.0 soon and see if it still happens in 'registered' and report back :)

cheers,
Mike

shags38:

Hi Cindy,

I changed configuration to 'false' for 'registered' account on a couple of websites on 9th May and it stopped the spam accounts - so registered was allowing spam account creation - I will upgrade to 1.2.0 soon and see if it still happens in 'registered' and report back :)

cheers,
Mike

Access Blocker doesn't show up in Plugins Search for some reason or other, in any variation of the term ?? - I got there by using your v1.1.1 update post in here - the latest download is v1.1.1 - is this correct?

cheers,
Mike

shags38:

Access Blocker doesn't show up in Plugins Search for some reason or other, in any variation of the term ?? - I got there by using your v1.1.1 update post in here - the latest download is v1.1.1 - is this correct?

cheers,
Mike
Mike, I misspoke when I said that Access Blocker was at v1.2.0; v1.1.1 is the most recent version.

Note, too, that the Zen Cart search functionality is pretty lame. I usually google "Zen Cart {whatever}", in this case "Zen Cart Access Blocker" to find what I'm looking for.

lat9:

Mike, I misspoke when I said that Access Blocker was at v1.2.0; v1.1.1 is the most recent version.

Note, too, that the Zen Cart search functionality is pretty lame. I usually google "Zen Cart {whatever}", in this case "Zen Cart Access Blocker" to find what I'm looking for.

Hi Cindy, I assumed as much but wanted to be sure :) I will keep the Google method in mind - the big disappointment is that a great deal of Zen Cart users are not using this great plugin because it doesn't show up in plugins ):

Been on 1.1.0 for a year now happy as a clam. This has got the be the most under-appreciated plug in out there. It shut the fake account creation down to zero and I haven't given it a thought in a long time.
Recently they have started back up again. I have been digging through things to see if everything is working and it seems to be. I think the newest attacker is just slipping through the ipdata.co filter.
Im keeping an eye on the who is online section in admin and adding any sketchy countries I see to the field in the access blocker settings.
Am I doing it right that the comma separated list should not have spaces after the commas?

All the recent fake accounts are using the same country for their fake customer.
Is there a place in the code I can add this feature to "Block by: Create-account Country"
Before now the filter *Block by: Create-account Company *set to google was sufficient to block the overwhelming majority of what was coming in.

angst:

Am I doing it right that the comma separated list should not have spaces after the commas?
Those comma-separated lists can include spaces, new-lines, carriage-returns and tabs (makes the configuration setting much more readable) ... so long as there's an intervening comma.

What version of Zen Cart is in use on the site? Any debug-logs generated at/around the time of the fake-account creation(s)?

Update: You can also set the Access Blocker's debug setting to 'all' which will also generate a request/response trace of communications to ipdata.co in /logs/ipData.log.

Access Blocker ver. 1.1.0
Zen Cart ver. 1.5.5f

In the configuration in the admin GUI there is only a toggle of debug on or off that creates a log of everything that ipdata has denied but it does not log all the traffic that it let though. I have that on long term and its amazing how many creations it is blocking each month. Over 700 blocks this month.

In includes/classes/ipdata.php
around line 9 is > if (!defined('IPDATA_LOGGING')) {

define('IPDATA_LOGGING', 'false');

If I change that to 'true' or 'all' will it create the file you mention and log all traffic including allowed traffic at /logs/ipdata.log ?

I don' think knowing where they are coming from is going to help me though. Im watching the "who is online" tool all day and am adding every random country that I see that has been on the contact us success page. I keep maxing out my allowed lookups at domaintools.com and am not making a dent in it. Here is what my country block comma separated list looks like so far. IS,NL,SG,ZW,MK,RU,CN,TW,IN,BE,PE,BR,CZ,RO,ZW,TH,UA,DE,BR,VN,SG,BG

Is there a place in the code I can add a feature to "Block by: Create-account Country" ?
100% of these accounts are filling in the customer as a certain country. If I could add that as a filter it would shut them down completely.

Access Blocker's debug simply creates a monthly log of accesses blocked, there's no provision to log all accesses and identify whether it's blocked or not.

The Block by Country and Block by Organization settings require an API call to ipdata.co to retrieve that country/organization information based on the active IP address. Noting, too, that starting with Zen Cart 1.5.2, you have the option of disabling countries so that the base Zen Cart processing will disallow that country from any customer address.

I normally keep Access Blocker's debug set to 'true' and then inspect those monthly blocked-access logs and add any new IP-address blocks to the Block by IP Address setting. The addresses in that list are blocked prior to making an API call to ipdata.co, so that they don't count towards your usage statistics.