Block IP Not Working?!!?

I had a few (almost certainly) fraudulent orders pass through my site. So, I blocked the one IP address being used.
A few hours later, the same account, with the same IP address made another six orders that cost me over $250. Anyone know why the IP block doesnt work?

Sure they could change their IP, use a VPN, etc. but they didnt and this was the first of three failing fraud checks.

You can block IPs via your web host which is probably the best thing to do.
Or via your htaccess file.

Thanks, but that seems like overkill for what it does. Mainly because an IP is so easy to change, but it is a feature so I thought it might work.

frankwho wrote:Thanks, but that seems like overkill for what it does. Mainly because an IP is so easy to change, but it is a feature so I thought it might work.

Then block a RANGE of IP's if you have to.

So the intent is not actually to block that IP from viewing the site or completing checkout. It is to simply shift them to an order status other than Complete / Pending?

That's how it's programmed. To make it even more confusing "Pending" actually means there's an issue as it's the default fallback order status I mentioned.

I think I get it. I said Pending though because I thought that was the default setting when a fresh install is done. To allow for shipping and such.
But since orders on my site need to reach Complete status before codes are available to the customer, then Pending an order because of a blocked IP would essentially be effective right? But how I do make orders from blocked IPs go to Pending?

avvici -arvixe- wrote:

frankwho wrote:Thanks, but that seems like overkill for what it does. Mainly because an IP is so easy to change, but it is a feature so I thought it might work.

Then block a RANGE of IP's if you have to.

I wasnt even going to reply to this, but there is this crazy thing called Tor and lots of others like it. They give you an IP from anywhere in the world. The purpose of my post was less about specifically blocking this certain IP so that can make the baddie go away, and more trying to figure out why this one small, and usually ineffective, but still available safeguard is not working.

frankwho wrote:But since orders on my site need to reach Complete status before codes are available to the customer, then Pending an order because of a blocked IP would essentially be effective right? But how I do make orders from blocked IPs go to Pending?

If you could easily spot it then it's effective. The blocking itself should occur automatically.

Honestly, Im not totally sure what you mean.
But, I do understand why it did not do what I expected it to. So thank you sir.

If an order being marked "Pending" is adequate enough for you to identify a customer with a blocked IP, then it's effective. The status itself should be applied automatically to any order with a banned IP.

It didnt mark as pending though. It went right to complete even though the IP was in my banned list.

You can block quad-decimal addresses and address ranges formally in .htaccess in the usual nnn.nnn.nnn.nnn pattern (there are specific syntax rules for ranges), but do not bother trying to block regions by name (such as .ru -- it's ineffective). Go easy, you do not want to turn .htaccess into a virtual telephone book of global baddies that will be the first file read (.htaccess is essentially the first website file read, putting aside various techospeak quibbles). The people who are up to no good have several means of hiding behind proxies located nowhere near them, of cloaking, of altering displayed machine and router Mac Addresses, etc.. Studiously blocking address ranges can substantially reduce bulk in .htaccess while substantially trimming traffic but some risk remains that some bad customers, spammers, and hackers will not be blocked.

frankwho wrote:It didnt mark as pending though. It went right to complete even though the IP was in my banned list.

I can't reproduce this on 1.5.5.1. Both existing and new accounts have the status set.

frankwho, where you mentioned, "this was the first of three failing fraud checks," was there a relatively formal fraud check in place that might require setup with an option mis- or unset, perhaps such as some of the PayPal safeguards -- or were you referring in that context just to three customer-events in the OC IP block in a generic and relatively loose sense of fraud check? The only version reference I see above is rph's as to 1.5.5.1 (just above), although in an unrelated and at the moment still unanswered post on Aug 23 you noted 1.5.5.1 specifically. In that as well as prior versions I haven't seen the IP block fail (if IP used, then IP blocked). Given some of the difficulties we've seen people have with order status, do the several order status elections jibe with each other and with context?

The three failures were IP Block, MaxMind, and Stripe itself since they run fraud checks, then emailed and said the sale was potentially fraudulent, and let it process anyways.

I am using 1.5.5.1 and System > Settings > Option > Order Status is set to Complete if that makes a difference.

do the several order status elections jibe with each other and with context?

Im not sure what this means, but I do seem to be having issues in other areas. Such as coupons not registering used, empty fields that seem like they should contain some order data, and even reward points not registering.

Oye.

Oye that I set orders to go to complete status or that I managed to somehow destroy a plug and play website?

Well, perhaps oye that there were too many things going on at once. Since IP Block, MaxMind, and Stripe have overlapping and probably not entirely complementary or supplementary functions among themselves, conflicts would seem possible. The coupons and order fields could spring from other things already in conflict. Try pulling out all of your extensions (you can slip them into a /vqmod/xml/setaside/ subdirectory), then putting them back in one at a time, and among those first three then two at a time before all three. If they are more core-intrusive modules than vqmod extensions are, then similarly disarm and rearm whatever is in play that is not working either at all or together. That rph couldn't "reproduce this on 1.5.5.1" (supra) tends to mean that you have substantially altered some aspect(s) of OC, and the usual way of pulling that off is by adding too much of whatever did not come with OC or is moreover not compatible with the version of OC.

You didn't destroy it. You have your config.php pair, your index.php pair, apparently vqmod, and your database running. You can replace all of the mere files (spare the foregoing four, don't overwrite them) from the OC .zip /upload/ tree. You do not need to reinstall the whole shebang. Just backtrack and take another run at it. An oye a day will keep your mind on it; when there's no more oye, relax.

frankwho wrote:Oye that I set orders to go to complete status or that I managed to somehow destroy a plug and play website?

You're fine. If you don't have the default order status set as pending then it won't show as pending when a banned IP orders. MaxMind and Stripe (not sure what that is) aren't related to the banned IP feature.