Adobe Experience Manager Sites & More

srinivas_chann1 · 6/22/22

Hi,

Could some provide suggestions as what we could to do to Protect aem website from hackers using query parameters.

We have https://abc.com and the anonymous user can keep running batch jobs that could be sending new query parameters request every second to the website like https://abc.com?q=testing next call https://abc.com?q=test1, like this.

Due to this the call will hit the AEM publishers and the load on AEM servers will increase.

Please suggest what improvements we could do at dispatcher level to block such requests and at AEM level so that such requests are not entertained, load is kept to minimal.

Regards,

Srinivas

tusharbias · 6/22/22

@SantoshSai

This is pure case of DOS attack.

I agree IgnoreURLParams is for defining what needs to be cached in terms of query params. This will atleast save our Publish servers from attack and request just land on Dispatcher and request use the cached data. This will help our infrastrature. IMO, Instead of re-direction this should be used.

All network servers can be subject to denial of service attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can do certain things to mitigate the problems that they create.

Often the most effective anti-DoS tool will be a firewall or other operating-system configurations. For example, most firewalls can be configured to restrict the number of simultaneous connections from any individual IP address or network, thus preventing a range of simple attacks. Of course this is no help against Distributed Denial of Service attacks (DDoS).

You can also built your custom monitoring to monitor the load and in case of any suspicious activity IP can blocked or proper action can be taken.

** Make sure to handle this for selectors as well. i.e. whitelist selectors which is used rest block.

View solution in original post

SantoshSai · 6/22/22

Hi @srinivas_chann1 ,

You can check /filter section

eg.

/filter {
/0001 { /type “deny" /method "GET" /url "/path/*" /query "*" }
/0002 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }
}

In your case, it will be

/0003 { /type "deny" /method "GET" /url "/content/abc.html" /query "q=*" }

Reference: https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-c...

OR

In your httpd ".conf" file, inside your VirtualHost tag - Write these rules.

RewriteEngine On
RewriteCond %{QUERY_STRING} ^q=testing (use regex)
RewriteRule .* /? [R,L]

What it will do - For Eg.,

If your request url is - http://www.ab .com/index.html?q=testing

then it will redirect the url to http://www.abc.com

In both the above cases you can reduce load on publisher.

Hope that helps!

Regards,

Santosh

tusharbias · 6/22/22

You need to use - IgnoreURLParams in Dispatcher

Ignoring URL Parameters

The ignoreURLParams section defines which URL parameters are ignored when determining whether a page is cached or delivered from cache:

When a request URL contains parameters that are all ignored, the page is cached.
When a request URL contains one or more parameters that are not ignored, the page is not cached.

When a parameter is ignored for a page, the page is cached the first time that the page is requested. Subsequent requests for the page are served the cached page, regardless of the value of the parameter in the request.

It should look like this -

/ignoreUrlParams
{
/0001 { /glob "*" /type "deny" }
/0002 { /glob "q" /type "allow" }
}

Refer here for more info - https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-c...

SantoshSai · 6/22/22

@tusharbias
I believe /ignoreUrlParams is for caching purpose, If you state { /glob "q" /type "deny" } - in this case dispatcher will still hit to publisher but stop it from caching, which won't help you to block or filter out the url and which remains same load on publisher - correct if I'm wrong.

tusharbias · 6/22/22

@SantoshSai

This is pure case of DOS attack.

I agree IgnoreURLParams is for defining what needs to be cached in terms of query params. This will atleast save our Publish servers from attack and request just land on Dispatcher and request use the cached data. This will help our infrastrature. IMO, Instead of re-direction this should be used.

All network servers can be subject to denial of service attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can do certain things to mitigate the problems that they create.

Often the most effective anti-DoS tool will be a firewall or other operating-system configurations. For example, most firewalls can be configured to restrict the number of simultaneous connections from any individual IP address or network, thus preventing a range of simple attacks. Of course this is no help against Distributed Denial of Service attacks (DDoS).

You can also built your custom monitoring to monitor the load and in case of any suspicious activity IP can blocked or proper action can be taken.

** Make sure to handle this for selectors as well. i.e. whitelist selectors which is used rest block.

SantoshSai · 6/23/22

@tusharbias IMHO, this is completely different topic, Looking into your information - "This will atleast save our Publish servers from attack and request just land on Dispatcher and request use the cached data".

However, If you look at /ignoreUrlParam - It will still hit to publisher for the first time - how will it retain from attacking?

Although, let me give you details about re-direction

A denial of service (DoS) attack is an attempt to make a computer resource unavailable to its intended users.

At the dispatcher level, there are two methods of configuring to prevent DoS attacks:

Use the mod_rewrite module to perform URL validations.
Prevent the dispatcher from caching URLs with spurious extensions by using filters.

Clearly mentioned in Adobe documentation: https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/getting-started/security...

Note: Original query is to completely reduce load on publisher server not to cache.

based on that I would still stand by my stance, as /filter section always helps us to block the URL completely, that's why we have such /filter rules

# Deny everything first and then allow specific entries
/0001 { /type "deny" /glob "*" }

# Open consoles
    /0011 { /type "allow" /url "/admin/*"  }  # allow servlet engine admin
    /0012 { /type "allow" /url "/crx/*"    }  # allow content repository
    /0013 { /type "allow" /url "/system/*" }  # allow OSGi console

@kautuk_sahni

tusharbias · 6/23/22

Dont want to debate on this but you yourself given the answer,

"However, If you look at /ignoreUrlParam - It will still hit to publisher for the first time - how will it retain from attacking? "

True, this is the case for all pages. Once your pages gets cached then with different params also it will return the page from cache itself. So no point of having DOS on publisher.

There are always multiple ways to solve one problem now the question is which is efficient redirection vs returning cache page.

SantoshSai · 6/23/22

@tusharbias - IMHO, It's not about debate, It's all about providing accuracy of information, take it easy
To cache them, request will still hit to publisher - It would get attacked in first request though. After caching then it will serve content from dispatcher(but still you will be attacked by 1st request). Also, as I mentioned above look at Adobe's best practices when you bring term of DoS -

https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/getting-started/security...

Himanshu_Jain · 6/22/22

/filter {  
>/0001 { /type "deny" /method “*" /url "/path/*" }  
>/0002 { /type "allow" /method "GET" /url "/path/*" }  
>/0003 { /type “deny" /method "GET" /url "/path/*" /query "*" }  
>/0004 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }  
}

Refer https://github.com/AdobeDocs/experience-manager-dispatcher.en/blob/main/help/using/dispatcher-config...

Himanshu Jain