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

[mr-wolf]

What happens if you make an incorrect statement in the file /etc/nginx/conf.d/aa400_own_tweaks.conf ??
Have you seen this thread? Input - How to add nginx header for all https sites (but NOT plain http)?
Did you try the exact content of my file?

What's the output of:

nginx -V && grep conf.d /etc/nginx/nginx.conf

and

nginx -T | grep /etc/nginx/conf.d/

 

[learning_curve]

What happens if you make an incorrect statement in the file /etc/nginx/conf.d/aa400_own_tweaks.conf ?? Have you seen this thread? Input - How to add nginx header for all https sites (but NOT plain http)? Did you try the exact content of my file?

The original statement made in the file was correct, in that it was a duplication of the guidance given by @UFHH01 in THIS earlier thread. As we have said, it worked perfectly until very recently.

Yes we've just read your other thread, which looks like in may indeed solve the problem! We'll try that modified content first and then report back before anyting else!

 

[mr-wolf]

Yes we've just read your other thread, which looks like in may indeed solve the problem! We'll try that modified content first and then report back before anyting else!

I wouldn't know about that...
In my configuration I had no problems with adding the header in the normal way (both http and https).
It's only that I just recently found out it was not done.
So I'm glad I have that solved and shared with the Plesk community.

Still interested in the output of

nginx -T | grep /etc/nginx/conf.d/

 

[learning_curve]

I wouldn't know about that...
In my configuration I had no problems with adding the header in the normal way (both http and https).
It's only that I just recently found out it was not done.
So I'm glad I have that solved and shared with the Plesk community

Yes a great find thanks!
Modifying our own file after reading this takes us closer... but no cigar yet
It has removed the content from the http file, but not yet (!) added it into the https file
The plot thickens...

Still interested in the output of

nginx -T | grep /etc/nginx/conf.d/

The output of that is:

[****@**** /]# nginx -T | grep /etc/nginx/conf.d/
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
    include /etc/nginx/conf.d/*.conf;
# configuration file /etc/nginx/conf.d/ssl.conf:
# configuration file /etc/nginx/conf.d/zz010_owntweaks_nginx.conf:
# configuration file /etc/nginx/conf.d/zz010_psa_nginx.conf:
[****@**** /]#

 

[mr-wolf]

Why did you have zz010_owntweaks_nginx.conf ??
It should be aa400_owntweaks_nginx.conf

# nginx -T | grep /etc/nginx/conf.d/
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
    include /etc/nginx/conf.d/*.conf;
# configuration file /etc/nginx/conf.d/aa400_own_tweaks.conf:
# configuration file /etc/nginx/conf.d/aa500_psa_tweaks.conf:
# configuration file /etc/nginx/conf.d/ssl.conf:
# configuration file /etc/nginx/conf.d/zz010_psa_nginx.conf:
# configuration file /etc/nginx/conf.d/zz090_assp.conf:
# configuration file /etc/nginx/conf.d/zz090_rslsync.conf:
# configuration file /etc/nginx/conf.d/zz090_syncthing.conf:
# configuration file /etc/nginx/conf.d/zz095_autodiscover.conf:

 

[learning_curve]

Why did you have zz010_owntweaks_nginx.conf ??
It should be aa400_owntweaks_nginx.conf

The actual file name is irrelevant surely in our case? Other than when possibly implementing a 'running order' in this sub-directory / specific process and that is, if they have any possible data process issues in between them, but we have many less files than your own example currently as you can see. However, to completely erradicate that possiblity, we've changed it as per your naming example pattern then run re-test / re-start and it's exactly the same result i.e. close but no cigar - yet

 

[mr-wolf]

But it determines the running order of the config file?
For that reason I have the autodiscover (which uses a regular expression for server_name) as last.

But I just made a new discovery.
My zz090_assp.conf is giving me an E whilst zz090_syncthing.conf is giving me a B (which is good).

I copied zz090_syncthing.conf to zz090_assp.conf and changed the server name.
That will give me a B
But when I change the proxy_pass to http://127.0.0.1:55555 it will go back to E.

This means that the service behind it is making it lose all its headers (not the HSTS though)
Very strange.......


Even stranger:

If I add this to zz090_assp.conf it will go even further down to F because it also loses the HSTS header???

add_header 'Referrer-Policy' 'strict-origin-when-cross-origin';
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;

 

[learning_curve]

A good example of how things can get complicated, quite quickly If we go back to where we started, we had one simple custom file (in our case) which worked perfectly and did everyting it needed to do (for us). Now it doesn't, yet the file's content was completely unaltered in all the tests we did, until we included the extra details that you kindly advised us about, which as you have now seen, didn't reproduce the previous status anyway. We'll need to retrace back to providing the file's original content and then trace the problem from there. When we find it, we'll restore the status quo and then carry out some extra improvments, including the ones that you have kindly shared. Now it's coffee and deep thinking time...

 

[mr-wolf]

As an experiment I just added a header for "Content-Security-Policy" to my zz090_autodiscover.conf
Instead of going from B to A I went down to F
According to the securityheaders site I lost all my headers by adding

add_header Content-Security-Policy "default-src 'self';";

This time, after adding all the "generic" headers explicitly in the file I was indeed able to to get all the headers back and get my status to A

 

[learning_curve]

Okay, we have deleted the additional file that we previously had added to /etc/nginx/conf.d and added all the details of it into /etc/httpd/conf.d/ssl.conf then run the re-test on both apache and nginx and then run re-start on both. Now everyting works exactly as it did previously (apart from the two nginx only sites...). This is an interim measure which adds the security back in whilst we figure out what's happening in nginx-land, which we're going to investigate, but which may take some time!

Edit: This action also solves the '...apply HSTS to https only and not http at the same time' issue...

 

[mr-wolf]

I was able to get zz090_assp.conf to A by adding the "always" to the other headers as well.
The site needs authentication before you get the whole page. That was the reason why it needs this extra parameter.

# cat /etc/nginx/conf.d/aa400_own_tweaks.conf

map $scheme $hsts_header {
    https   'max-age=15768000; preload';
}

add_header Strict-Transport-Security $hsts_header always;

ssl_session_timeout         10m;
ssl_session_cache shared:SSL:50m;

ssl_dhparam /etc/dhparam/dhparam4096.pem;

add_header 'Referrer-Policy' 'strict-origin-when-cross-origin' always;
add_header X-Frame-Options SAMEORIGIN always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options nosniff always;

# cat /etc/nginx/conf.d/zz090_assp.conf

server {
    listen 23.23.22.20:443 ssl;
    server_name assp.domain.com;

    error_log /var/log/nginx/ownservices/error.log;
    access_log /var/log/nginx/ownservices/access.log combined;

    ssl_certificate             /root/.ssh/wildcard.pem;
    ssl_certificate_key         /root/.ssh/wildcard.key;

    ssl_stapling on;
    ssl_stapling_verify on;

    add_header          Strict-Transport-Security       "max-age=15768000; preload" always;
    add_header          Content-Security-Policy         "default-src 'self';" always;
    add_header          Referrer-Policy                 strict-origin-when-cross-origin always;
    add_header          X-Frame-Options                 SAMEORIGIN always;
    add_header          X-XSS-Protection                "1; mode=block" always;
    add_header          X-Content-Type-Options          nosniff always;

    ssl_dhparam         /etc/dhparam/dhparam4096.pem;
    ssl_session_timeout 5m;

    ssl_protocols       TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers   on;

    client_max_body_size 128m;

    location / {
        proxy_pass https://127.0.0.1:55555;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

 

[learning_curve]

Good post. With the Apache fallback position in place now, we'll revert back to solving our own nginx process flow tomorrow. Ironically, it looks like you've self-repaired some of your own stuff, whilst testing things with a view to wanting to help us Updates tomorrow!

 

[Dukemaster]

Hi,
@mr-wolf please can you tell me which environment you use? I mean apache with nginx or only nginx? and also which FPM setting?
Because it comes obvious that not all of us talking here in this thread have the same setup. And I wouldn't like to try tutorials which can never solve my problems because of different environment. it's very important.
I had HSTS and therefor A+ for months. But since I use own DNS, tried unsuccessful additional IPv6, also tried unsuccessful DNSSEC (provider doesn't support it), and activated successfully OCSP-stapling, somewhere around this changes it seems (!) that I've lost HSTS.

If there would be the possibiliy to reset/backup Plesk to the time 6 weeks ago, I would immediatly do it. But I have no self-made server backup and I've a problem in general with backup at the moment..
Yesterday I couldn't restore my arox.eu subscription backup due to certificate error?????.
Greets

 

[mr-wolf]

I have Nginx as proxy for Apache.
Apache is handling PHP, most of them running PHP-FPM 7.1

I have several services running a webIF on localhost.
I use Nginx to make these accessible from the Internet using a configuration in /etc/nginx/conf.d/

I have several Plesk servers.
On 1 I have a server-wide setting for all parameters including HSTS, but I would advice against that.
As a matter of fact I will stop it soon as I just remembered that the Thunderbird autoconfig procedure is a plain http thing.
I don't think that the Thunderbird http autoprovisioning client will honour these headers, but it just proofs how easy it is to overlook some thing.
For that reason I advice you to not use IncludeSubDomains.

This is the config on my server with many sites:
cat /etc/nginx/conf.d/aa400_own_tweaks.conf

map $scheme $hsts_header {
    https   'max-age=15768000; preload';
}

ssl_session_timeout     10m;
ssl_session_cache       shared:SSL:50m;

ssl_dhparam             /etc/dhparam/dhparam4096.pem;

This is what I set in Additional nginx directives

add_header Strict-Transport-Security $hsts_header always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

add_header X-Frame-Options SAMEORIGIN always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options nosniff always;

 

[learning_curve]

....also tried unsuccessful DNSSEC (provider doesn't support it) and activated successfully OCSP-stapling...

FWIW @Dukemaster We also use 1 and 1 and as you now know, they don't currently directly support both DNSSEC and more importantly DNS CAA because this is compulsory from September. There is a usable Plesk extention for DNSSEC but it's kind of pointless if all your DNS is currrently managed by 1 and 1 as we discovered ourselves

...I have Nginx as proxy for Apache. Apache is handling PHP, most of them running PHP-FPM 7.1

We also use Nginx as proxy for Apache on all sites bar 2 which are Nginx only. On the proxy sites they are all on PHP-FPM 7.1 and Maria DB not MySQL

...For that reason I advice you to not use IncludeSubDomains

Yes we have seen others avoid this for similar reasons. We use it and it's fine for us. We don't use Thunderbird at all.

Our intention, is still to solve the original problem that we posted on this thread, which is to make all the additional security measures actually be applied by Nginx (i.e. as was the case anyway, until recently!) This suits us and our particular server setup. This was made via server-wide settings for all parameters including HSTS before this thread. We now may have to apply this to each specific domain via Additional nginx directives as you have done in most cases @mr-wolf

 

[mr-wolf]

If you don't like to add all the directives manually you could run the script that I created today.
It turns on the https redirect for all sites that have the WordPress Plugin "Really Simple SSL" installed.

Then it will create the vhost_nginx.conf file for all the sites that have https redirect enabled and still don't have that config.

ln -s /usr/local/sbin/gen_dhparam /etc/cron.weekly/
cat /usr/local/sbin/gen_dhparam

#!/bin/bash

mkdir -p /etc/dhparam 2>/dev/null
FILE=`mktemp`

N=512
while [ $N -le 4096 ] ; do
  openssl dhparam $N -out $FILE && cat $FILE >/etc/dhparam/dhparam${N}.pem
  let N*=2
done

rm -f ${FILE}

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

map $scheme $hsts_header {
    https   'max-age=15768000; preload';
}

ssl_session_timeout     10m;
ssl_session_cache       shared:SSL:50m;

ssl_dhparam             /etc/dhparam/dhparam4096.pem;

cat /usr/local/sbin/reallysimple.vhost_nginx

add_header Strict-Transport-Security $hsts_header always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

add_header X-Frame-Options SAMEORIGIN always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options nosniff always;

cat /usr/local/sbin/reallysimple

#!/bin/bash

HEADLESS=
tty >/dev/null || HEADLESS=true

THISSCRIPT="`readlink -f $0`"
SCRIPTNAME=${THISSCRIPT##*/}
BASE=${THISSCRIPT##*/}
[ -z "${BASE}" ] && BASE=${0##*/}

LOG=/var/log/${SCRIPTNAME}.log

PLESKBIN=/usr/local/psa/bin/domain

TMPDIR=`mktemp -t -d ${0//*\/}.XXXXXXXXXX`

# Collect all the Plesk domains
find /var/www/vhosts/ -type d -name really-simple-ssl | cut -b17- | sed 's/\/.*//g' | sort -uo ${TMPDIR}/plesk_domains

while read DOMAIN ; do
  ${PLESKBIN} -i ${DOMAIN} >${TMPDIR}/domaininfo

  if grep -q "SEO-safe 301.*HTTPS:Off" ${TMPDIR}/domaininfo ; then
    echo "Turn on Permanent SEO-safe 301 redirect from HTTP to HTTPS for ${DOMAIN}" | tee -a ${LOG}
    ${PLESKBIN} -u ${DOMAIN} -ssl-redirect true | tee -a ${LOG}
  fi
done<${TMPDIR}/plesk_domains

if [ -s ${THISSCRIPT}.vhost_nginx ] ; then
  # Collect all the Plesk domains
  mysql --skip-column-names -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "SELECT domains.name FROM domains ORDER BY domains.name ASC; " 2>/dev/null | egrep -v '\..+\.' | tr 'A-Z' 'a-z' | sort -uo ${TMPDIR}/plesk_domains

  while read DOMAIN ; do
    [ ${HEADLESS} ] || echo ${DOMAIN}
    #  ${PLESKBIN} -u ${DOMAIN} -ssl-redirect true | tee -a ${LOG}
    ${PLESKBIN} -i ${DOMAIN} >${TMPDIR}/domaininfo
    if grep -q "SEO-safe 301.*HTTPS:On" ${TMPDIR}/domaininfo ; then
      NGINXCONF=/var/www/vhosts/system/${DOMAIN}/conf/vhost_nginx.conf

      if [ ! -e ${NGINXCONF} ] ; then
        echo "create ${NGINXCONF}" | tee -a ${LOG}
        cat ${THISSCRIPT}.vhost_nginx >${NGINXCONF}
        chmod 600 ${NGINXCONF}
        chown root:nginx ${NGINXCONF}
        plesk repair web ${DOMAIN}
      fi
    fi
  done<${TMPDIR}/plesk_domains
fi

rm -r ${TMPDIR}

 

[learning_curve]

That's a very helpful post. However, we don't use Wordpress anywhere currently so we'll need to manually and patiently apply them one by one, later today

 

[mr-wolf]

Then you should read again what I wrote...
The Wordpress plugin detection is an extra. It will turn on redirection to https for those sites

Then for all domains that have redirection enabled it will create the config


If you want to turn on redirect to https ON for all sites (only once), you could uncomment the line

# ${PLESKBIN} -u ${DOMAIN} -ssl-redirect true | tee -a ${LOG}

 

[learning_curve]

We understood your post perfectly. Re-direction is enabled via Hosting Settings within Plesk Panel in our setup. Very easy, accurate and functional, so for us, no plug-ins (Wordpress or otherwise) and/or other methods are needed. That was the point we were illustrating. Adding all the features manually to each domain will allow us to test them one at a time. Not as convenient as your script obvioulsy, but that aproach suits us and Additional nginx directives is easy to use within the Plesk Panel

 

[learning_curve]

Update: On the two nginx only domains, we can achive everything that we need (A or A+ everywhere and no issues) by adding all the required details (except server-wide SSL rules like TLS1.2 only for example) by adding all the headers / rules / conditions via Additional nginx directives for each of the two domains. We haven't gone back to all the other domains that are temporarilly being controlled by Apache only (i.e. the Nginx Proxy / Apache domains) but we'll patiently look at each one of those tomrrow. Still haven't figured out why this stop working when it was specified server-wide via Nginx until recently, but the most important issue (for us) is normal service restoration / enhancement and only when that's complete, will we (maybe) we'll look at investigation within Plesk again as to why this happened.