Netcraft недавно опубликовал исследование сайтов SSL/TLS, которые они отслеживают, и заметил, что только 5% из них правильно реализуют HTTP Strict Transport Security (HSTS). В этой статье описывается настройка NGINX и NGINX Plus для реализации политики HSTS.

Что такое HSTS?

HTTPS (HTTP, зашифрованный SSL или TLS) является неотъемлемой частью мер по обеспечению безопасности трафика на веб-сайт, что делает его очень трудным для злоумышленника, чтобы перехватить, изменить или поддельный трафик между Пользователем и веб-сайта.

Когда пользователь вводит веб-домен вручную (предоставляя имя домена без префикса http:// или https://) или следует простой ссылке http://, первый запрос на веб-сайт отправляется незашифрованным, используя простой HTTP. Большинство защищенных веб‑сайтов немедленно отправляют перенаправление для обновления пользователя до HTTPS‑соединения, но хорошо расположенный злоумышленник может смонтировать атаку “человек в середине” (MITM) для перехвата первоначального HTTP‑запроса и может контролировать сеанс пользователя с этого момента.

HSTS стремится справиться с потенциальной уязвимостью, указывая браузеру, что доступ к домену можно получить только с помощью HTTPS. Даже если пользователь вводит или следует простой HTTP-ссылке, браузер строго обновляет соединение с HTTPS.

Как работает HSTS?

Политика HSTS публикуется путем отправки следующего заголовка ответа HTTP с защищенных (HTTPS) веб-сайтов:

Strict-Transport-Security: max-age=31536000

Когда браузер видит этот заголовок с веб-сайта HTTPS, он “узнает”, что этот домен должен быть доступен только с помощью HTTPS (SSL или TLS). Он кэширует эту информацию на максимальный период (обычно 31536000 секунд – это примерно 1 год).

Необязательный параметр includeSubDomains сообщает браузеру, что политика HSTS также применяется ко всем поддоменам текущего домена.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Например, ответ HTML для https://www.example.com может включать запрос к ресурсу от https://example.com, чтобы убедиться, что HSTS установлен для всех поддоменов example.com

Настройка HSTS в NGINX и NGINX Plus

Настройка заголовка ответа Strict Transport Security (STS) в NGINX и NGINX Plus относительно проста. Добавте параметр в конфигурационный файл nginx.conf:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Параметр always гарантирует, что заголовок задан для всех ответов, включая ответы на внутренние ошибки. Более старые версии NGINX (до версии 1.7.5 или NGINX Plus R5) не поддерживают параметр always и не устанавливают заголовок для внутренних ответов об ошибках.

Правила наследования для директив add_header

Блоки конфигурации NGINX наследуют директивы add_header от своих вложенных блоков, поэтому вам просто нужно поместить директиву add_header в серверный блок верхнего уровня. Существует одно важное исключение: если блок включает в себя директиву add_header, он не наследует заголовки от вложенных блоков, и вам нужно повторно объявить все директивы add_header:

server {     
    listen 443 ssl;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;     
# This 'location' block inherits the STS header     
    location / {         
        root /usr/share/nginx/html;     
    }     
# Because this 'location' block contains another 'add_header' directive,     
# we must redeclare the STS header     
    location /servlet {         
        add_header X-Served-By "My Servlet Handler";         
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;         
        proxy_pass http://localhost:8080;     
    } 
}

Тестируйте HTTP Strict Transport Security с осторожностью

После того, как клиент представлен с политикой HSTS, он кэширует информацию на указанный максимальный период. В течение этого периода браузер отказывается от доступа к веб-службе по незашифрованному HTTP. Если для политики HSTS указан параметр includeSubDomains, эти ограничения также применяются ко всем поддоменам текущего домена.

Очень сложно отказаться от политики HSTS, чтобы удалить HTTPS-версию веб-сайта или службы. Когда вы тестируете HSTS, используйте очень короткий максимальный тайм-аут и убедитесь, что вам комфортно с эффектами и обязательством поддерживать HTTPS-версию вашего сайта. Когда вы впервые начнете жить с вашей политикой HSTS, держите max-age маленьким и увеличивайте его только тогда, когда вы уверены в этом.

Должен ли каждый ответ HTTPS иметь заголовок STS?

Цель состоит в том, чтобы представить политику HSTS пользователям как можно скорее, когда они начинают сеанс HTTPS. Если они не получают политику HSTS во время сеанса, они останутся уязвимыми для будущих атак захвата HTTP.

Браузер должен наблюдать за заголовком STS только один раз, поэтому нет необходимости добавлять его в каждый блок местоположения и каждый ответ. Однако добавление его только на домашнюю страницу или страницу входа в систему, вероятно, недостаточно, и если вы добавите заголовок только к кэшируемым ответам, клиент может не увидеть его. Убедитесь, что вы покрываете как можно больше своего URL‑пространства, уделяя особое внимание динамическому (не кэшируемому) контенту.

Запуск HTTP и HTTPS версий веб-сайта бок-о-бок

Некоторые сайты запускают HTTP и HTTPS версии веб-сайта на одном сервере NGINX или NGINX Plus, чтобы сделать его содержимое доступным по любому протоколу:

server {     
    listen  80;     
    listen  443 ssl http2;     
# ... 
}

Это не подходит при использовании HSTS, поэтому в файле конфигурации WEB домена прописываем редирект на протакол HTTPS:

server {     
    listen 80 default_server;     
    listen [::]:80 default_server;     
    server_name _;     
    return 301 https://$host;    
# Либо 
  # return 301 https://$host$request_uri; 
} 
server {     
    listen 443 ssl http2;     
    server_name www.example.com;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; 
}

Укрепление HSTS

Клиент защищен от перехвата HTTP после того, как он увидел заголовок STS для соответствующего домена в течение объявленного периода максимального возраста.

Однако HSTS не является идеальным решением для захвата сеанса HTTP. Пользователи по-прежнему уязвимы для атаки, если они получают доступ к защищенному HSTS веб-сайту через HTTP, когда у них выполняются данные условия:

• Никогда раньше не посещал сайт
• Недавно переустановил свою операционную систему
• Недавно переустановил свой браузер
• Перешел на новый браузер
• Перешли на новое устройство (например, мобильный телефон)
• Удалил кэш браузера
• Не посещал сайт в последнее время, и время max-age прошло

Чтобы решить эту проблему, Google поддерживает “список предварительной загрузки HSTS” веб-доменов и поддоменов, которые используют HSTS и представили свои имена https://hstspreload.appspot.com/. Этот список доменов распространяется и жестко закодирован в основных веб-браузерах. Клиенты, обращающиеся к веб-доменам в этом списке, автоматически используют HTTPS и отказываются обращаться к сайту по протоколу HTTP.

Имейте в виду, что после установки заголовка STS или отправки доменов в список предварительной загрузки HSTS удалить его невозможно. Это одностороннее решение сделать ваши домены доступными через HTTPS.

Если вы планируете добавить заголовок STS в конфигурацию NGINX, сейчас также самое время рассмотреть возможность использования других HTTP‑заголовков, ориентированных на безопасность, таких как X-Frame-Options и X-XSS-Protection.

NGINX Plus имеет дополнительные функции для защиты вашего сайта от угроз безопасности и других проблем, таких как распределенные атаки типа “отказ в обслуживании” (DDoS).

[endtxt]

RSS

Распределенная атака типа “отказ в обслуживании” (DDoS) представляет собой попытку сделать службу, обычно веб‑сайт, недоступным путем бомбардировки его таким количеством трафика с нескольких машин, что сервер, предоставляющий службу, больше не может функционировать правильно из‑за исчерпания ресурсов.

Как правило, злоумышленник пытается насытить систему таким количеством подключений и запросов, что она больше не может принимать новый трафик или становится настолько медленной, что становится практически непригодной для использования.

Использование NGINX для борьбы с DDoS-атаками

NGINX имеет ряд особенностей, которые – в сочетании с характеристиками DDoS-атаки, могут сделать их важной частью решения по смягчению DDoS-атак.

Защита архитектуры NGINX по событиям

NGINX сконструирован так, чтобы он мог быть “амортизатором при ударе” DDOS на ваш сервер.

Новые запросы из сети не отвлекают NGINX от обработки текущих запросов, что означает, что NGINX имеет возможность применять методы, описанные ниже, которые защищают ваш сайт или приложение от атаки.

Ограничение скорости запросов в nginx

Можно ограничить скорость, с которой NGINX принимает входящие запросы, значением, типичным для реальных пользователей. Например: реальный пользователь, обращающийся к странице входа, может делать запрос только каждые 2 секунды. Исходя из этого настроим NGINX так, чтобы разрешить одному IP-адресу клиента пытаться войти в систему только каждые 2 секунды (эквивалентно 30 запросам в минуту):

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

server {
# ... 
     location /login.html {
         limit_req zone=one;
     }
}

• limit_req_zone – Директива настраивает вызываемую зону общей памяти для хранения состояния запросов для указанного ключа, в данном случае IP-адреса клиента ( $binary_remote_addr).
• limit_req – Директива в location блоке для /login.html ссылается на зону общей памяти.

Ограничение количества соединений

Можно ограничить число соединений, которые могут быть открыты одним IP-адресом клиента, снова значением, соответствующим реальным пользователям. Например, можно разрешить каждому IP-адресу клиента открывать не более 10 подключений к области /store вашего веб-сайта:

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {     
# ...     
    location /store/ {         
        limit_conn addr 10;        
    } 
}

• limit_conn_zone– Директива настраивает зону общей памяти с именем addr для хранения запросов на указанный ключ, в этом случае (как и в предыдущем примере) IP-адрес клиента,$binary_remote_addr. 
• limit_conn– Директива в locationблоке for /store ссылается на зону общей памяти и устанавливает максимум 10 соединений от каждого IP-адреса клиента.

Закрытие Медленных Соединений

Вы можете закрыть соединения, которые пишут данные слишком редко, что может представлять собой попытку держать соединения открытыми и таким образом, уменьшить способность сервера принимать новые соединения.

client_header_timeout           30s;
client_body_timeout             30s;

По умолчанию данный параметр равен 60 секундам

[endtxt]