...
Most distributions of NGINX no longer include sites-enabled
and sites-available
directories. This example installation is based on distribution that does not include these directories, and places the configuration file in the /etc/nginx/conf.d directory
. If your installed version of NGINX includes sites-enabled
and sites-available
directories, consult the NGINX documentation for further guidance.
Save a backup of the default configuration file:
Code Block |
---|
sudo mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.bak |
...
Drop HTTP v1.0 traffic: in the configuration below, we drop HTTP v1.0 traffic - see comment in the configuration. As noted, there is a possible very minor impact if you are building a website that you want to be discoverable on all search engines, but this is unlikely to affect major search engines. We have taken the option to drop HTTP v1.0 traffic because this is very straightforward; the alternative configuration to allow HTTP v1.0 but mitigate specific risks is more complex, and in our opinion, overall a bigger risk to reliably providing the service because it is more prone to being configured incorrectly or having unintended consequences.
Save a backup of the default configuration file:
Code Block |
---|
sudo mv /etc/nginx/conf.d/ |
...
default.conf /etc/nginx/conf.d/default.conf.bak |
Create configuration file for PhixFlow: open editing on a file /etc/nginx/conf.d/phixflow.conf
(e.g. with sudo nano /etc/nginx/conf.d/phixflow.conf
), and paste in the following, replacing [domain]
with your domain, e.g. phixflow.mycompany.com:
...
domain]
with your domain, e.g. phixflow.mycompany.com:
Code Block |
---|
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl ipv6only=on;
server_name [domain];
# Drop all HTTP v1.0 traffic. Only a very small number of legitimate robots now use this, and in most cases PhixFlow installations are not intended to be found via
# search engines, and even if they are, this is unlikely to have anything other than a very minor effect. We can realistically assume that no user connections will use HTTP v1.0.
# HTTP v1.0 can be used by malicious actors exploiting weaknesses in the protocol as part of an attack.
# If we have to re-instate this for some reason, there are migitations - for example, for the case when requests are submitted with HTTP v1.0
# with no header set, which can lead to exposing the private IP address of this (the reverse proxy) server; make sure, in this case, that we apply these mitigations.
if ($server_protocol ~* "HTTP/1.0") {
return 444;
}
proxy_intercept_errors on;
error_page 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 421 422 423 424 425 426 428 429 431 451 500 501 502 503 504 505 506 507 508 510 511 /custom_error.html;
location = /custom_error.html {
internal;
root /usr/share/nginx/html;
}
# add secure flag to XSRF-TOKEN cookie
proxy_cookie_flags XSRF-TOKEN secure;
location / {
proxy_pass http://127.0.0.1:8080;
}
ssl_certificate /etc/letsencrypt/live/[domain]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[domain]/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
client_max_body_size 150M;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
} |
...