NGINX: Access Management and Security Controls EMEA

NGINX: Access Management
and Security Controls

MORE INFORMATION AT NGINX.COM
Agenda
• Introducing NGINX
• Server protection with access control lists
• Transport security with SSL/TLS, including
Let’s Encrypt
• Authenticating users
• Backend protection with rate limiting and
other controls
• Summary and Q&A
3
Liam Crilly
Director of Product
Management, NGINX
liam@nginx.com
@liamcrilly

4
“... when I started NGINX,
I focused on a very specific
problem – how to handle more
customers per a single server.”
- Igor Sysoev, NGINX creator and founder

NGINX v0.1 published in 2004
NGINX, Inc. founded in 2011
NGINX Plus released in 2013
Offices in San Francisco, Cambridge (UK), Cork, Moscow and Singapore
400M websites
1,200+ commercial customers
200+ employees across engineering, support, sales and marketing

Source: Source information goes here.Source: Source information goes here.
#1for the busiest sites
The busiest sites choose NGINX
6
44%
55%
63%
Top 1M Top 100K Top 10K
Source: W3Techs Web server ranking 23-Jan-2018

Where NGINX Plus fits
HTTP,
TCP, UDP
Web/Application Clusters
Internet

Pre-requisites
• NGINX or NGINX Plus installed from our official repo
• OSS: nginx.org/en/download.html
• Plus: nginx.com/resources/admin-guide/installing-nginx-plus/
• Basic knowledge of NGINX configuration

Agenda
• Introducing NGINX
• Server protection with access control lists
• Transport security with SSL/TLS, including Let’s Encrypt
• Authenticating users
• Backend protection with rate limiting and other controls
• Summary and Q&A

IP Access Control Lists
# White list
location /internal-only/ {
allow 10.0.0.0/8;
allow 192.168.1.32;
allow 2001:0db8::/32;
deny all;
}
# Black list
location /external-only/ {
deny 10.0.0.0/8;
deny 172.16.0.0/16;
deny 192.168.0.0/16;
allow all;
}
• Restrict access by IP address
• Can create white lists or black lists
• Can be used at server level as well
• Also supported for stream module (TCP/UDP)
traffic

Dynamic IP Black List
server {
listen 1111;
allow 127.0.0.1; # Prevent remote access
deny all;
location /api {
api write=on;
}
}
keyval_zone zone=blacklist:1M;
keyval $remote_addr $banned zone=blacklist;
server {
listen 80;
location / {
root /usr/share/nginx/html;
if ($banned) {
return 403;
}
}
}
• First server block enables NGINX Plus API
and restricts its usage.
• keval_zone – Creates shared memory zone
to be used for key-val store
• keyval – Defines the key to value mapping
• Can use fail2ban to dynamically manage the
blacklist, search for fail2ban on nginx.com
Note: NGINX Plus API and key-val store is
exclusive to NGINX Plus.

Dynamic IP Black List
$ curl http://localhost:1111/api/1/http/keyvals/blacklist
{}
$ curl -id '{"10.0.0.1":"1"}'
http://localhost:1111/api/1/http/keyvals/blacklist
HTTP/1.1 201 Created
$ curl -iX PATCH -d '{"10.0.0.1":null}'
HTTP/1.1 204 No Content
$ curl -iX DELETE
HTTP/1.1 204 No Content
• Query blacklist key-val store
• Black list an IP Address
• Remove single IP Address from
the blacklist
• Remove all IP Address from the
blacklist

Let’s Encrypt with NGINX
server {
listen 80 default_server;
server_name example.com www.example.com;
# ...
}
1. Create basic virtual server config in
NGINX. Make sure to use
server_name directive to specify
domains to be encrypted.
1. Install and run certbot client. The
client will automatically configure
NGINX virtual server with
server_name matching domains
specified in -d argument.
$ add-apt-repository ppa:certbot/certbot
$ apt-get update
$ apt-get install python-certbot-nginx
$ certbot --nginx -d example.com -d
www.example.com
Congratulations! You have successfully enabled
https://example.com and https://www.example.com
<snip>

Let’s Encrypt with NGINX
3. Create cron to automatically renew
certificates. Let’s Encrypt certificates
are valid for only 90 days.
Notes:
• certbot will automatically add in
configuration to redirect all traffic to
HTTPS.
• ECC certificates not yet supported by
certbot.
• HTTP/2 not supported by certbot,
but can be added by manually editing
configuration.
$ crontab -e
0 12 * * 0 /usr/bin/certbot renew --quiet

Manual SSL Configuration
server {
listen 80 default_server;
server_name www.example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl default_server;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers HIGH;
location / {
#...
}
}
• Force all traffic to SSL
• Use ssl_certificate and
ssl_certificate_key to specify
public certificate and private key
respectively.

SSL Session Caching and HTTP/2
server {
listen 443 ssl http2 default_server;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers HIGH;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
}
• Improves SSL/TLS performance
• 1 MB session cache can store about 4,000
sessions
• Cache shared across all NGINX workers
• HTTP/2 improves performance
• Note: HTTP/2 requires OpenSSL 1.0.2 to
work properly

Dual-stack RSA/ECC SSL Configuration
server {
ssl_certificate cert_rsa.crt;
ssl_certificate_key cert_rsa.key;
ssl_certificate cert_ecdsa.crt;
ssl_certificate_key cert_ecdsa.key;
# ...
}
• Specify two sets of
ssl_certificate and
ssl_certificate_key directives
• NGINX will serve ECDSA cert for
clients that support it and RSA for
those that don’t
• Most modern browsers and OS’s
support ECC
• ECC has 2-3x better performance
than RSA based on our testing.

Using SSL to Upstream Servers
upstream my_upstream {
server server1.example.com;
server server2.example.com;
}
server {
listen 443 ssl;
# ...
location / {
proxy_set_header Host $host;
proxy_pass https://my_upstream;
}
}
• Use https instead of http in the
proxy_pass directive

Client Certificate Authentication
server {
ssl_client_certificate ca.crt;
ssl_verify_client on;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
• ssl_client_certificate – Specify
CA certificate chain used to verify
client certificate is valid.
• ssl_verify_client – Enable
verification of client certificates. Can
also be set to optional and
combined with $ssl_client_verify
to enforce client certificates for certain
locations.

HTTP basic authentication
$ apt-get install apache2-utils
$ htpasswd –c /etc/nginx/.htpasswd user1
New password:
Re-type new password:
Adding password for user user1
• Use htpasswd utility to create a password
file.
• Outputted file has format
user:md5_password
• auth_basic enables HTTP basic
authentication for the given context.
• auth_basic_user_file specifies the
user password file we generated.
location /status {
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;
}

HTTP subrequest authentication
location /private {
auth_request /auth;
proxy_pass http://my_upstream;
}
location = /auth {
internal;
proxy_pass http://auth_server;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
• auth_request instructs NGINX to create
an HTTP subrequest before allowing
access. If the subrequest results in a
HTTP 200 OK

JSON Web Tokens (JWT)
1. Client requests JWT from issuer
1. Issuer validates client and issues
JWT
2. Client submits JWT to NGINX Plus
for validation
3. NGINX Plus validates JWT and
passes relevant field to upstream
servers as HTTP headers
Note: JWT authentication is exclusive to
NGINX Plus

Anatomy of a JWT
{
"typ":"JWT",
"alg":"HS256",
"kid":"0001"
}
{
"name":"Xavier Ample",
"sub":"xample@example.com",
"exp":"1577836800",
"iss":"My Issuer"
}
First object is the header:
• typ – Defines type as JSON Web Token
• alg – Specifies JWT is signed HMAC SHA-
256.
• kid – Specifies signing key identifier
Second object is the payload:
• name – Full name of client
• sub – Unique identifier for client
• exp – Expiration date, measured in seconds
since epoch
• iss – Issuer of JWT, useful if accepting
JWTs from multiple issuers and 3rd parties.
• The complete JWT is Base64-encoded. A
dot (.) separates the header, payload, and
signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsYzEiLCJ
lbWFpbCI6ImxpYW0uY3JpbGx5QG5naW54LmNvbSIsImV4cCI6IjE0ODM
yMjg3OTkifQ.VGYHWPterIaLjRi0LywgN3jnDUQbSsFptUw99g2slfc

NGINX Plus JWT Configuration
location /products/ {
auth_jwt "Products API" token=$http_apikey;
auth_jwt_key_file issuer_keys.jwk;
proxy_set_header API-Client $jwt_claim_sub;
proxy_pass http://api_endpoint;
}
• auth_jwt – Enables JWT authentication
for this context and defines the realm.
Optional token parameter specifies where
the JWT token. By default NGINX Plus
looks in the Authorization header for a
Bearer token.
• auth_jwt_key_file – Specifies the
location of the JSON Web Key (JWK) file.
Analogous to the public certificate, used by
NGINX Plus to verify
• All JWT claims are put into variables with
the following format: $jwt_claim_name.
Variables can then be put into HTTP
headers and sent to upstream servers.

Nested JWT Claims and Array Data
{
"exp": 1513429677,
"sub": "xample@example.com",
"aud": "nginx",
"attributes": {
"name": "Xavier Ample",
"room": "A123",
"dept": "Demonstrations"
},
"groups": [
"Administrator",
"Foobar",
"Bazpub"
]
}
• A JWT payload can contain “nested”
information about the user, such as group
membership, which can be used to
authorize access to a resource. This helps
avoid the need to query a database
multiple times to authorize user requests.
• attributes is a nested JWT claim
• groups is an array

Nested JWT Claims and Array Data
auth_jwt_claim_set $jwt_groups groups;
auth_jwt_claim_set $jwt_real_name attributes name;
map $jwt_groups $isAdmin {
"~bAdministratorb" 1;
default 0;
}
server {
listen 443 ssl;
auth_jwt "closed site";
auth_jwt_key_file jwk.json;
location /admin {
if ($isAdmin = 0) {
return 403; # Forbidden
}
proxy_pass http://my_backend;
}
}
• auth_jwt_claim_set – Will convert
arrays into comma separated list. Can also
be used to extract nested claim.
• map – Used to determine if user is member
of Administrator group
• Using if statement, users not member of
Administrator group are denied access

NTLM Proxying
upstream http_backend {
server 127.0.0.1:8080;
ntlm;
}
server {
# ...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
• ntlm – Instructs NGINX needs to
maintain keepalive connections to
upstream servers so request from
different users are not interleaved on the
same connection. This is required for
NTLM to work.
• Note: NTLM proxying is exclusive to
NGINX Plus

Rate limiting
limit_req_zone $binary_remote_addr zone=mylimit:10m
rate=10r/s;
server {
location /login/ {
limit_req zone=mylimit burst=10 nodelay;
}
}
• limit_req_zone -- Defines the
parameters for the rate limit. Each unique
IP is limited to 10 requests/sec.
• limit_req -- Instantiates rate limit for the
given context.
• The burst and nodelay parameters allow
for bursting. Recommended for most
deployments.

Rate limiting by user
limit_req_zone $remote_user zone=mylimit:10m
rate=10r/s;
server {
location /login/ {
limit_req zone=mylimit burst=10 nodelay;
}
}
• $remote_user
Username when using HTTP Basic auth
• $ssl_client_fingerprint
Unique identifier of client certificate
• $jwt_claim_sub
Userid when using JWT authentication

Connection limiting
upstream my_upstream {
server myserver.example.com max_conns=50;
}
limit_conn_zone $binary_remote_addr zone=mylimit:10m;
server {
location /download/ {
limit_conn mylimit 1;
}
}
• limit_conn_zone – Defines some
parameters for the connection limit. Each
unique IP will be limited.
• limit_conn – Instantiates it for the given
context and defines what the limit is. Only
one connection per IP address will be
allowed.
• max_conns – Defines connection limit to
upstream server
• Also supported in stream module
(TCP/UDP).

Bandwidth Limiting
server {
location /download/ {
limit_rate_after 500k;
limit_rate 20k;
}
}
• limit_rate defines the overall bandwith
limit in bytes per second.
• limit_rate_after says to impose the
limit only after the specified amount of data
is downloaded.
• For stream (TCP/UDP) use
proxy_download_rate and
proxy_upload_rate.

Summary
• NGINX IP access control lists can be used to restrict access by IP
Address
• NGINX supports SSL/TLS offload with integration to Let’s Encrypt
• HTTP Basic and Subrequest Authentication can be used to provide
authentication services to your application
• NGINX Plus supports JWT authentication to restricts access to APIs
• Rate, connection, and bandwidth limiting can help mitigate some
forms of DDoS

Q & ATry NGINX Plus free for 30 days: nginx.com/free-trial-
request

NGINX: Access Management and Security Controls EMEA

Recommended

Recommended

More Related Content

More from NGINX, Inc.

More from NGINX, Inc. (20)

Recently uploaded

Recently uploaded (20)

NGINX: Access Management and Security Controls EMEA

Editor's Notes