How to defend Prestashop from spam and bots?

Any site on the WEB must sooner or later deal with "malicious" bots and spam, if not also with attempts to attack in order to infect or compromise the site itself. The enormous speculation surrounding cryptocurrencies since 2016 has made the problem significantly concerning, even just for the continuous attempts to infect websites in order to distribute to unsuspecting visitors malicious programs and scripts aimed at mining cryptocurrencies. 2017 was worse than 2016, and 2018 is set to be no different. Since January, I have received several support requests and have often read on forums about issues related to this phenomenon, from those complaining about receiving countless emails in a few hours (for example), to those complaining about detecting unusual and continuous carts.

Even without these warning signs, a marked discrepancy between PrestaShop statistics and Analytics, or a conversion rate of 0.009 - or a significant decrease of the same value - should raise suspicion.

DIFFERENCES BETWEEN PRESTASHOP STATISTICS AND ANALYTICS

Why do the statistics data from PrestaShop differ so much from those of Analytics? This is one of the questions that can often be found in forums or asked by customers. Behind this question lies one of the biggest plagues of the web, hundreds of thousands of computers, servers, and infected devices that do nothing but attempt some illicit activities, from simple SPAM sending to intrusions into computer systems with the aim of stealing data. These "bots," even when they fail to cause any damage to our systems because we have made them sufficiently secure (they will never be completely secure, especially where, as in the case of e-commerce, a compromise between functionality and security is necessary), are still a problem as they consume bandwidth and resources. In fact, often when we complain about the performance of our hosting or dedicated server, we get frustrated with PageSpeed, Pingdom, GT Metrix, and other analysis tools, trying to implement their recommendations without achieving real results. In reality, much of the resources and bandwidth is stolen by intrusion attempts and spam, and partly by the phenomenon of hotlinking. So even when this abnormal traffic does not cause damage, it still uses resources and therefore incurs an economic cost. The more important and visited our e-commerce is, the more this phenomenon becomes a serious problem, so serious that often paid services like CloudFlare are resorted to; spending 200 dollars a month just to defend against junk traffic is obviously not sustainable for a small merchant or small business, but at certain levels, it becomes mandatory.

For the CMS Joomla and WordPress, it is very easy to use Project Honey Pot, for which we are working on creating a module for its integration into PrestaShop.

WHAT TO DO?

FIRST RULE: the first thing to do is to perform a thorough scan of all the devices and computers we use to operate our ecommerce. Keep in mind that "I USE A MAC" is not a valid antivirus, so equip each of your devices with antivirus and antimalware software that protects against exploits, malware, and ransomware. Avoid installing pirated software; those who distribute it do not do so without a purpose, and the majority contains "little gifts," so it's not just out of fear of a visit from the BSA, but to protect yourself. Many software options also have very valid open-source alternatives; for example, LibreOffice and OpenOffice are not only great alternatives to Microsoft Office, but they handle CSV files much more easily.

If the systems you use to manage the ecommerce are not secure, it is pointless to waste time implementing security.

SECOND RULE: before installing a module on your ecommerce in PrestaShop, verify it, especially if the module is released for free or comes from an unknown source. Verifying a module is very simple, and you can use the same resources that PrestaShop provides to us Developers. So register and use: https://validator.prestashop.com especially check the Errors and Security sections. I also recommend always installing the module on a non-production copy of your ecommerce with DEBUG mode active; it is very useful and essential to have a test copy of your ecommerce. You can also keep it locally on your PC using AMPPS or similar. I also recommend deactivating and uninstalling all unused modules.

Be cautious, especially of PHP scripts or modules that obscure part of the code making it unreadable (e.g., base64_encode).

THIRD RULE: essential tools include: Google Search Console*, Google Analytics* (or another statistics service), and especially real-time access to the log files of your domain. Your ecommerce is your business; do not skimp on hosting. If you do not have real-time access to the log files, you will have no way to find the source of any attacks or identify potential problems. Many well-known hosting services offer the possibility to consult a copy of the logs from the previous day, which is better than nothing, but not sufficient. When choosing a service, always check that there is also an Anti-DDoS system, one of the minimum security requirements.

  • Google Search Console should be consulted often; do not wait for alerts to arrive.
  • Google Analytics should be checked daily, even when you do not have active campaigns.
  • Server log files should be checked once a week or at least once a month.

*) We recommend our module Art Webmaster Tools Site Verification and Hreflang to activate and include these services.

What to check: the presence of errors 500, 502, and 503 can also be caused by a sudden spike in junk traffic. This is where the server log files become important, as they record the IP of the person who made the request for the page that caused the error, the possible cause of the error, and any parameters passed in the URL itself. By sifting through the log files, you will also find requests like: /phpmyadmin/scripts/setup.php, /wp-login.php; these requests are all made by bots trying to exploit known vulnerabilities in systems (the most popular being WordPress). NOTE: always remember to regenerate the robots.txt file as soon as we notice unusual traffic or receive spam. To do this, go to: settings > SEO & URLs in the backend of our ecommerce in PS.

NOTE: always remember to regenerate the robots.txt file as soon as we notice unusual traffic or receive spam. To do this, go to: settings > SEO & URLs in the backend of our ecommerce in PS.

WHAT TO DO IF YOU RECEIVE SPAM?

Let's see a practical case: you start receiving a bombardment of spam emails, and the country in the requests always shows France.

In these cases, we find that spending a few extra euros can save us a lot of time. If your hosting provider gives you access to real-time log files, you can immediately identify the source. Even better if your service provides you access to an advanced panel like Plesk.

From the log files searching specifically for /fr/contattaci (part of the URL of the support request page, check your URL) it becomes clear that a bot with IP xxx.xxx.x55.29 and xxx.xxx.x55.29 is sending continuous contact requests. We can also check where the attack is actually coming from (there are many services available on the WEB) for example: https://www.tcpiputils.com/

If you are a masochist and do not have PLESK or any other control panel for your service, you can download the log file locally and use the glogg utility to search within the same file. I admit I learned by struggling with insufficient resources and during times when every single MB cost as much as a month's salary, but if your goal is to do business online with your e-commerce, I will never tire of saying: do not skimp, because you will regret it.

All that remains is to block the two IPs; to do this we have various options: use one of the many modules available for PrestaShop like "Block Bots / Users based on IP, Country or User-Agent" or modify the .htaccess file, which is a more complex operation. Let's see an example:

INSERT AFTER THE LINE:

# ~~end~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

THE FOLLOWING DIRECTIVES:

SetEnvIf Remote_Addr XXX.XXX.X55.31 bad_user
SetEnvIf Remote_Addr XXX.XXX.X55.29 bad_user
Deny from env=bad_user
ErrorDocument 403 /error403.html

That is, the IP we want to exclude; in this way, it will receive the error page 403: access denied. We can also decide to redirect the traffic elsewhere. In this case, in the example (which is a real case), the SPAM was coming from South Africa. Alternatively, we could also choose, if we do not sell in that state and do not intend to do so in the future, to block all traffic coming from that country.

To exclude a country, we must use the international code that identifies it; in the case of South Africa, it is ZA, so:

SetEnvIf GEOIP_COUNTRY_CODE ZA bad_user
Deny from env=bad_user
ErrorDocument 403 /error403.html

Note: the country ban requires that mod_geoip is active on your hosting.

To keep everything safe: once the IPs responsible for the SPAM are banned, you will automatically no longer receive them. However, it is always better to prevent than to cure because if the bot changes IP, the problem will reappear, so it is advisable to directly insert a reCAPTCHA in the PrestaShop contact form. For this, there is also an excellent module Add Google reCAPTCHA to store forms developed by InnovaDeluxe. It is important to update to the latest version of PrestaShop; in some older versions, even adding a reCAPTCHA filter will not solve the problem.

If you are wondering why not just limit yourself to simply inserting the reCAPTCHA, the reason is very simple. These bots do not check the outcome of the submission, so the automatic program would continue to attempt to send SPAM, consuming resources because with each submission our SERVER will process the request. By banning IPs, we will consume fewer resources, leaving them available for that quality traffic that brings us conversions.

NOTES: it is much more serious and annoying when the module "SEND TO A FRIEND" is targeted, which I recommend completely uninstalling; it is not enough to deactivate it. A bot that exploits this module can lead to the temporary suspension of the email account you have configured in PrestaShop, up to a ban of your server's IP. So if you receive many delivery failed messages in your mailbox that you use for your e-commerce, take action immediately.

CONCLUSIONS

If despite using reCAPTCHA you still receive spam emails, especially if the attack has been very intense with hundreds of emails per day, it may mean that there is no Anti-DDoS filter upstream of your server, so you have a serious security problem. It is not necessary to equip yourself with a hardware firewall, although it is recommended, but having at least a basic Anti-DDoS system is mandatory. If you are not on a dedicated server but on shared hosting, ask your provider how to activate the firewall; for example, OVH allows you to activate the firewall with a simple click from the hosting control panel.

Author: Loris Modena

SENIOR DEVELOPER

Per Ind Loris Modena, owner of Arte e Informatica, started working in the IT sector in 1989 as a system administrator responsible for the maintenance and installation of computer systems. He began programming for the web in 1997, focusing on CGI programming in PERL and later transitioning to programming in PHP and JavaScript. During this time, he became familiar with the Open Source world and the management of Linux servers.

Product added to wishlist