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

[buildingblocks]

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)

[Merlinpa1969]

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

[buildingblocks]

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?

[RixStix]

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

[mc12345678]

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

[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.

[buildingblocks]

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.

[buildingblocks]

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.

[RodG]

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

No.

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.

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'

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

[mc12345678]

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...