Blocking Request Methods - Apache

[Githopp192]

all about hardening Nextcloud.

Does anyone has got experience in configuration the control request methods, related to apache configuration ?

for that moment i did setup this config:

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK).

Question: Does Nextcloud working within this settings also or does important functionalities not working anymore after this setup ?

RewriteCond %{REQUEST_METHOD} ^(CONNECT|DEBUG|DELETE|MOVE|PUT|TRACE|TRACK)

Control Request Methods | .htaccess made easy (htaccessbook.com)

Control Request Methods

Category: Blog • Posted by Jeff Starr • Updated: Monday, May 9th, 2016 @ 1:05 pm

Sites hosted on Apache servers can accept a wide range of request methods. For example, most developers are familiar with GET and POST requests. Other request methods are less common, such as DELETE, HEAD, and PUT. While many types of request methods are harmless or even beneficial, some of them are just unnecessary and serve to increase the overall security liability of your site. This post explains how to lock things down by blocking or allowing only specific types of HTTP requests.

Blocking Request Methods

This technique blocks some request methods that most sites never use. Why block them? Because they may be used by teh bad guys to scan and covertly attack your site. Think of these request types as hidden doors to your house that none of your friends use or even know about. But that pathetic loser down the street knows all about the hidden doors, and uses them for his evil schemes. You don’t it want it, bro.

To lock the doors, you can add the following .htaccess snippet to your site’s root .htaccess file:

# BLOCK UNNECESSARY REQUEST METHODS
RewriteCond %{REQUEST_METHOD} ^(CONNECT|DEBUG|DELETE|MOVE|PUT|TRACE|TRACK) [NC]
RewriteRule .* - [F,L]

This snippet blocks all of the following requests methods:

• CONNECT
• DEBUG
• DELETE
• MOVE
• PUT
• TRACE
• TRACK

Important: before implementing this technique, make sure that your site does not rely on any of these blocked request methods. Most don’t, but you want to be sure. Ask your host or local expert if in doubt.

[christianlupus]

Uff, that is hard to answer (read impossible).

A general comment: The DELETE and PUT methods are quite common in APIs. So, these should not be blocked or nasty things might happen.

With CONNET and MOVE, I am not sure if they are needed by the WebDAV interface. You would have to verify it before rejecting them.

The hard point: All installed apps can register routes (including a corresponding verb like GET, POST or whatever) according to their need. Thus, it is not trivial to say this verb is not used as some fancy app might come along that needs that specific verb for whatever. (That is why I wrote it is impossible to tell. Every instance might have a different subset of apps installed.)

All in all the core uses a deny everything and accept valid policy: unless there is a specific route with that path and verb, the server redirects the browser to a safe site with GET verb. So, the risk is rather small.

Christian

[Githopp192]

Thanks Christian for this great answer.

Yes, you’re quite right - as i’ve got several test vm’s (in vbox) - i could test it here.

For that moment i configured “RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)” and it works as expected.

btw - i’m using OpnSense with 100’000 active rules, all on DROP (which does not disturb Nextcloud), Host IPS (fail2ban), DNS Blacklist Dropper, of course Nextcloud builtin AV and Ransomware protection and a fine tuned backup mechanism (different snapshot techniques, Enterprise Backup Suite & much more).

[rawtaz]

I too think this is not something you should tighten down overly much. As @christianlupus said even if Nextcloud itself doesn’t use a given method, apps might. For example some apps I have use PUT and PATCH, besides the usual GET and POST. I think the added security by removing methods like this is quite small, hardly relevant at all.

[Githopp192]

thx @rawtaz

[pete.dawgg]

@Githopp192

Think of these request types as hidden doors to your house that none of your friends use or even know about. But that pathetic loser down the street knows all about the hidden doors, and uses them for his evil schemes. You don’t it want it, bro.

This sounds rather questionable to me - after all, HTTP is a very well-established standard. You can easily make your webapps and clients fail in the most obscure and untraceable ways by arbitrarily disabling some parts of a protocol.
If your security requirements are really so high it might work better to put more dedicated securtity boxes in front of you server in different zones, or, if this is not possible, use fail2ban with a cutomized configuration and LONG blocking times.
GOOD LUCK!

[rawtaz]

@pete.dawgg

If your security requirements are really so high it might work better to put more dedicated securtity boxes in front of you server in different zones

E.g. a web application firewall

[bb77]

@rawtaz

E.g. a web application firewall

Which of course doesn’t auto-magically make everything secure If it is configured too restrictively, it can cause the same issues as disabling parts of the protocol, and if it is configured too lax, it might as well be left out entirely. It usually also can’t protect you from critical security vulnerabilities in the application itself, or only to a limited extent. In the worst case it can even introduce its own security vulnerabilities.

But @pete.dawgg is of course right. If you want to monitor the traffic and the requests to your applications in order to take the appropriate actions, it makes more sense using a dedicated security appliance, instead of just blindly disabling certain functions on the server.

[rawtaz]

@bb77

Which of course doesn’t auto-magically make everything secure

Noone suggested this was the case, so I’m not sure why you point this out. It’s obvious. But it’s probably way better than restricting a few HTTP verbs and running fail2ban which doesn’t have a clue what’s even being requested on the application layer What you said about it is pretty much the same with any software out there, it can help, be of disservice if misconfigured, and can have vulnerabilities of its own (antivirus software is a prime example of this).

[bb77]

@rawtaz

so I’m not sure why you point this out

Because I wanted to. For you my statement may be obvious, but especially for home users or small business users, who usually don’t have a dedicated team of experts, a (incorrectly configured) security appliance can also create a false sense of security.

@rawtaz

fail2ban which doesn’t have a clue what’s even being requested on the application layer

That’s not entirely true. Yes, Fail2ban usually triggers actions on layer 3 by controlling a packet filter / firewall, but it responds to events that occur on layer 7.

But yes of course, used correctly, a WAF can certainly be a big help and offers way more insight and granular control than Fail2ban.

[rawtaz]

@bb77

Fail2ban usually triggers actions on layer 3 by controlling a packet filter / firewall, but it responds to events that occur on layer 7

How can it do that?

[bb77]

It reads log files and then triggers the package filter of your OS, to block the respective IP address for a certain amount of time. The first part happens on layer 7, the second part happens on layer 3. Or in other words: Fail2ban itself is operating on layer 7, the package filter, that does the actual blocking, is operating on layer 3.

[rawtaz]

Exactly. And this is why fail2ban has no idea what’s going on on level 7, so you’re back at square one, you need something that understands the higher levels to be able to either take action itself, or if you want to use fail2ban report on what goes on and what might be an attack. Just logging requests won’t help fail2ban, you need to somehow tell it when there is something wrong. So basically you still need something like a WAF or other type of application-aware protection.