Your cart
There are no more items in your cart
- Arte e Informatica
- Blog sulla sicurezza online
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 same site. The huge speculation that has been hovering behind cryptocurrencies since 2016 has made the problem considerably worrying, if only due to the constant attempts to infect websites in order to distribute malicious programs and scripts that are intended to mine cryptocurrencies to unsuspecting visitors. 2017 was worse than 2016 and 2018 reserves the right not to be outdone. Since January I have received several requests for assistance and read very often on the forums about problems relating to this phenomenon, from those who complain of receiving countless emails in a few hours (example), to those who complain of detecting abnormal and continuous carts.
Even without these red flags, a marked discrepancy between PrestaShop and Analytics stats, or a conversion rate of 0.009 - or a major decrease of the same value - should be suspicious.
DIFFERENCES BETWEEN THE STATISTICS OF PRESTASHOP AND ANALYTICS
Why are PrestaShop statistics data so different from Analytics data? It is one of the questions that can often be read in the forums or can be asked by your customers. Behind this question lies one of the biggest scourges of the network, hundreds of thousands of infected computers, servers and devices that do nothing but attempt some illicit activity, from the simple sending of SPAM to the intrusion into computer systems in order to steal data. . These "bots" even when they fail to cause any damage to our systems as we have made them sufficiently secure (they will never be in reality especially where, as in the case of ecommerce, a compromise between functionality and security is required) are still a problem as they steal bandwidth and resources. In fact, often when we complain about the performance of our hosting or dedicated server , we get hot on PageSpeed, Pingdom, GT Metrix and other analysis utilities, trying to implement the recommendations without obtaining real results, in reality many of the resources and bandwidth is stolen by intrusion and spam attempts, and in part by the phenomenon of Hotlinking. So even when this anomalous traffic does not create damage, it still uses resources and therefore causes us economic damage. The more our ecommerce will be important and visited, the more this phenomenon becomes a serious problem, so serious that we often resort to paid services such as CloudFlare, spending $ 200 a month just to defend against junk traffic is obviously not sustainable for a small merchant and the small business, but at certain levels it becomes mandatory.
For Joomla and WordPress CMSs it is possible to use Project Honey Pot in a very simple way for which we are working on the creation of a module for its integration into PrestaShop.
WHAT TO DO?
FIRST RULE : the first thing to do is a good scan of all the devices and computers we use to operate on our ecommerce. Keep in mind that "I USE THE 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 the installation of pirated software, the distributors do not do it without a purpose, the majority contain "little gifts", so it is not for fear of a visit from the BSA, but to protect yourself. Many of the software also have very good open source alternatives, for example LibreOffice and OpenOffice are not only a great alternative to Microsoft Office, but they handle CSVs much easier.
If the systems you use to manage ecommerce aren't secure, there's no point wasting time implementing their security.
SECOND RULE : before installing a module on your e-commerce in PrestaShop, check it, especially if the module is released for free or comes from a source you do not know. Verifying a module is very simple and you can use the same resources that PrestaShop makes available to us developers. Then register and use: https://validator.prestashop.com check especially the Errors and Security entry. However, I recommend that you always install the module in a non-production copy of your ecommerce with the 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 via AMPPS or similar. I also recommend deactivating and uninstalling all unused modules.
Trust a little above all in PHP scripts or modules that mask part of the code making it unreadable (eg base64_encode).
THIRD RULE: essential are: Google Search Console *, Google Analitycs * (or other statistics service) and above all the real-time access to the log files of your domain. Your ecommerce is your business, don't skimp on hosting, if you don't have real-time access to log files you won't have any way of finding the source of any attacks, or finding any problems. Many hosting services, even famous ones, offer the possibility to consult a copy of the previous day's logs, better than nothing, but not enough. When choosing the service, always check that an Anti-DDoS system is also present, one of the minimum security needs.
- Google Search Console should be consulted often do not wait for alerts to arrive.
- Google Analytics you should check it daily even when you have no active campaigns.
- Server log files should be checked once a week or at least once a month.
*) We recommend our Art Webmaster Tools Site Verification and Hreflang module to activate and include these services.
What to check: 500, 502, and 503 errors can also be caused by a sudden surge in junk traffic. This is where the server log files become important, as they record the IP of 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. Sifting through the log files you will also find requests such as: /phpmyadmin/scripts/setup.php, /wp-login.php these requests are all made by bots trying to exploit known exploits in systems (the most popular is WordPress ). NOTES: always remember to regenerate the robots.txt file as soon as we notice anomalous traffic or receive spam. To do this we go to: settings> SEO & URLs in the backend of our ecommerce in PS.
NOTES : always remember to regenerate the robots.txt file as soon as we notice anomalous traffic or receive spam. To do this we 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 begin to receive a bombardment of junk emails, as the country in the requests always appears france.
Precisely in these cases we find that spending a few tens of euros more can save us a lot of time, if your hosting provider provides you with access to log files in real time, identify the source immediately. Better still if your service gives you access to an advanced panel like Plesk.
From the log files, looking for / fr / contact us (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 continue contact requests. We can also check where the attack really comes 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 other control panel of your service you can download the log file locally and use the glogg utility to search within the same file. I admit I learned just by struggling with insufficient resources and in periods where every single MB cost as much as a month's salary, but if your aim is to do business online with your ecommerce I will never get tired of saying it: do not skimp, because you you will regret.
All that remains is to block the two IPs to do so we have various options to use one of the many modules available for PrestaShop such as " Block Bots / Users based on IP, Country or User-Agent " or to modify the .htaccess file this more complex operation, let's see an example :
WE INSERT AFTER THE LINE:
# ~~ end ~~ Do not remove this comment, Prestashop will automatically keep 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 that we want to exclude, in this way you will receive the 403 error page: access denied. We can also decide to redirect traffic elsewhere. In the case In the example (which is a real case anyway) the SPAM came from South Africa. Alternatively we can also choose, if we do not market in that state and have no plans to do so in the future, to block all traffic from that country.
To exclude a country we must use the international acronym that identifies the same in the case of South Africa is ZA therefore:
SetEnvIf GEOIP_COUNTRY_CODE ZA bad_user
Deny from env = bad_user
ErrorDocument 403 /error403.html
Note : the ban for coutry requires mod_geoip to be active on your hosting.
To keep everything safe: once the IPs responsible for SPAM are banned, you will automatically no longer receive any. But it is always better to be safe than sorry as if the bot changed IP automatically the problem would reoccur, so it is advisable to directly enter a reCAPTCHA in the PrestaShop contact form. Also for this there is an excellent Add Google reCAPTCHA to store forms module developed by InnovaDeluxe. It is important to update to the PrestaShop version, on some older versions even adding a reCAPTCHA filter will not solve the problem.
If you ask yourself why not limit yourself to simply inserting the r eCAPCHA , the reason is very simple. These Bots do not check the outcome of the sending, so the automatic program would continue to try to send the SPAM consuming resources because at each sending our SERVER will process the request. By banning IP we will therefore consume fewer resources, leaving them available for that quality traffic that brings us conversions.
NOTES : much more serious and annoying is when the " SEND TO A FRIEND " module is targeted, which I recommend to uninstall completely, it is not enough to deactivate it. A bot that uses this module can lead you to the temporary suspension of the email account you have configured in prestashop up to a ban on the IP of your server. So if you receive many failed delivery in your mailbox that you use for your e-commerce, correct them immediately.
CONCLUSIONS
If despite the use of reCAPCHA you still receive spam emails and especially if the attack received was very intense with hundreds of emails a day, it may mean that upstream of your server there is no Anti-DDoS filter so you have a serious security issue. It is not necessary to have a hw firewall even if recommended, but a basic Anti-DDoS system is a must. If you are not on a dedicated server, but on a 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
For Ind Loris Modena , owner of Arte e Informatica , he began working in the IT sector in 1989 as a system engineer in charge of the maintenance and installation of IT systems. He started programming for the web in 1997 dealing with CGI programming in PERL and then moving on to programming in PHP and JavaScript. In this period he approaches the Open source world and the management of Linux servers.
Related products