Translating apache config to nginx

Server NGINX
1

Roundcube uses some apache config to deny access to certain locations
and I’m trying to translate them to nginx. The following seems to
work fine:

location ~
^/?(.git|.tx|SQL|bin|config|logs|temp|tests|program/(include|lib|localization|steps))
{
deny all;
}

location ~
/?(README.md|composer.json-dist|composer.json|package.xml)$ {
deny all;
}

But this causes a 403 during normal operation:

location ~ ^(?!installer)(.?[^.]+)$ {
deny all;
}

Why is that happening?

  • Grant
2

On Wed, Feb 19, 2014 at 05:35:46AM -0800, Grant wrote:

Hi there,

The following seems to work fine:

location ~
^/?(.git|.tx|SQL|bin|config|logs|temp|tests|program/(include|lib|localization|steps))
{
deny all;
}

That’s probably work until you add “location ^~ /oops{}” and request
/oops/a.git

Not a problem; just a thing to be aware of when you use top-level regex
locations.

But this causes a 403 during normal operation:

location ~ ^(?!installer)(.?[^.]+)$ {
deny all;
}

Why is that happening?

What requests do you want to match that location?

What requests actually match that location?

Alternatively: what request do you make? What response do you expect?
And
what is the regex above intended to do?

Cheers,

f

Francis D. [email protected]

3

What requests actually match that location?

Alternatively: what request do you make? What response do you expect? And
what is the regex above intended to do?

I actually got these apache deny directives from the roundcube list.
I don’t have a more specific idea of what this one is supposed to do
beyond “securing things”. I’m not very good with regex and I was
hoping someone here would see the problem. Does it make sense that
this would work in apache but not in nginx?

  • Grant
4

intention is.

Then someone may be able to translate those words into an nginx config
fragment.

Here is the description:

“deny access to files not containing a dot or starting with a dot in
all locations except installer directory”

Should the following accomplish this in nginx? It gives me 403 during
normal operation.

location ~ ^(?!installer)(.?[^.]+)$ {
deny all;
}

  • Grant
5

On Fri, Feb 21, 2014 at 07:36:20AM -0800, Grant wrote:

Hi there,

Here is the description:

“deny access to files not containing a dot or starting with a dot in
all locations except installer directory”

So: you want it to block /one and /two/, to allow /thr.ee, and to block
/.four, yes?

Should the following accomplish this in nginx? It gives me 403 during
normal operation.

That configuration seems to get the first three correct and the last
one wrong.

If you add a “/” immediately after the first ^, it seems to get all
four correct.

What is “normal operation”? If the request you make is like /thr.ee,
it should be allowed; if it is not like /thr.ee is should be blocked.

(Personally, I’m not sure why you would want that set of restrictions.
But
if you want it, this is one way to get it.)

location ~ ^(?!installer)(.?[^.]+)$ {
deny all;
}

A more nginx-ish way would probably be to only have prefix locations at
the top level; but if what you have works for you, it’s good.

f

Francis D. [email protected]

6

On Thu, Feb 20, 2014 at 05:58:05AM -0800, Grant wrote:

Hi there,

location ~ ^(?!installer)(.?[^.]+)$ {
deny all;
}

Alternatively: what request do you make? What response do you expect? And
what is the regex above intended to do?

I actually got these apache deny directives from the roundcube list.

Possibly the roundcube list will be able to explain, in words, what the
intention is.

Then someone may be able to translate those words into an nginx config
fragment.

I don’t have a more specific idea of what this one is supposed to do
beyond “securing things”. I’m not very good with regex and I was
hoping someone here would see the problem.

The problem is that the regex matches requests that you don’t want it
to match – that much is straightforward.

Since this is intended to be a security thing, it’s probably better not
to try to guess what the author might have meant.

(It currently is secure, sort of – you can’t get at the urls they
intended to block.)

Does it make sense that
this would work in apache but not in nginx?

Yes; the two programs have different expectations of their
configuration.

In nginx, for example, all user requests will start with “/”, so any
regex
that requires anything other than “/” as the first character will fail.

In apache, some regexes don’t have that requirement.

(Or maybe that’s incorrect – check with an apache person if it
matters.)

f

Francis D. [email protected]

7

On 21 February 2014 21:51, Grant [email protected] wrote:

What is “normal operation”? If the request you make is like /thr.ee,
it should be allowed; if it is not like /thr.ee is should be blocked.

I just meant normal browsing around the inbox in Roundcube.

If you assume that people on this list magically know what Roundcube
URIs look like, you’re going to be massively reducing the audience
that might otherwise be able to help you! :wink:

J

8

What is “normal operation”? If the request you make is like /thr.ee,
it should be allowed; if it is not like /thr.ee is should be blocked.

I just meant normal browsing around the inbox in Roundcube.

If you assume that people on this list magically know what Roundcube
URIs look like, you’re going to be massively reducing the audience
that might otherwise be able to help you! :wink:

You’re right, but the regex was originally written for Roundcube, so
my point was that it was supposed to work but didn’t and something was
probably lost in translation between apache and nginx. It just needed
an extra slash.

  • Grant
9

Here is the description:

“deny access to files not containing a dot or starting with a dot in
all locations except installer directory”

So: you want it to block /one and /two/, to allow /thr.ee, and to block /.four,
yes?

That’s how I read it too.

it should be allowed; if it is not like /thr.ee is should be blocked.
I just meant normal browsing around the inbox in Roundcube.

(Personally, I’m not sure why you would want that set of restrictions. But
if you want it, this is one way to get it.)

location ~ ^(?!installer)(.?[^.]+)$ {
deny all;
}

I think the corrected directive is as follows?

location ~ ^/(?!installer)(.?[^.]+)$ {
deny all;
}

  • Grant