I made this and find it somewhat useful...I question the need for it a little because I don't know if the offenders actually come back or not, who knows.
Working on 3.0.3.9, this monitors all form submissions for real person input, if it's not a live person it logs the ip to the database once. Then there is a cron file outside the public folder to draw from the database ( I would set the cron to once every 1 or 2 min if you choose to do it) and write that banned ip to the htaccess file to deny access and then email you if a new ip has been blocked. I'm actually going to have mine write to the firewall, but figure this is easier to disseminate amongst everyone. It also logs the IP in the admin log which you can comment out. This also does the same thing for people accessing your site with wp login and wp admin in the url, and also trying to get into the admin. As far as the admin goes (if you have done the same as me and renamed it and kept an empty admin dir) if you left the empty admin dir, if someone goes into that dir their ip will also be banned.
The only thing to consider with this is if the offenders are doing this through a VPN and your customers are also using that vpn IP. With that said, you can simply not setup the cron to ban ip, it will still prevent none live people from submitting forms.
1/ Place custom_ip_block.php outside of the public folder and point your cron to it. Edit the database and email settings at the top.
2/ Delete this mod's admin dir if you didn't rename your default admin folder, and have no care for a decoy admin dir. If you keep it edit the database info at the top.
This was created to work with Journal 3.2 in mind, but the layout is clear to edit the code to the default theme. I don't have time to provide support, but it works for me as is. I'm sharing this here because some of the coding is a little hacky/none ideal opencart format to just get it done, and no admin page for settings....everything that needs editing is directly to the code.
Question for those that know. I would prefer writing to the htaccess immediately instead of through a cron, but I didn't want to put any file that could access the htaccess in the public folder. Considering that this is actually a mod, and the edited files that would contain the code to write to htaccess is in the storage folder, would it be safe to code this so it writes to the htaccess from within the modified files instead of cron?
v3.0.3.9 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
Quick update for security issues, I didn't test it yet but it should work:
On the install.xml Add
After
And then close this condition before the last closing tag.
And in catalog/model/catalog/custom_spam_tracker.php put $this->db->escape() around all three variables being inserted in the database.
On the install.xml Add
Code: Select all
if (!filter_var($ip_spam , FILTER_VALIDATE_IP) === false) {Code: Select all
$ip_spam = $_SERVER['REMOTE_ADDR'];
}And in catalog/model/catalog/custom_spam_tracker.php put $this->db->escape() around all three variables being inserted in the database.
v3.0.3.9 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
if you already have a means to identify and prevent bots from forms submissions, why the need to block the ip?Joe1234 wrote: ↑Fri Jun 14, 2024 12:47 pmI made this and find it somewhat useful...I question the need for it a little because I don't know if the offenders actually come back or not, who knows.
Working on 3.0.3.9, this monitors all form submissions for real person input, if it's not a live person it logs the ip to the database once. Then there is a cron file outside the public folder to draw from the database ( I would set the cron to once every 1 or 2 min if you choose to do it) and write that banned ip to the htaccess file to deny access and then email you if a new ip has been blocked. I'm actually going to have mine write to the firewall, but figure this is easier to disseminate amongst everyone. It also logs the IP in the admin log which you can comment out. This also does the same thing for people accessing your site with wp login and wp admin in the url, and also trying to get into the admin. As far as the admin goes (if you have done the same as me and renamed it and kept an empty admin dir) if you left the empty admin dir, if someone goes into that dir their ip will also be banned.
The only thing to consider with this is if the offenders are doing this through a VPN and your customers are also using that vpn IP. With that said, you can simply not setup the cron to ban ip, it will still prevent none live people from submitting forms.
1/ Place custom_ip_block.php outside of the public folder and point your cron to it. Edit the database and email settings at the top.
2/ Delete this mod's admin dir if you didn't rename your default admin folder, and have no care for a decoy admin dir. If you keep it edit the database info at the top.
This was created to work with Journal 3.2 in mind, but the layout is clear to edit the code to the default theme. I don't have time to provide support, but it works for me as is. I'm sharing this here because some of the coding is a little hacky/none ideal opencart format to just get it done, and no admin page for settings....everything that needs editing is directly to the code.
Question for those that know. I would prefer writing to the htaccess immediately instead of through a cron, but I didn't want to put any file that could access the htaccess in the public folder. Considering that this is actually a mod, and the edited files that would contain the code to write to htaccess is in the storage folder, would it be safe to code this so it writes to the htaccess from within the modified files instead of cron?
Blocking ips is really only a good idea when dealing with DOS or DDOS attacks and then via the firewall and even then only on an immediate and temporary basis.
Thanks for the reply, you quoted me but you missed a couple points.
1/ I questioned the need for it because I wondered if people actually keep coming back so banning ip may be unnecessary. I don't know, so as far as I believe keeping them off the site once identified by blocking them would help with resources and keep the site running fast. My site has been running faster more consistently.
2/ I did say I will have mine write to the firewall. I don't know everyone's server structure or how their firewall file is configured to code that automatically.
Either way, I think the automatic banning of the ip is good at least for an htaccess specifically for the admin section.
Or, I could add a count to the ip table and anyone passed say 10 gets banned because they are coming back, or add a date difference lookup with the ip so if they come back another day they clearly need to be banned.
Thanks for pointing out the need for blocking to be temporary, I really didn't understand how ddos attacks worked until I just looked it up. I could end up blocking a future or current customer. Since I only accept customers from the US I may end up changing that to only blocking IP outside of the US. And I may also implement something to remove IP blocks after a certain amount of time (I have a quick idea of how to do that, not sure if it will work).
Either way, good points, I'll look into it when I have time....or if anyone wants to jump in to make some adjustments and repost the mod.
1/ I questioned the need for it because I wondered if people actually keep coming back so banning ip may be unnecessary. I don't know, so as far as I believe keeping them off the site once identified by blocking them would help with resources and keep the site running fast. My site has been running faster more consistently.
2/ I did say I will have mine write to the firewall. I don't know everyone's server structure or how their firewall file is configured to code that automatically.
Either way, I think the automatic banning of the ip is good at least for an htaccess specifically for the admin section.
Or, I could add a count to the ip table and anyone passed say 10 gets banned because they are coming back, or add a date difference lookup with the ip so if they come back another day they clearly need to be banned.
Thanks for pointing out the need for blocking to be temporary, I really didn't understand how ddos attacks worked until I just looked it up. I could end up blocking a future or current customer. Since I only accept customers from the US I may end up changing that to only blocking IP outside of the US. And I may also implement something to remove IP blocks after a certain amount of time (I have a quick idea of how to do that, not sure if it will work).
Either way, good points, I'll look into it when I have time....or if anyone wants to jump in to make some adjustments and repost the mod.
v3.0.3.9 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
In general,Joe1234 wrote: ↑Sat Jun 15, 2024 7:55 pmThanks for the reply, you quoted me but you missed a couple points.
1/ I questioned the need for it because I wondered if people actually keep coming back so banning ip may be unnecessary. I don't know, so as far as I believe keeping them off the site once identified by blocking them would help with resources and keep the site running fast. My site has been running faster more consistently.
2/ I did say I will have mine write to the firewall. I don't know everyone's server structure or how their firewall file is configured to code that automatically.
Either way, I think the automatic banning of the ip is good at least for an htaccess specifically for the admin section.
Or, I could add a count to the ip table and anyone passed say 10 gets banned because they are coming back, or add a date difference lookup with the ip so if they come back another day they clearly need to be banned.
Thanks for pointing out the need for blocking to be temporary, I really didn't understand how ddos attacks worked until I just looked it up. I could end up blocking a future or current customer. Since I only accept customers from the US I may end up changing that to only blocking IP outside of the US. And I may also implement something to remove IP blocks after a certain amount of time (I have a quick idea of how to do that, not sure if it will work).
Either way, good points, I'll look into it when I have time....or if anyone wants to jump in to make some adjustments and repost the mod.
blocking ip adresses, individual or ranges are bad unless you are facing a (D)DOS attack, then the block should be immediate and temporary.
blocking country ip ranges is also futile as those ranges are traded on a daily basis, what is today a Russian range will be a Spanish range tomorrow.
Besides, most spammers/hackers (except for the very poor amateur guys) no longer use their country ip addresses, they rent an ip range at AWS, Azure, Rackspace, or use a VPN, etc. in your very own country, courtesy of cloud services.
So if you can detect a bogus POST request, form-wise or otherwise, ignore it and move on, no need to manage it any further.
It often makes sense though to block a detected spammer for the whole initial session with 403 responses, for subsequent requests in the same session. That's how we do it in our SpamBot Buster.
Of course using the Journal3 framework isn't helpful and probably tends to make a website less secure.
Of course using the Journal3 framework isn't helpful and probably tends to make a website less secure.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
That is true as those spammers/probers tend to issue many requests per second so blocking that ip, temporarily, upon detection might help.JNeuhoff wrote: ↑Mon Jun 17, 2024 7:58 pmIt often makes sense though to block a detected spammer for the whole initial session with 403 responses, for subsequent requests in the same session. That's how we do it in our SpamBot Buster.
Of course using the Journal3 framework isn't helpful and probably tends to make a website less secure.
But most of those request bursts will have passed before you have managed to put that ip in your firewall or htaccess.
Mind you, bots don't do sessions so the ip is all you have to go on for that period of time.
I agree, which leads me back to a question in my OP. Is it safe to put coding that writes to the htaccess/firewall in a modified controller file since that file is in the storage dir outside of the public dir?
I did not know this, good to know. I block by actual country in the firewall instead of by actual IP, is that the same thing?nonnedelectari wrote: ↑Mon Jun 17, 2024 7:15 pmblocking country ip ranges is also futile as those ranges are traded on a daily basis, what is today a Russian range will be a Spanish range tomorrow.
I'll do more tests on time to write and stuff, but this makes sense in light of what I've learned here. I don't know how to do it by session, but I could probably set up a cron to erase it after 24 hours or something.
v3.0.3.9 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
The only thing I can think would be an issue with the location would be if you had bots doing lots or requests you would be doing lost of write to your htaccess. At least with a cron you will only be writing every so often.
Joe1234 wrote: ↑Thu Jun 20, 2024 10:03 pmI agree, which leads me back to a question in my OP. Is it safe to put coding that writes to the htaccess/firewall in a modified controller file since that file is in the storage dir outside of the public dir?
I did not know this, good to know. I block by actual country in the firewall instead of by actual IP, is that the same thing?nonnedelectari wrote: ↑Mon Jun 17, 2024 7:15 pmblocking country ip ranges is also futile as those ranges are traded on a daily basis, what is today a Russian range will be a Spanish range tomorrow.
I'll do more tests on time to write and stuff, but this makes sense in light of what I've learned here. I don't know how to do it by session, but I could probably set up a cron to erase it after 24 hours or something.
Don't know which firewall you are using but I am pretty sure your "country block" is ip based, there is no other way really.I block by actual country in the firewall instead of by actual IP, is that the same thing?
htaccess is a very old concept from the early days of web pages, mostly intranet really, not designed for high traffic internet sites.
It is now used by shared hosted services to allow clients to make some changes on their own because they won't allow you to change the full server config.
These files are not cached, read on every request and therefore not suited for dynamic high volume ip blocking, that is why firewalls are here.
You can dynamically add blocks, ip-wise or otherwise, to htaccess files, I have and dropped it again, but the benefits are limited for DOS attacks as it is to late in the process flow, the request still invokes the webserver process, still reads/writes htaccess, still produces a response. With a firewall entry, the request is simply dropped.
Who is online
Users browsing this forum: nonnedelectari and 18 guests
