Magento / Security

Protect Magento search security from malicious scanning

by , , revisited on

We have by far the largest RPM repository with NGINX module packages and VMODs for Varnish. If you want to install NGINX, Varnish, and lots of useful performance/security software with smooth yum upgrades for production use, this is the repository for you.
Active subscription is required.

One of the clients got worried about unusual spike in search activity on their Magento store. And the weird search requests themselves.

There were dozens more requests besides the ones found in Magento backend. The access logs have been filled with many requests coming from the same IP, seemingly trying to “search” for something.

Of course, there was no actual search taking place. A malicious script was clearly trying to break-in and find vulnerabilities using the search function of Magento: - - [20/Jul/2016:07:15:08 +0100] "GET /catalogsearch/result/index?index=%21(()%26%26%21%7c*%7c*%7c&ornamental_qualities=63&q=1 HTTP/1.1" - - [20/Jul/2016:07:15:08 +0100] "GET /catalogsearch/result/index?index=http://some-inexistent-website.acu/some_inexistent_file_with_long_name%3F.jpg&ornamental_qualities=64&q=1 HTTP/1.1 - - [20/Jul/2016:07:15:08 +0100] "GET /catalogsearch/result/index?index=%24%7b9999707%2b10000380%7d&ornamental_qualities=65&q=1 HTTP/1.1" - - [20/Jul/2016:07:15:08 +0100] "GET /catalogsearch/result/index?index=../../../../../../../../../../etc/passwd%00.jpg&ornamental_qualities=63&q=1 HTTP/1.1"
... and many more

Magento Search is used for hacking

All those many requests will provide unnecessary load for your PHP backend and are security threat.

Magento Unusual Search
Magento Unusual Search

Common security sense

Is your Magento patched properly and all the extensions are up to date? That doesn’t make it 100% secure as there may be still security bugs, not confirmed officially.

Even provided you have secure website code does not guarantee protection. If your server is not setup securely, it will fall a victim to attacks.

The most innocent thing a hacker might do after gaining access to server includes:

  • send out thousands of spam emails through your server, effectively putting it into mail block lists
  • change the store’s homepage by replacing index.php

Not the least common thing taking place with hacked servers is complete destruction of data “for entertainment” (do you have your backups enabled?).

So how do we deal with the issue of hacker scans? Of course, if you don’t have patched Magento you must update it properly. The same applies to extensions.

If you have not secured your server and did not put much attention to security, you must secure it.

And here is one additional way to secure Magento store. What we are going to do in this post is make life to those hackers less fun. We are going to limit their requests.

Secure Magento search. Limit rate

The following instructions are good for Magento 1.x running under Nginx. Our goal is to detect unusual access rate for search function of Magento, and block those requests.

We will make use of ngx_http_limit_req_module Nginx module, which is bundled with standard Nginx.

Define request storage

First, let’s define the storage for all those IPs which access the search function. Open up nginx.conf, and within http section, add:

limit_req_zone $binary_remote_addr zone=search:10m rate=6r/m;

This tells Nginx to store remote user addresses in RAM. This storage is 10 MB in size which is enough to save thousands of visitors addresses. We also define the rate of requests of 6 per minute. That means that the storage will collect only those IPs which access search function with an unusual rate of once within every 10 seconds.

Define location for limiting requests

Next, in the server block of your website configuration in Nginx, add the following:

    location /catalogsearch/ {
        limit_req zone=search burst=1 nodelay;
        try_files $uri $uri/ /index.php?$args;

What we do here is telling Nginx to limit requests to /catalogsearch/ location, allowing 1 request to be satisfied without a delay, even when it hits the limit rate defined earlier.

Why do we need to satisfy 1 “bad” request? This is to accommodate for situations when a user maybe abruptly changing their mind about initial search.

So, if someone (or something) makes 2 subsequent requests to search function, the 3rd search request which exceeds rate of 6 requests per minute will be denied with “503 Service Temporarily Unavailable” error message.

That’s really all it takes to tighten up Magento search security!

We have lessened the chance for attackers to find vulnerabilities. We’ve also lessened the strain to your Magento server. All without affecting genuine search requests.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.