It now comes increasingly common, that Magento stores are shipped for sending SPAM. For this purpose, either “Fake”-Customer accounts are created and / or produced newsletter subscribers.
Many wonder-as they fret- “Why do they do that?” or “What's the point?”. A clear answer can I give out but not an approach:
While efforts are being automatically created by bots customer accounts, but the email addresses used are not wrong. In recent cases, there were mostly e-mail accounts from @ mail.ru, @ gmail.ru, @inbox.ru, @ Bk.ru, @ List.ru and other Russian mail hosting. Generally, there probably most of the mail addresses and thus available after login in the respective shop a confirmation email from that = it therefore be true emails from a real shop (-sender) sent to real people. That would be so intent 1. Now the question “Why? It's just a normal sign-up confirmation email…”. Ja, BUT it is the bots use for their “advertising message” the customer name. Therefore, a long text is also there so. As an example,:
According to Google Translate this is probably quite rough
We see some “His” in the message. But we imagine, that this name in your “Hallo [Name] and welcome to the X-Shop!”-E-mail is used to confirm the registration in the online shop. Actually makes no sense… Compared to the SPAM, we get every day probably a smooth 6.
What deeper sense this makes or how efficient it is, I can not say it, But the fact is, that the registration function of the Magento stores is used for that benefit many. In our current case, like almost 300 Time in 12 Hours.
What can you do about it? Unfortunately, there is no clear answer that question, because the problem goes deep. I want to introduce the following approaches:
1. Magento Captcha: Magento has version 1.7 a ready built-in Captcha feature. This only needs to be activated, order for customer registration, den Login, the “Forgot Password”-to be used function and Checkout (possible adjustments necessary for their own template). To this end, under System > Configuration > Customer / Customer configuration / go CAPTCHA.
There you can then activate the Captcha for different areas in the frontend.
For the Newsletter subscription or the contact form, this is not the standard.
2. Google reCaptcha: Probably the currently most frequently encountered on the Internet (re)Captcha. For use in Magento has on one side with a Google account reCaptcha account to Own / the domain to be created, then using the thus obtained Keys in the shop. To display the spelling is there different ways. From your own implementation through various extensions (free and fee). I personally would look for in the extension thereon, that no unnecessary “Bloatware” mitinstalliert, since it exclusively to the integration of a “Widgets” These, should not be necessary large database changes by the extension and additional functions superfluous. Amasty teaches his free tool e.g.. both the one with the other also – Therefore, I have refrained. However, is also in the free extension of Turiknox not done much more than needs to be.
3. IP-Sperre: If one evaluates the server logs from, one recognizes very clearly relatively regular source IPs. In our case, mostly from Russia. It can help to block these IPs or IP ranges. This we have done over the .htaccess in which we
<Files index.php> Order Deny,Allow Deny from XXX.XXX.XXX.XXX Deny from XXX.XXX. </Files>
have entered. You can write out the complete IP or only areas, by only writing part (usually the front). The less you write, the more blocked. of course, but the risk of unwanted blockage also increases.
4. Since many entries for the new customers NOT “reulär” created through the front-end script, but past it, brings the Captcha (1 and also 2) in some bots nothing. They continue to easily create customer accounts. If one evaluates the logs from, can be found here repeatedly calls / customer / account / create post. What is generally correct yes. However, the difference lies in the history or. of context.
I make a normal user an account, sees this in the log like this:
Meine.IP.Adresse.hier - - [05/Jun/2018:12:02:28 +0200] "GET /index.php/customer/account/create/ HTTP/2.0" 200 10055 "https://www.hiermeineshopurl.de/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0" Meine.IP.Adresse.hier - - [05/Jun/2018:12:02:53 +0200] "GET /index.php/customer/account/createpost/ HTTP/2.0" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0"
Created a bot a User Account, however, it looks like this:
Die.Bot.IP.Hier - - [05/Jun/2018:12:11:20 +0200] "GET /index.php/customer/account/create HTTP/1.1" 200 10054 "https://www.hiermeineshopurl.de/index.php/customer/account/login/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0" Die.Bot.IP.Hier - - [05/Jun/2018:12:11:21 +0200] "POST /index.php/customer/account/createpost/ HTTP/1.1" 302 - "https://www.hiermeineshopurl.de/index.php/customer/account/create/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0" Die.Bot.IP.Hier - - [05/Jun/2018:12:11:22 +0200] "GET /index.php/customer/account/index/ HTTP/1.1" 200 9542 "https://www.hiermeineshopurl.de/index.php/customer/account/create/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0"
Abnormalities en masse. We had a test basis disabled in this store, the double opt-in function in the application and it fell on, that was logged immediately, to deposit a customer address.
5. HoneyPot: In such are e.g.. Things integrated on the side, does not see the human, and would therefore not be aware. a bot “looks” However, they and responds accordingly. This may be another field or a checkbox. I have used the free extension Magento-Hackathon HoneySpam. This adds a URL field for registration. This is not considerate for normal users- and therefore not fillable. Will it be so filled, it was a bot and registration is refused.
6. Country-Block: There is the possibility of entire countries(IDs) to lock and not be on the side. For this there are various manuals, which can be found on Google and some Extensions. but this should always be the last resort and therefore still my last ace up his sleeve, the
7. Email Blacklist: There are some extensions, that can be configured so, that defined during registration mail addresses or parts of email addresses are rejected. As an example, the extension of Amasty for nothing (but it brings back the “Bloatware” Amasty base with in the same way as under Store 2 described). With this extension you can do a lot with the wild card * work. Thus would be a block of *@ mail.ru uvm. possible.
This possibility entails the risk of unwanted users to block, but is not quite as rigorous as No.. 6.
All in all we have so far the tide of spam registrations restrict only strong but not prevent. If there is something new here, are we writing. but we also look forward to letters or. Comments.
Update vom 07.06.2018
After evaluating the new server logs and other tests, I would like to add more info.
- I test times as created a new user and first name and surname you a little text incorporated, making note of a super-domain. The part “Commercers mit IP XYZ [Anm.: IP I have called, so I can search the server logs after my IP tomorrow) – great website at www.commercers.com” which is comparable with the information, which incorporate the bots. And you can clearly see, that both the mail subject and the mail content makes no real sense. I would not come up with the idea to pay an outstanding bill allegedly, because it is in such a context.
- I further observed the phenomenon of systemic customer registration. The double opt-in for customer registration is enabled. Each customer must first click the link in the mail before he can log in, e.g. by. to store address data (in the registration form is queried NO address!). Surprisingly, however, are all the accounts created by bots with a complete address (all from Australia) deposited. So the bots have the option to deposit the addresses already during the registration, as you can probably assume, that the angespamte Russians will hardly sign, deposit to an Australian address 😉
- This is a current extract from the server log:
Hier.die.BOT.IP - - [06/Jun/2018:20:04:45 +0200] "POST /customer/account/createpost HTTP/1.1" 302 - "https://www.hiermeineshopurl.de/customer/account/create" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36" Hier.die.BOT.IP - - [06/Jun/2018:20:04:49 +0200] "GET /index.php/customer/account/index/ HTTP/1.1" 302 - "https://www.hiermeineshopurl.de/customer/account/create" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36" Hier.die.BOT.IP - - [06/Jun/2018:20:04:51 +0200] "GET /index.php/customer/account/login/ HTTP/1.1" 200 9870 "https://www.hiermeineshopurl.de/customer/account/create" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36"
- A frequent visitor to the site is also the Mail.RU_Bot / 2.0 with the following entry
Hier.die.Bot.IP - - [06/Jun/2018:00:19:53 +0200] "GET /robots.txt HTTP/1.0" 200 67 "-" "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot / 2.0; +http://go.mail.ru/help/robots)"
It is interesting, that it obviously reads the robots.txt in the stands, that he should do from the field to kindly. but itches him not very, because it receives the diligent work in accordance with this reading and the side indicated with e.g.:
Hier.die.Bot.IP - - [06/Jun/2018:01:51:34 +0200] "GET /index.php/contacts/ HTTP/1.1" 200 9208 "-" "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot / 2.0; +http://go.mail.ru/help/robots)"
(URL http://go.mail.ru/help/robots way, not helping a further. But I do not think, the bot itself is a problem, as Mail.ru is a legal mail provider. but must have on the side to him not yet.)
- In summary for today:
- The bots use a possibility at the normal account creation to come by. Thus, it is not holding the reCaptcha on.
- The bots can also just off the registry give to the address. Looking at the register.phtml to, the address fields are stored there,, however “hidden”. Thus, they are not considerate for normal users- and fillable. This would thus be a suitable HoneyPot.
Update vom 12.06.2018
After all did not too much, I tried again the Magento own Captcha. I disabled the Google reCaptcha and activated the default Captcha. Although I previously set it already just (s. screenshot above) had, I tried again. And lo and behold: It worked. Since then, no SPAM registrations more. According server logs will continue trying to access the Store, by the .htaccess and (probably) but the Captcha is no registration of bots by.
Just take a look. If there is something new, I log.
Used incidentally in Magento 1.9
To me the same thing is happening to me some months…it was very slowly…but today is bestial. I take as 1700 new high so far this day. All supposedly Chinese… And I can with them!
Yesterday we had this problem in another store (mail.ru records Australia). No more problems after activating Magento Captcha.
Hallo, Perhaps it would also bring what, the form fields name and first name on e.g.. each 20 limit signs. Longer are names not normally and the place for the supposed promotional message might then be too little. Thus, it would not be interesting enough for the spammers.
Moin! This is a good approach. The question is how the bot with the error message “More than 20 character” deal. Whether he NOT handle it and thus no entry is created or whether this case only 20 Characters are entered. I could imagine, The former is true that.
Thanks for shining light on the reason for this. This has happened to us and I was completely baffled as to what the purpose of this was. That totally makes sense that it’s a way to send out spam emails.