TOC

Как обезопасить Nginx в Ubuntu 14.04

Nginx - это очень безопасный и надежный веб-сервер даже с настройками по умолчанию. Тем не менее, есть много способов обеспечить безопасность Nginx.

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

Предпосылки

Прежде чем следовать этому руководству, убедитесь, что вы выполнили следующие предварительные условия:

Если не указано иное, все команды, которым требуются привилегии root в этом учебном пособии, должны запускаться как пользователь без полномочий root с привилегиями sudo.

Шаг 1 - Обновление всего программного обеспечения

Обновление программного обеспечения до последней версии - это отличный первый шаг в защите всей системы, а не только Nginx.

Предупреждение: перед обновлением всех пакетов в вашей системе обязательно определите, не вызовет ли это проблемы с чем-либо, работающим в вашей системе, кроме Nginx. Хорошей идеей будет сделать резервную копию всей системы перед выполнением операции, которая затрагивает столько пакетов одновременно. Вы можете вернуться к резервной копии, если возникнут проблемы после обновления всех пакетов. Чтобы обновить список пакетов репозитория и затем все установленные на данный момент пакеты, управляемые с помощью + apt-get + на вашем сервере Ubuntu, выполните команды:

sudo apt-get update && sudo apt-get upgrade

Кроме того, вы можете просто обновить Nginx до последней версии в хранилище Ubuntu. Это обновит пакет Nginx и все необходимые зависимости:

sudo apt-get upgrade nginx

Шаг 2 - Предотвращение раскрытия информации

Чтобы начать укреплять свой веб-сервер Nginx, давайте начнем с ограничения информации, которую он раскрывает. Ценная информация просачивается на каждом уровне от заголовков сервера HTTP до отчетов об ошибках приложения.

Итак, начнем с заголовков HTTP. По умолчанию Nginx показывает свое имя и версию в заголовках HTTP. Вы можете проверить эту информацию с помощью + curl + следующим образом:

curl -I http://localhost

Вывод должен выглядеть так:

Output of curl -I http://localhostHTTP/1.1 200 OK

...

Как вы можете видеть, версия Nginx и название операционной системы можно увидеть в приведенном выше выводе. Это не обязательно серьезная проблема, а скорее часть головоломки, которую злоумышленник попытается решить, чтобы скомпрометировать ваш сервер Nginx. Вот почему мы будем скрывать эту информацию, открыв основной файл конфигурации Nginx + / etc / nginx / nginx.conf + с помощью nano:

sudo nano /etc/nginx/nginx.conf

Затем внутри части конфигурации + http + добавьте строку + server_tokens off; + следующим образом:

/etc/nginx/nginx.conf

http {

       ##
       # Basic Settings
       ##

...

После этого сохраните и выйдите из файла и перезагрузите Nginx, чтобы изменения вступили в силу:

sudo service nginx reload

Теперь, если вы попробуете снова ту же команду curl:

curl -I http://localhost

Вы увидите меньше информации:

Output of curl -I http://localhostHTTP/1.1 200 OK

...

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

Помимо заголовка + Server, есть еще один заголовок с конфиденциальной информацией -` + X-Powered-By`. Этот заголовок обычно показывает версию PHP, Tomcat или любой серверный движок за Nginx. Если вы запустите Nginx с PHP, вывод + curl + будет выглядеть так:

Output of curl -I http://localhost on nginx with phpHTTP/1.1 200 OK
Server: nginx
...

...

Вышеприведенный заголовок + X-Powered-By + показывает, что сервером является Ubuntu 14 с PHP версии 5.5.9. Очень важно скрыть эту информацию от заголовка + X-Powered-By. Вы не можете сделать это в Nginx, но вместо этого вы должны найти соответствующую опцию в бэкэнд-движке. Например, в случае PHP вы должны установить опцию + expose_php = Off + в основном файле конфигурации + php.ini +. По умолчанию эта опция установлена ​​на + On +.

Следующее, что нужно сделать, - это изменить страницы ошибок 4xx (на стороне клиента), информацию о которых может использовать злоумышленник. Обычно это страницы ошибок + Unauthorized 401 + и + Forbidden 403 +. Если вы не решаете проблему, обычно нет необходимости показывать эти ошибки постоянным посетителям. Если вам нужно знать об этих ошибках, вы все равно сможете найти их в журнале ошибок Nginx (+ / var / log / nginx / error.log +).

Чтобы изменить эти две страницы ошибок, откройте файл конфигурации для своего блока сервера, например, файл по умолчанию:

sudo nano /etc/nginx/sites-enabled/default

Внутри главного сервера + server + в части конфигурации укажите:

/ И т.д. / Nginx / сайты с поддержкой / по умолчанию

server {
...

...

После сохранения изменений в файле обязательно перезагрузите Nginx, чтобы он вступил в силу с помощью команды:

sudo service nginx reload

Приведенные выше советы дают вам представление о том, как предотвратить раскрытие информации - показать как можно меньше ненужного веб-контента. Вы должны скрывать служебную и отладочную информацию не только в Nginx, но и в бэкэнд-движках (PHP, Tomcat и т. Д.) И, конечно же, в веб-приложениях.

Шаг 2 - Настройка SSL

Запуск безопасного протокола HTTPS с SSL на Nginx является обязательным для любого сайта, который обрабатывает конфиденциальную информацию, такую ​​как учетные данные пользователя, личные данные и т. Д. SSL - это единственный способ убедиться, что независимо от того, где находятся пользователи вашего сайта и какое интернет-соединение они используют, информация, которую они получают и отправляют, будет защищена.

Статья Как создать SSL-сертификат на Nginx для Ubuntu 14.04 объясняет, как легко настроить бесплатный SSL с настройкой HTTPS по умолчанию. Хотя эта статья является хорошим началом, она не сможет эффективно защитить ваши данные. В настоящее время настройки и алгоритмы SSL по умолчанию недостаточно сильны, чтобы не дать злоумышленнику расшифровать ваш трафик.

Поэтому мы настроим SSL-сертификат для Nginx с более надежными алгоритмами и настройками шифрования. Это обеспечит более высокий уровень защиты ваших данных, и ваша служба HTTPS будет соответствовать самым высоким стандартам и практикам безопасности.

Начнем с создания каталога для наших SSL-сертификатов с помощью команды:

sudo mkdir /etc/nginx/ssl/

Для нашего SSL нам понадобится сертификат с надежным алгоритмом подписи SHA256. Для целей тестирования или непроизводственной среды вы можете использовать самозаверяющий сертификат и игнорировать предупреждения SSL. Давайте создадим его с помощью команды:

sudo openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

Эта команда задаст вам несколько простых вопросов о деталях вашего сайта и бизнеса. После этого он создаст 2048-битный RSA-ключ в файле + / etc / nginx / ssl / nginx.key + и сертификат SHA256 в файле + / etc / nginx / ssl / nginx.crt +.

Затем вам нужно сгенерировать более сильные 4096-битные параметры DH. Приготовьтесь подождать некоторое время, в зависимости от вашей капли, это может занять до 30 минут. Запустите команду:

sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

Теперь вы можете настроить часть SSL вашего блока сервера. В качестве примера, давайте настроим блок сервера по умолчанию. Откройте его файл конфигурации для редактирования с помощью nano:

sudo nano /etc/nginx/sites-enabled/default

В этом файле отредактируйте часть конфигурации сервера, добавив часть SSL после директивы + server_name + следующим образом:

/ И т.д. / Nginx / сайты с поддержкой / по умолчанию

server {
...
      server_name localhost;










...

Вот какие инструкции мы указали с указанными выше директивами:

  • + listen + - включить прослушиватель SSL на порту 443, т.е. порт HTTPS.

  • + ssl_protocols + - включить только эти три, рассматриваемые в настоящее время безопасные протоколы - + TLSv1 TLSv1.1 TLSv1.2 +.

  • + ssl_ciphers + - включить только эти безопасные шифры SSL: + EECDH + AESGCM: EDH + AESGCM: AES256 + EECDH: AES256 + EDH +

  • + ssl_prefer_server_ciphers + - убедитесь, что клиент уважает настройки шифров сервера.

  • + ssl_dhparam + - использовать пользовательские сильные параметры DH, которые мы сгенерировали ранее.

  • + ssl_certificate + - используйте наш самозаверяющий SSL-сертификат. Обязательно измените его, если вы используете другой сертификат.

  • + ssl_certificate_key + - используйте наш закрытый ключ SSL, который мы сгенерировали ранее.

Чтобы указанные выше настройки вступили в силу, вам придется снова перезагрузить nginx с помощью команды:

sudo service nginx reload

Для проверки вашей новой конфигурации SSL лучше всего использовать внешний инструмент, например, предоставленный SSL Labs. Там вы должны игнорировать предупреждение о том, что SSL не является доверенным. Это естественно, потому что это самозаверяющий сертификат. Обратите внимание, что этот сайт будет проверять только сайты с зарегистрированным доменным именем. Вы не можете проверить соединение SSL только с IP-адресом вашего Droplet.

Общий результат должен быть «Т», как для «Тестирования», но по сути это А (максимально возможный), и он должен сказать «», если вопросы доверия игнорируются: «», например:

изображение: https: //assets.digitalocean.com/articles/nginx_security_1404/ssltest.png [Проверка SSL]

Позже вы, вероятно, захотите удалить предупреждение SSL и сделать тест SSL чистым «А». Одним из вариантов является использование * Let’s Encrypt *, как описано в статье https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14- 04 [Как защитить Nginx с помощью Let’s Encrypt в Ubuntu 14.04]. Он бесплатный, позволяет указать размер ключа RSA до 4096 и не выдает предупреждение о самоподписании. В противном случае вы можете выбрать любого из коммерческих провайдеров SSL. Когда вы выбираете один, просто убедитесь, что вы выбираете сертификат SHA256.

Шаг 3 - Ограничение доступа по IP

Аутентификация по паролю не всегда достаточна для обеспечения безопасности чувствительных областей вашего сайта, таких как панели управления сайтом, phpmyadmin и т. Д. Иногда злоумышленники используют слабые пароли или программные уязвимости в таких областях для получения несанкционированного доступа. Вот почему настоятельно рекомендуется добавить дополнительные ограничения IP-адресов, если вы можете определить IP-адреса законных пользователей.

Например, если у вас есть сайт WordPress и его область администрирования находится в + / wp-admin / +, вам следует ограничить доступ к нему только вашим IP-адресом или IP-адресами всех администраторов. Для этого откройте соответствующий блок сервера - блок сервера по умолчанию для Nginx это + / etc / nginx / sites-enabled / default +:

sudo nano /etc/nginx/sites-enabled/default

Внутри части конфигурации + server + добавьте:

/ И т.д. / Nginx / сайты с поддержкой / по умолчанию

server {
...
   location /wp-admin/ {
       allow /24;
    allow /24;
       deny  all;
}
...
...

Пожалуйста, не забудьте заменить + 192.168.1.1 + и + 10.0.0.1 + на ваши IP-адреса. Точно так же вы можете разрешить доступ для других IP-адресов или даже сетей, изменив маску сети (+ / 24 +).

Чтобы такие настройки вступили в силу, вам придется перезагрузить Nginx снова командой:

sudo service nginx reload

Теперь, если вы попытаетесь получить доступ к части вашего сайта + / wp-admin / + через браузер, выходящий за пределы допустимого диапазона IP-адресов, вы получите сообщение об ошибке. Эта ошибка будет 403 Запрещена (если вы не изменили эту ошибку на 404 Не найдено, как описано выше). В то же время вы увидите истинный код ошибки в журнале ошибок с помощью команды:

sudo tail /var/log/nginx/error.log

Ошибка + accessidden + будет выглядеть так:

Output of sudo tail -f /var/log/nginx/error.log...
2016/01/02 04:16:12 [error] 4767#0: *13  by rule, client: X.X.X.X, server: localhost, request: "GET /wp-admin/ HTTP/1.1", host: "Y.Y.Y.Y"
...

Комбинация применения нескольких подходов к безопасности, таких как изменение страницы с ошибками и ограничение доступа по IP, показывает совокупный эффект усиления Nginx. Согласно примеру, вместо обычной страницы администратора WordPress, злоумышленники и используемые ими автоматизированные инструменты увидят страницу 404 не найдена. Это сбивает с толку и может отговорить их от попыток использовать другие подходы к компрометации вашего WordPress.

[[step-4-- performing-a-security-audit]] === Шаг 4 - Выполнение аудита безопасности

Всегда полезно проводить проверку безопасности независимо от вашего собственного мнения. Для этого вы можете использовать инструмент аудита безопасности, который сканирует веб-уязвимости. Есть много таких инструментов, в том числе коммерческих, и для начала вы можете использовать wapiti, который является бесплатным и открытым исходным кодом. В Wapiti могут отсутствовать некоторые функции более продвинутых инструментов, но это даст вам представление о том, что такое аудит безопасности.

Вы можете установить wapiti на Ubuntu через apt:

sudo apt-get install wapiti

Затем начните сканирование вашего сайта с помощью wapiti с помощью команды:

wapiti http:// -n 10 -b folder

Обязательно замените + example.org + на имя вашего сайта. Мы предоставили команде два дополнительных аргумента. Первый + -n 10 + ограничивает количество URL с одинаковым шаблоном до 10, так что бесконечные циклы предотвращаются. Второй аргумент + -b folder + устанавливает область сканирования только для данного домена.

После того как сканирование завершится, вы получите результаты в каталоге с именем + generate_report + внутри каталога, из которого вы запустили сканирование. Для лучшего просмотра загрузите этот каталог на локальный компьютер и откройте файл + index.html с помощью веб-браузера.

Внутри отчета вы увидите уязвимости, отсортированные по 10 различным категориям: инъекция SQL, слепая инъекция SQL, обработка файлов, межсайтовый скриптинг, CRLF, выполнение команд, потребление ресурсов, обход Htaccess, резервный файл и потенциально опасный файл.

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

изображение: https: //assets.digitalocean.com/articles/nginx_security_1404/wapiti_report.png [Wapiti Report]

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

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

[[step-5-- taking-additional-security-measures]] === Шаг 5 - Принятие дополнительных мер безопасности

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

Naxsi - это брандмауэр веб-приложений для Nginx. Он защищает вас от известных и неизвестных веб-уязвимостей с помощью компиляции вредоносных сигнатур.

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

Fail2ban - отличный инструмент для поднятия веб-безопасности на новый уровень и проактивной защиты вашего сервера nginx. До сих пор мы ограничивали пользователей в поиске определенной информации и доступе к частям нашего сайта. С помощью fail2ban вы можете дополнительно блокировать злоумышленников на определенные периоды времени, когда вы обнаружите, что они выполняют вредоносную деятельность.

Мониторинг важен для безопасности, и Monit - отличный инструмент для этой цели с хорошей поддержкой Nginx. Журналы не только показывают следы злонамеренных действий, но также показывают скачки загрузки процессора и использования памяти.

В этой статье особое внимание обратите на Шаг 5 - Мониторинг логов на наличие ошибок и ключевых слов. Там вы можете настроить пользовательские оповещения, которые будут отправляться при событиях безопасности, например, когда кто-то получает доступ или пытается получить доступ к конфиденциальным частям вашего сайта (-ов).

Наличие брандмауэра очень важно для безопасности вашего nginx и вашей капли в целом. Убедитесь, что вы добавляете порт https (tcp 443) к разрешенным входящим соединениям помимо стандартного порта http (tcp 80).

Средство проверки целостности файлов и каталогов, такое как AIDE, оповещает об изменениях в файлах и каталогах. Это особенно удобно для веб-файлов, потому что вы должны знать, когда части вашего сайта изменяются и добавляются новые файлы / каталоги. Чтобы узнать больше об AIDE, вы можете начать со статьи.

Приведенная выше статья немного устарела и специально не написана для Ubuntu. Тем не менее, вы должны иметь возможность легко адаптировать его и применять для Ubuntu 14.04. При настройке AIDE или другого аналогичного инструмента обязательно исключите из своего мониторинга веб-журналы и временные файлы, такие как веб-кеш.

Заключение

После прочтения этой статьи вы должны более уверенно относиться к безопасности Nginx. Обязательно соблюдайте баланс между функциональностью и безопасностью, чтобы у вас было спокойствие, что ваша веб-среда работает так, как задумано, и в то же время безопасна. Также имейте в виду, что защита Nginx - это постоянная задача, требующая регулярного обновления, перенастройки, сканирования и т. Д.

Related