store barraged with IP's adding huge amount of items to cart

At least 2 times over the past few years one of my sites gets barraged by various IP's which adds a huge amount of items to cart causing excessive CPU resource usage. It happened again today. Some of the IP's are in the same range. I add the IP's (deny from) to htaccess either individually or by range. Things are quieting down at the moment but one thing I noticed tonight is many of the session ID's are identical. How does that happen? Are there better ways to deal with it?

(I know the site needs to be upgraded but the site owner is not prepared to do that right now)

Session Ids are the ame because there is a link posted somewhere with the zenId on it

this problem is still going on. I've given up on adding to htaccess. Currently in who's online, "Host" is showing a slew of guests filling carts coming from wannabe.torservers.net and tor-exit-node.7by7.de. Any suggestions on what to do? Is this considered a denial of service attack?

If you can determine a common user agent, this plugin to block bad bots (or user agents) might be helpful. Just be careful that you don't block a legitmate useragent if using a partial string.

https://www.zen-cart.com/downloads.php?do=file&id=1854

There is also ip blocker, one for your version of ZC, the second for ZC 1.5.0+.

1.3.8 and 1.3.9
https://www.zen-cart.com/downloads.php?do=file&id=979

1.5.0+
https://www.zen-cart.com/downloads.php?do=file&id=1814

Depending on what market you sell too, I wouldn't consider that kind of traffic coming in via Tor Project node servers to be legitimate traffic. Both of those are Tor servers out of Germany. Its more about what the traffic is doing while on the site, rather then where they came from...could be someone using a Tor browser for privacy concerns.

barco57:

Depending on what market you sell too, I wouldn't consider that kind of traffic coming in via Tor Project node servers to be legitimate traffic. Both of those are Tor servers out of Germany. Its more about what the traffic is doing while on the site, rather then where they came from...could be someone using a Tor browser for privacy concerns.

They are adding huge amounts of products to cart, resulting in cpu use overage on the account, that's the problem. Our host has opened several tickets with warnings about scripts abusing cpu resources but haven't responded back to our response to the first ticket explaining what is happening and asking for suggestions.

Thanks, I'll suggest the ip blockers.

I'm wondering if adding a hidden field to the product info page would help? The hidden field to work as the 'honeypot' method used in the contact form works.

The product info page has a quantity input field, so if a robot fills in all input fields on the product info page then filling in the hidden field would prevent items being sent to cart. Could this work?

I haven't had a chance tonight to look into this but thought I'd post to see if anyone has thoughts on this.

buildingblocks:

I'm wondering if adding a hidden field to the product info page would help?

No.

buildingblocks:

The hidden field to work as the 'honeypot' method used in the contact form works.

I believe there's a bit of bad terminology here. A 'honeypot' is designed to attract wannabe hackers, not to discourage them.

buildingblocks:

The product info page has a quantity input field, so if a robot fills in all input fields on the product info page then filling in the hidden field would prevent items being sent to cart. Could this work?

That depends if the excessive serverload is the result of items being added to the cart, or if it is the shear volume of the requests. If it is the volume of requests then this could make things worse as the 'denial' caused by the 'honeypot' would occur quicker than the processing needed to add to the cart, so the next request(s) will come back even quicker than they had been.

OTOH, if the 'honeypot' aspect of the code is written to slow things down - ie, by causing no response to be returned to the requesting client at all. AKA 'tar pitting' them, this will slow the number of requests over a given time period, but it may or may not solve the server overload issue, because such connections will never be 'closed' causing more connections to remain open, which will also increase server load. Whether this increase will offset the reduction caused by preventing the adding to the cart is something that will need to be checked and monitored in 'real time'

buildingblocks:

I haven't had a chance tonight to look into this but thought I'd post to see if anyone has thoughts on this.

In addition to my comments above, this so called 'honeypot' is only effective against actual bots, and I'm somewhat surprised/puzzled that these bots are utilising the tor servers. I'm going to need to research this a little further because this isn't 'typical' bot behaviour (based on my current experience/knowledge). It is something 'new' (to me) - and that worries me. :-(

Cheers
RodG

RodG:

No.

I believe there's a bit of bad terminology here. A 'honeypot' is designed to attract wannabe hackers, not to discourage them.

That depends if the excessive serverload is the result of items being added to the cart, or if it is the shear volume of the requests. If it is the volume of requests then this could make things worse as the 'denial' caused by the 'honeypot' would occur quicker than the processing needed to add to the cart, so the next request(s) will come back even quicker than they had been.

OTOH, if the 'honeypot' aspect of the code is written to slow things down - ie, by causing no response to be returned to the requesting client at all. AKA 'tar pitting' them, this will slow the number of requests over a given time period, but it may or may not solve the server overload issue, because such connections will never be 'closed' causing more connections to remain open, which will also increase server load. Whether this increase will offset the reduction caused by preventing the adding to the cart is something that will need to be checked and monitored in 'real time'

In addition to my comments above, this so called 'honeypot' is only effective against actual bots, and I'm somewhat surprised/puzzled that these bots are utilising the tor servers. I'm going to need to research this a little further because this isn't 'typical' bot behaviour (based on my current experience/knowledge). It is something 'new' (to me) - and that worries me. :-(

Cheers
RodG

So. I was kind of on the path of use it, but like said let it somewhat use a timer for result but not too long of one... Biggest thing I've seen is the system draw of adding ever more product to a cart. But, all the above somewhat got me lost, leading to don't do anything different (otherwise I would think the final "solution" would be big bold and center. :) )

Of all of it, the thing that surprised me was the discussion that this method of approach to the site was "something new". I've seen it before as well, and yes had made some site changes based on the resulting concern. What if someone actually ordered that many product, or should someone see the remaining product at any time, etc... More from the perspective of what information is gained through doing this type of action outside of the technilogical testing of the site's response.

Whatever, seemed like this method of approach was considered new, which actually surprised me though I can't say I have worried about it as the remaining availability is untouched until the product is purchased, so no harm there...

mc12345678:

But, all the above somewhat got me lost, leading to don't do anything different (otherwise I would think the final "solution" would be big bold and center. :) )

The thing is, I'm not sure that there really is a good solution to this particular problem.

mc12345678:

Of all of it, the thing that surprised me was the discussion that this method of approach to the site was "something new". I've seen it before as well,

The hidden field approach is nothing new. I've never heard it called a 'honeypot' until now though, so I guess that part of it is 'new'.

mc12345678:

What if someone actually ordered that many product,

Only bots & hackers would/could populate a hidden input field, so this wouldn't affect real shoppers.

This is also what makes it an effective method to prevent bots from sending spam type messages.

I'm not convinced that it is a good technique to prevent what is essentially a denial of service attack, and this is what my input is/was relating too. Nothing more, nothing less.

mc12345678:

or should someone see the remaining product at any time, etc... More from the perspective of what information is gained through doing this type of action outside of the technilogical testing of the site's response.

Perhaps that is the entire purpose of this 'attack' - To see how the site/server can handle it?

mc12345678:

Whatever, seemed like this method of approach was considered new, which actually surprised me though I can't say I have worried about it as the remaining availability is untouched until the product is purchased, so no harm there...

What is 'new' is that this attack is/was apparently via the TOR network. As it turns out, it isn't quite as 'new' as I 1st thought, with the 1st such cases as 'recent' as 2012 (or thereabouts). I've not found anything in the way of any botnets currently utilising TOR, and the small handful that have been found since 2012 have been shutdown just as efficiently as botnets that don't use TOR.
Other than for experimental purposes, the only references I've found of bots using tor to populate a shopping cart relates to carts on the 'dark net', and that isn't applicable in this case.

In short, this particular case of a bot using tor to populate a public facing shopping cart is both new and unusual. It appears to serve no useful purpose to anyone.

About the only sensible thing I can think of at the moment is that the OP's server (or home computer) has been exploited and turned into a rogue tor server itself and the 'attack' on the actual store is some kind of fallout effect from this exploit. I'm really clutching at straws here though.

Cheers
RodG

I believe there's a bit of bad terminology here.

yes, probably is. I thought I had seen that field referred to as honeypot method in another post somewhere discussing the hidden field in the contact form.

I'm somewhat surprised/puzzled that these bots are utilizing the tor servers

not only coming from tor servers but I definitely found some coming from there. It's the first time I had ever heard of TOR.

OTOH, if the 'honeypot' aspect of the code is written to slow things down - ie, by causing no response to be returned to the requesting client at all. AKA 'tar pitting' them, this will slow the number of requests over a given time period, but it may or may not solve the server overload issue, because such connections will never be 'closed' causing more connections to remain open, which will also increase server load. Whether this increase will offset the reduction caused by preventing the adding to the cart is something that will need to be checked and monitored in 'real time'

I thought maybe the hidden field would be good because the customer wouldn't need anything extra to deal with. Given the concerns mentioned, would adding a captcha be better for the server overload issue?

Biggest thing I've seen is the system draw of adding ever more product to a cart.
exactly what happens. At any given time we could find numerous IP's adding a huge list of items to the cart.

buildingblocks:

yes, probably is. I thought I had seen that field referred to as honeypot method in another post somewhere discussing the hidden field in the contact form.

You probably did. Terminology tends to get corrupted and/or changed over time. As long as we are all on the same page it isn't really important.

buildingblocks:

not only coming from tor servers but I definitely found some coming from there. It's the first time I had ever heard of TOR.

That makes things even more 'interesting'. Sadly, it doesn't really help matters.

buildingblocks:

I thought maybe the hidden field would be good because the customer wouldn't need anything extra to deal with.

Agreed. However, don't forget that it isn't just a matter of adding a hidden field. To be of any use you'll also need to add code to check if the field is populated or not, and if it is, then what to do about it. There are several options here. Drop the request, Reject the request, Ignore the request, and so forth (you could even return a webpage that says something like 'you're a bot - Go away' (or something less polite) :-)

buildingblocks:

Given the concerns mentioned, would adding a captcha be better for the server overload issue?

My personal opinion is that Captcha's are 'evil'. Nothing causes me to leave a site faster than the appearance of a Captcha.

Whether they will reduce a server load is also something that is debatable - Sure it'll stop the bots adding products to a cart, but it won't have any positive effects on the number of requests made by the bots. As with the hidden field method, it could exasperate this situation as the bots will keep retrying for as many times they are coded for.

buildingblocks:

exactly what happens. At any given time we could find numerous IP's adding a huge list of items to the cart.

The Captcha or hidden fields will essential have the same effect. I'd go for the hidden field method any day. Not only will this method have the same net effect, as you say, it less burden on the customers - and with the hidden field method you will have complete control over what to do when a
request is made where this field is actually populated.
The downside is, the bots may not even populate the hidden field anyway - as this depends on the bot itself.

This really is a very difficult problem to solve, especially on a shared server. If you have a dedicated server there are a number of 'IDS' programs (Intrusion Detection System) that can be used to block these, and even a 'stateful firewall' can be configured to achieve good results).

There has also been mention of an IP blocker module for ZenCart - I've never used this myself so I don't know if this is a manual or automatic IP blocker, nor do I know what mechanism it uses to block 'rogue' IP addresses - but it may be worth looking into.

Cheers
RodG