nginx headers

[siga75]

would it be possible to edit

report-uri /opnsense-report-csp-violation

so that we don't reveal that we are using opnsense?
also the

server: nginx

is a bit disturbing, but I am not a web developer and maybe it's needed, I don't know, I am also aware that a nessus / openvas scan will probably detect nginx in any case, still I would avoid to send informations if not mandatory

content-encoding: gzip
content-length: 18770
content-security-policy: default-src 'self'; script-src 'self'; img-src 'self'; style-src 'self' https://fonts.googleapis.com; media-src 'self'; font-src 'self' https://fonts.googleapis.com; form-action 'self';  report-uri /opnsense-report-csp-violation
content-type: text/html; charset=UTF-8
date: Sat, 05 Oct 2019 09:14:12 GMT
link: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
referrer-policy: same-origin
server: nginx
status: 200
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: sameorigin
x-permitted-cross-domain-policies: none
x-xss-protection: 1; mode=block

[fabian]

would it be possible to edit

report-uri /opnsense-report-csp-violation

so that we don't reveal that we are using opnsense?

In theory yes, but needs some changes under the hood to work. On the other hand I do not see any advantage because it is still easy to find out by fingerprinting. For example, the OPNsense nginx supports Brotli (br in the Accept-Encoding header) compression, has branded error pages for WAF etc. so you can always find it out.

also the

server: nginx

is a bit disturbing, but I am not a web developer and maybe it's needed, I don't know, I am also aware that a nessus / openvas scan will probably detect nginx in any case, still I would avoid to send informations if not mandatory

You can find some background information here: https://tools.ietf.org/html/rfc2616#section-14.38
In general I cannot remove the header totally without changing the source code of nginx but I have already configured it in a way to keep it as minimal as possible. It is also common to have it like this. If it would be missing, you could still find out which server it is by the order of the headers (and the implemented features).
Almost all web servers are having the same options (only write the name into the header), write header and version and there is also write some debug information in it (for example contain the enabled modules in apache httpd).

[bartjsmit]

Your OPNsense web interface should be restricted to admins  on the LAN only. If you have internal users you don't trust then set up a management VLAN and only allow TCP 443 from that.

Bart...

[siga75]

would it be possible to edit

report-uri /opnsense-report-csp-violation

so that we don't reveal that we are using opnsense?

In theory yes, but needs some changes under the hood to work. On the other hand I do not see any advantage because it is still easy to find out by fingerprinting. For example, the OPNsense nginx supports Brotli (br in the Accept-Encoding header) compression, has branded error pages for WAF etc. so you can always find it out.

also the

server: nginx

is a bit disturbing, but I am not a web developer and maybe it's needed, I don't know, I am also aware that a nessus / openvas scan will probably detect nginx in any case, still I would avoid to send informations if not mandatory

You can find some background information here: https://tools.ietf.org/html/rfc2616#section-14.38
In general I cannot remove the header totally without changing the source code of nginx but I have already configured it in a way to keep it as minimal as possible. It is also common to have it like this. If it would be missing, you could still find out which server it is by the order of the headers (and the implemented features).
Almost all web servers are having the same options (only write the name into the header), write header and version and there is also write some debug information in it (for example contain the enabled modules in apache httpd).

Thx for the answer, I modified the nginx error pages, but sure, it will be still easy to identify it, but I guess it will identified as nginx, and no one will know I have OPNsense (probably), they will maybe know it's nginx on freeBSD

[siga75]

Your OPNsense web interface should be restricted to admins  on the LAN only.

It is like this, still I don't like they know I run OPNsense

[bartjsmit]

Sorry to belabour the point but if you have a separate VLAN for your admins, won't they find out as soon as they log in?  ;D

[siga75]

LOL, every comment is appreciated :)

I am the only admin, and the only other person with physical access is my wife.

What I don't like is that a scan from the external perimeter, with only 80 and 443 exposed, will find out I have OPNsense

[bartjsmit]

Right, that is crystal clear :)

Your WAN side should not allow 80/443 at all. Double check with Shields UP! https://www.grc.com/shieldsup

Bart...

[siga75]

well, I have a site I would like people to access it XD

That's why I secured it in several ways, nginx reverse proxy / WAF (pointing to a separate subnet) apache embedded modsecurity, and stuff :)

[bartjsmit]

In that case, head on over to Github and file a bug report on the header disclosure for reverse proxy: https://github.com/opnsense/core/issues

Bart...

[siga75]

well, it's not a bug, and for what's my understanding Fabian is the main developer of this plugin, so he is aware already

[siga75]

again on this topic, it would be cool if we could add a list of trusted inline scripts, like

'sha256-6Grm8tY1bUzam5fsx+0YqSDt3FPJTxqAT0btehBKKBk='

I can't ask google to remove the inline scripting... for god sake they are promoting use of CSP and they use inline scripting....

Using 'unsafe-inline' is not a good idea if target of CSP is preventing XSS

Of course I could add them to apache, which is the web server behind, but it would mean to mix the CSP stuff on several points

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' https://*.google.com https://*.gstatic.com https://*.googleapis.com https://*.w.org https://*.youtube.com https://s.ytimg.com". Either the 'unsafe-inline' keyword, a hash ('sha256-6Grm8tY1bUzam5fsx+0YqSDt3FPJTxqAT0btehBKKBk='), or a nonce ('nonce-...') is required to enable inline execution.

[fabian]

I need a ticket for supporting nonces and hashes on github, otherwise the feature request will be forgotten.PS: please do not add stuff that is not related to the main quesion in the thread into that one - open another thread for that.