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
Quote from: siga75 on October 05, 2019, 11:29:57 AM
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.
Quote from: siga75 on October 05, 2019, 11:29:57 AM
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 (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).
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...
Quote from: fabian on October 05, 2019, 05:34:04 PM
Quote from: siga75 on October 05, 2019, 11:29:57 AM
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.
Quote from: siga75 on October 05, 2019, 11:29:57 AM
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 (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
Quote from: bartjsmit on October 05, 2019, 09:46:58 PM
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
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
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
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...
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 :)
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...
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
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.
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.