Unsuccessful OpenCart Hack Attempt

Hi all,

My module has been picking up a series of hack attempts on my admin overnight:
Is anyone keeping a central log of IP addresses worth blocking due to this behaviour ?

- Mel

Thanks man, added to APF. Indeed it would be nice to have a list of OC specific bad IP's trying to brute in or inject.

The only other admin attempt recently ive seen is 23.249.163.35

well if you dont sell to a certain country than just block those ip's example I block China, Iran, Russia, Africa to name a few

tmccaffe wrote:well if you dont sell to a certain country than just block those ip's example I block China, Iran, Russia, Africa to name a few

Also you need to block hosts entire ASN ranges since your server will never need to talk to another server. Blocking a country is one thing for ISP level users, but most of the abuse comes from servers.

Our APF blocklist (ASN's were recently purged): https://src.creadev.org/apps/apf/deny_hosts.rules

Blocks:
AS4134 ChinaNet
AS4837 China Unicom Backbone
AS4538 China Education and Research Network Center
AS9808 Guangdong Mobile Com
AS9394 China TieTong Telecommunications Corporation
AS49120 Gorset Ltd
AS44387 PE Radashevsky Sergiy Oleksandrovich
AS47142 PP Andrey Kiselev
AS15895 Kyivstar PJSC
AS50915 S.C. Everhost S.R.L.
AS9829 National Internet Backbone
AS17974 PT Telekomunikasi Indonesia
AS26347 Dream Network LLC
AS43350 NFOrce Entertainment BV
AS63008 Contina
AS53264 Continuum Data Centers, LLC.
AS36352 ColoCrossing
AS16276 OVH SAS
AS57858 Fiber Grid OU
AS53889 Micfo
AS62904 Eonix Corporation 1
AS30693 Eonix Corporation 2
AS55286 B2 Net Solutions Inc.
AS18978 Enzu Inc
AS15003 Nobis Tech Group
AS29761 Quadranet

How to you get this list? Do you actually use a tool or do it by hand to insert in the htaccess?

This list was made by hand, with a tool, and with automated ban tools like CpanelHulk and BFD.

I should mention this awesome site which is great for making ASN range lists: https://www.enjen.net/asn-blocklist/ind ... e=htaccess

That example link will put the whole ChinaNet range into htaccess format (or whatever other format you need) for banning. Its good to purge the ASN's every 3 months to make sure they didnt gain or lose any IP's

why don't add only known host for admin logins to the htaccess file for admin?

bero wrote:why don't add only known host for admin logins to the htaccess file for admin?

You can do that, there is a whitelist with password protect fallback tutorial here http://stackoverflow.com/questions/7667 ... -whitelist

The problem with just whitelisting (without password fallback) is that you will be constantly locked out on dynamic IP networks like DSL, mobile, or similar

True, but if you like security, you will use a proxy or VPN

I wanted to block certain countries from even seeing my site. However, it's not full proof because of proxy servers. In my admin area I use ip address only for me. Sometimes my ip address of course changes which is a pain but it can be just changed again no big deal. Another thing would be actually make a false admin directory I read this scheme somewhere and put a couple files in it.

Name the false admin directory "wp-admin" or "wp-login" and you will get tons of hits there. In the index you can make a tarpit (pseudo/fake blog logger for banning them) and a honeypot (from projecthoneypot.org)

I think either I have been hacked or messed something up. I tried to login to my admin and says invalid password.

I even went to phpmyadmin and changed password still cant log in

http://www.opencart.com/index.php?route ... earch=spam

Do you know if this module works with new version? Anything similar to it.

Yeah it works last i knew. We made one too. SFS doesnt support IPv6 yet though. The best bet to protect forms is making a hidden field that if filled out invalidates the POST. Humans wont see it, and if its blank it will let you through. Bots always see it though and fill it out, so they can never POST. Lets make this for admin form using fake email field.

Something similar to this at the top of admin login controller:
Then add this to admin login TPL:

Use cloudflare free (opencart uses cloudflare), also google 2factor is great to deter brute force and it's free but I don't know a free module exists on Opencart to use.

Beeing not mathematic professor, I always had a heck of a time to understand such: so I use a more 'newbie-way' to keep some fellow's off some of my sites, containing 'Customer Comment Forms'.
I enclose a file, I use for many years, updated, either 'selectively' oder 'globally', after new hacking attempts.
Possibly usefull, but not just usable for OC, it's made more for a 'regular' Site. Parts of it could be used in an OC .htaccess file, by nature of things...

Ernie

Lol, ok than someone uses a proxy and blows your .htaccess file to bits because you're not blocking that IP....bad choice.

Cloudflare has a global database of threats, and it learns and improves every day...and they have a free plan. Don't waste your time, change two boxes on your domain management panel (DNS name servers) to cloudflare and be safe and secure without even wasting a moment on thinking about it.

ocmobi wrote:Lol, ok than someone uses a proxy and blows your .htaccess file to bits because you're not blocking that IP....bad choice.

Correct, but most of the [web/vpn] proxies use those bad hosts, so by blocking at ASN level you are more successful than a manually curated or country based list offenders.

ocmobi wrote:Cloudflare has a global database of threats, and it learns and improves every day...and they have a free plan. Don't waste your time, change two boxes on your domain management panel (DNS name servers) to cloudflare and be safe and secure without even wasting a moment on thinking about it.

Although Cloudflare is awesome, it still misses huge amounts of threats. For a mature site with good traffic, I estimate they catch maybe 1 out of 10 bad visits unless you block whole countries. This is because of their liability -- they wont block china or ukraine mobile ASN's for example which is the source of significant amounts of crap. And, you dont wanna block whole countries unless its somewhere where you dont sell. So if you are going the country block route, CF is good....but again, ASN is far more successful since 90% of the bad-origins come from the same 30-50 hosts and they may span countries (OVH for example).

OVH is actually a good thought -- its a host so all the traffic from them to you is machine/server/website. CF blocks very little from them, and in order to mass block their traffic the country way, you would have to lock out Canada and France. Their IP pools are switched and abused so often that it is not feasible to pick and choose what to allow. Considering most hosts are moving IPV6 this is compounded - you will never keep up with their pools. So as much as CF can help, just ASN block and be done with it for real rather than assuming youre safe behind a CF threat block that is too transparent and doesnt mitigate enough clauses (because they dont wanna mess with their customers). Security seems to always comes down to DiY...just do it yourself and do it right, tailored to your own realm.

Here is an experiment and shows the relation [roughly] between what CF considers a threat [red], and all the stuff it misses [yellow]. The yellow is a country block. We get about 0 legit traffic and dont sell/target to any of those countries. This means that CF missed 85% of bad traffic even though most of them are well known and BL listed IP's. Upon turning the country block off, the good traffic can still trickle in while their bad ASN's are still being blocked at a greater than or equal to level. The sad part is that even in the latter, there are still no legit users visiting from the 85% pool that can potentially connect (im looking at you France).

It's also tough to understand exactly what we're discussing. A lot of people throw around the term hack, so it's not ideal and covering security encompasses a lot.

1) You need good hardware and software (server and script level) that is monitored and updated frequently. ie bash and poodle...so it's ideal to have control of your own environment and be a bit of a system admin guru and harden everything and patch everything. And for software keep up with Opencart updates and patches, otherwise your SOL if someone wants to exploit a known vulnaribility.

2) Using cloudflare far outweights not using it not just for the security benefits but also for all the CDN and other benefits.

3) I'm confused by what you say allowing bad requests in, what exactly is the harm in a bad origin IP visiting your box? Default cloudflare stops SQL injections, denial of service, and other things which is great protection to have. A known bad IP visiting hardly is a threat especially if it's just spam related for example. A lot of people/ip's get flagged and are false positives and if at worst they spam it's not the end of the world and yes you're left with maintining a blacklist but there are other services for that as well like project honeypot and many others so you can incorporate that

4) It's best to incorporate as many solutions as possible from hardware, to software, to available services since there is no magic solution and security constantly evolves. Cloudflare also has paid services which are better than what they offer for free, but your way better off with cloudflare than you are without it just trying to block ips since that doesn't offer many other things they do.

5) Shared hosting is also inherently flawed by design so you open yourself to a wide range of other potential issues just by being exploited by your neighbors, sharing ips, and etc.

But you're right if your targeting a US market and don't want any other countries, why not block everything. Doesn't mean it'll work, but it's at least one step of many others that can be taken to protect yourself.

One audit we did internally was that customers we've worked with in the past left FTP accounts exposed even after our business was done and that they had re-used accounts given to us for others as well. We emailed them asking them to disable FTP accounts, change passwords, monitor and audit this more closely but it's either out of their understanding or they just can't be bothered so there's a lot of things people do that get themselves hacked unfortunately too. Or simple permissions issues on servers that leave exploitation relatively simple.

All I recommend is backups and free cloudflare because I know people want to spend less, put in little to no effort, and auto-pilot things so at that level it leaves a lot of things out. Otherwise manual intervention, paid services (hosting and security) it the way to go.

Yah CF is cool and I agree that its better to run it than not run it....not trying to argue and things, i respect your angle. Was just sharing how and why there is a misconception that they are the super wall. Its actually pretty weak and an annoyance for real users in many cases (such as these fine forums). Also their mod_sec is basically not functional and the DDoS is very limited on free account so you end up paying $20+ a month and it isnt much better. Honestly too, CF itself has had handfuls of its nodes taken down more than monthly by DDoS lately. How is it that they cant protect themselves against DDoS with such robust protection? Their DNS should never go down with such dilution....but it does and quite often.

Again, its better than nothing, but moreso for the free SSL, minifiers, and CDN. As far as threats go, you could spend 10 minutes or less every quarter and purge + paste in a more encompassing and padded list of about 10 ASN and not worry about it for a long time until they acquire more cblocks. Example, denying OVH completely and killing MANY proxy services without blocking either canada or france: https://www.enjen.net/asn-blocklist/ind ... ype=iplist

Speaking of the CF inject prevent, try out the OWASP XSS knowns and perhaps all of them will go through to your site. If CF was blocking them, you would see the CF denied page right due to malformed post data? Well i was able to post all of these https://src.creadev.org/dev/1564/about_us

Same with the most basic of basic SQL inject, CF should be stopping this right? Nope this is 403 from mod_sec+OWASP on our serv...CF let it by: https://src.creadev.org/dev/1564/deskto ... 20or%201=1

And there is harm when bad IP's visit, even if they "dont do anything". Most of the time, they are harvesting, setting a deploy, scanning for libraries, or gathering viable urls for their other bot brethren to abuse. So blocking 1 bad [scanner] that did nothing on the surface often eliminates 10-fold dictionary/brute/spam/harassing floods. Again, this is the advantage of a curated list (of those ASN's). Total bot domination.

Sadly manual work is the reality of running an ecommerce store whether the inexperienced [or lazy] OP's accept it or not. Just gotta get er done yourself one way or another.