Resolved XFrame Options / X-XSS-Protection / X-Content-Type-Options / HSTS

[learning_curve]

Until very recently, these four items were neatly applied across all active domains on our server, simply by following the very clear instructions posted by @UFHH01 in the second post on this thread

For no reason that we can understand or immediatley fix (!) now they are faiing to be applied

As an interim and whilst we attempt to figure out why, we followed the HSTS 'fix' in this thread but that doesn't work either and would only be a temporary 'fix' for one out of the four anyway....

We've also carefully read through this HSTS associated more recent thread but it's not the same complete issue.

Using conventional nginx -t & apachectl -t tests results in no errors or issues. The same results after running /usr/local/psa/admin/sbin/httpdmng --reconfigure-all and/or plesk repair web -y -v There's no functional errors and all live sites are fine, albeit a little weaker now (securitywise) which is very important!

It appears that the /etc/nginx/conf.d/own_additional_ssl_.conf file hat was previously 100% functional is now simply being ignored. We're guessing that the process 'running order' has changed and that we need to revise how/when this specific file's content is added and made live and 100% functional again...

Has any body else had this happen / know the cure or fix?

 

[mr-wolf]

If "running order" is indeed the issue, you could rename that file to what I already have:

/etc/nginx/conf.d/aa400_own_tweaks.conf

 

[learning_curve]

We're guesing something similar has happened to you? That would have been a) A very nice solution b) raise even more questions as to why this could possibly even happen, but....Sadly, that file being renamed and then a normal pre-check & re-start has made zero difference Hmmmmm

 

[mr-wolf]

We're guesing something similar has happened to you? That would have been a) A very nice solution b) raise even more questions as to why this could possibly even happen, but....Sadly, that file being renamed and then a normal pre-check & re-start has made zero difference Hmmmmm

Sorry for that misunderstanding.
No, it did not happen to me.
I'm using the folder /etc/nginx/conf.d/ for several tricks and all of the files I create there are deliberately given a special name, so I know in which order they are executed.

It seems you have the same problem as @Dukemaster
Although he has a file there it is not adding headers.

Have you checked your site with Analyse your HTTP response headers ??
Does it add any headers??

 

[virtubox]

The most important post is this one : Resolved - How can I adjust HSTS in Plesk?
I use Apache + Nginx and all my headers including HSTS are set in Apache configuration, not in nginx

 

[mr-wolf]

What does this command tell you?

nginx -T | grep "add_header " | grep -v Plesk

 

[Dukemaster]

root@server:~# nginx -T | grep "add_header " | grep -v Plesk
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security 'max-age=15768000;includeSubDomains';
root@server:~# ^C

 

[virtubox]

What does this command tell you?

nginx -T | grep "add_header " | grep -v Plesk

On Plesk 17.5 : noting else than :
add_header "Access-Control-Allow-Origin" "*";

On Plesk 18.2 : (with the new headers area available )

add_header "Referrer-Policy" "strict-origin-when-cross-origin";
add_header "Strict-Transport-Security" "max-age=31536000; includeSubDomains; preload";
add_header "x-xss-protection" "1; mode=block";
add_header "Referrer-Policy" "strict-origin-when-cross-origin";
add_header "Strict-Transport-Security" "max-age=31536000; includeSubDomains; preload";
add_header "x-xss-protection" "1; mode=block";

 

[learning_curve]

Sorry for that misunderstanding. No, it did not happen to me

Ahhh we were thinking Nirvana at first

I'm using the folder /etc/nginx/conf.d/ for several tricks and all of the files I create there are deliberately given a special name, so I know in which order they are executed. It seems you have the same problem as @Dukemaster Although he has a file there it is not adding headers. Have you checked your site with Analyse your HTTP response headers ?? Does it add any headers??

Yes we have checked several separate sites on our server using Analyse your HTTP response headers and other similar checks too. We did this before posting this thread, in case we had missed something obvious. The results confirm that the previous application of all these processes has stopped - but obvioulsy don't explain why

 

[learning_curve]

The most important post is this one : Resolved - How can I adjust HSTS in Plesk? I use Apache + Nginx and all my headers including HSTS are set in Apache configuration, not in nginx

We are guessing that you have edited the /etc/httpd/conf.d/ssl.conf file** itself? Then restarted Apache? Or was there another method that you used? That's an immediate recovery option we guess so thanks for the info there, but unluckily, we have two sites that are nginx only i.e. not just proxy for Apache like the others, which is why the previous method was great (for us) ** as detailed in the Best Answer within Resolved - How can I adjust HSTS in Plesk?

 

[learning_curve]

What does this command tell you?

nginx -T | grep "add_header " | grep -v Plesk

Apart from our server name being different, we receve exactly the same response as @Dukemaster did. Exactly the same. All the content he has posted, is the content of the file that's now "being ignored" in the current "runnning order" for whatever reason

 

[Dukemaster]

YES, that the problem which drives me crazy...i worked now over 30 hours without sleep and no light at the end of the tunnel...
From the config it must be HSTS. Why is it not shown? Something must be blocking it or qualys doesn't like me anymore...
thanks for the first real answer saying like it is. Perfect configuration but no success.
And the horror overwhelmed me two hours ago...I wanted to delete subdomain mail.arox.eu and I for the unsleepness I deleted the whole subscription also with the other subdomain server.arox.eu which is my hostname. But okay. I recreated it.
But I wondered why my subscription backup was not able to upload because of certificate error.
Now the domain is recreated and the subdomain too. but the old problem hsts is also present and another with email problem certificate warning in Thunderbird. webmail working with all domains but normal email has the server hostname in certificate which is untrusted...I wnat a clean correct environment and no allowing warnings in thunderbird. thats not the best way.

Thanks and greets

 

[learning_curve]

Surely this can only be as a result of the continuing improvemnts to Plesk, but one that unfortunately at the same time, has removed the inclusion of this file - collateral damage?

Within etc/nginx/nginx.conf (which hasn't changed at all - checked via file date & time etc) and within the http {} section, is the important line:

include /etc/nginx/conf.d/*.conf;

So any custom files that are correctly named (i.e. *.conf) and that are located in here, like the one we are all using should be included when the header is being configured by nginx?

Tracing this, to see where the restruction is now being applied, is beyond our level of code / process / Plesk knowledge etc but hopefully one of the Plesk experts can help identify this

 

[learning_curve]

Interestingly, after seeing the results of

nginx -T | grep "add_header " | grep -v Plesk

which are shown above and having previously used Analyse your HTTP response headers & SSL Server Test (Powered by Qualys SSL Labs) & a few other tools to check progress on this, we then seperately checked both http (see below) and https via View HTTP Request and Response Header and that does show that the http header being configued correctly. It's only https tests that show the incorrect config i.e. the additional file content that includes the HSTS as detailed in previous posts above being ignored / muted / missed or whatever.

Particularly difficult for us as we have no http pages on any site / domain on our server. All https and re-directs are applied via Permanent SEO-safe 301 redirect from HTTP to HTTPS within the Plesk Panel on all domains...

Status: HTTP/1.1 301 Moved Permanently
Server:    nginx   
Date:    Thu, 20 Jul 2017    
Content-Type:    text/html   
Content-Length:    178   
Connection:    close   
Location:    https:// **domain being tested**  
X-Frame-Options:    SAMEORIGIN   
X-XSS-Protection:    1; mode=block   
X-Content-Type-Options:    nosniff   
Strict-Transport-Security:    max-age=15768000;includeSubDomains

Odd that all the correct code is in place, but is not "visible" when & where it counts. (The 301 report is correct - see above)

 

[virtubox]

By testing with/without redirects, if headers are set with Apache, it require to se them in http and in https to apply them during the redirection from http to https.
So, in your case it seems nginx apply them only before the redirection.
You can also use HSTS Preload List Submission to automatically preload HSTS on your domains.

 

[mr-wolf]

What are the permissions of the config files?
Mine are only rw for the user (root).
All other permissions are off

i'm not saying it is the problem, but I've seen programs reject configs because the file permissions were too open.

chmod 600 /etc/nginx/conf.d/*.conf
chown root:nginx /etc/nginx/conf.d/*.conf

 

[learning_curve]

By testing with/without redirects, if headers are set with Apache, it require to se them in http and in https to apply them during the redirection from http to https. So, in your case it seems nginx apply them only before the redirection. You can also use HSTS Preload List Submission to automatically preload HSTS on your domains.

Yes, that looks to be the case, however, that was NOT the case until after recent Plesk updates... That's why we guessed and said there may have been some collateral damage after one of the updates. We know about the preload option and it can be a good choice, but it's only for HSTS, not the other security items in the file unfortunately

 

[virtubox]

Yes, that looks to be the case, however, that was NOT the case until after recent Plesk updates... That's why we guessed and said there may have been some collateral damage after one of the updates. We know about the preload option and it can be a good choice, but it's only for HSTS, not the other security items in the file unfortunately

Don't worry, all this issues are fixed with the release 18.2 with the new Additional headers area. It automatically apply the headers to nginx

 

[learning_curve]

What are the permissions of the config files?

By default, both /etc/nginx/nginx.conf.default AND /etc/nginx/nginx.conf in the level above are 644. The default /etc/nginx/conf.d/zz010_psa_nginx.conf however is 600 as per your findings, whilst our own file here was 644. We've changed that to 600 and the difference is..... nothing Still it was worth a shot and is a quick result

 

[learning_curve]

Don't worry, all this issues are fixed with the release 18.2 with the new Additional headers area. It automatically apply the headers to nginx

Ahhh We're a bit lost there... As per our signature, we're on the latest Onyx 17.5.3 release i.e. #14 but you're referring to #18.2 as per your earlier post as well. What you have posted seems to be a good solution, but not (for us at present, anyway) if it's not in the Onxy release that we are using There must be another way to solve this. Maybe we'll try the apply to the previoulsy mentioned Apache Only option and see if that works. Our two nginx only sites won't be fixed, but the others might be