How to improve security in nginx bloc for jupyterhub – discuss

Hi everyone,

I have set up a jupyterhub server with nginx as reverse proxy. I start making the nginx bloc configuration file using the one give in the official documentation and I add some rules to « harding nginx ».

This is the current configuration file :

# Top-level HTTP config for WebSocket headers
# If Upgrade is defined, Connection = upgrade
# If Upgrade is empty, Connection = close
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# HTTP server to redirect all 80 traffic to SSL/HTTPS
server {
    listen 80;
    server_name jpthb.ada-lovelace.net;

    # Redirect the request to HTTPS
    return 302 https://$host$request_uri;
}

# HTTPS server to handle JupyterHub
server {
    listen 443 ssl http2;

    server_name jpthb.ada-lovelace.net;

    ssl_certificate /some/secure/path/jpthb_ada-lovelace_net.cer;
    ssl_certificate_key /some/secure/path/jpthb_ada-lovelace_net.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /some/secure/path/dhparam.pem;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security max-age=15768000;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
    add_header X-Xss-Protection "1; mode=block";
    autoindex off;
    proxy_hide_header X-Powered-By;
    proxy_hide_header Composed-By;

    # Managing hidden files
    location ~ /\.git {
        return 404;
    }
    location ~ /\~ {
        return 404;
    }
    location ~ /\.back {
        return 404;
    }
    location ~ /\.save {
        return 404;
    }

    # Managing literal requests to the JupyterHub frontend
    location / {
        proxy_pass https://127.0.0.1:8000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # websocket headers
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header X-Scheme $scheme;

        proxy_buffering off;
    }
    if ($server_protocol = HTTP/1.0) {
    return 444;
    }

}

To complete this file, I just need to adapt one rule :

if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) {
    return 405;
}

This one is not sufficient because when I add this in the nginx configuration file, all the users can authenticate themself on Jupyterhub but it’s impossible to create a notebook or to launch a kernel : it always leads to « Errror 405 ». If I remove this rule, Jupyterhub works fine again.

I know I have to add some http protocol in this list GET|HEAD|POST|OPTIONS but I really don’t know wich one.

Could someone see what protocol I miss ?

Thank’s a lot,
arnome.

PS : all the rules I add come from an internal document of the french Inrae Institution call « Hardening nginx », this document is not specific to jupyterhub configuration.

Try going to your browser console and looking at the network requests:
support.happyfox.com/kb/article/882-accessing-the-browser-console-and-network-logs/

You can also edit your nginx log format to include the request method, though I’m surprised it’s not already there:
nginx.org/en/docs/http/ngx_http_log_module.html

At first glance it looks like PATCH may be needed, but the combination of your browser and nginx logs should confirm this.

Read more here: Source link