Как сделать nginx безопасным

  • Tutorial


TL;DR: абсолютно устойчивых систем не существует, поэтому ответ — никак. Но можно значительно упростить себе жизнь с помощью Docker-контейнера bunkerized-nginx. О том, чем он отличается от стандартного образа nginx и что интересного умеет, поговорим под катом.

Сервер в бункере


Вообще у меня слово bunkerized применительно к серверу ассоциируется исключительно с CyberBunker, и здесь эта аналогия в принципе уместна. Французская команда Bunkerity разрабатывает готовые защищённые образы для nginx, mariadb, php и phpmyadmin, обещая защиту от проникновения, ботов и индексаторов, брутфорса и опасных файлов, как владельцы пиратского бункера когда-то гарантировали безопасность и анонимность.

image

Сканеры не видят сервер https://demo-nginx.bunkerity.com/, хотя он доступен в браузере

Реальные фичи


Помимо стандартных плюсов nginx'a в докере мы получаем:

  • Поддержку HTTPS с автоматическим продлением Let's Encrypt,
  • Актуальную веб-защиту: HTTP-заголовки безопасности, php.ini hardening, предотвращение утечек памяти и другое
  • Встроенный межсетевой экран Modsecurity с правилами OWASP Core Rule Set
  • Автоматическую блокировку подозрительных действий через fail2ban
  • Защиту от бот-атак — обязательная проверка по капче/кукам/кастомному js (аналог Attack mode в Cloudflare)
  • Блокировку луковичных соединений, прокси, по подозрительному/запрещённому юзер-агенту и даже по стране запроса
  • Автоматическую проверку IP в черном списке DNSBL
  • Защиту от брутфорса (лимит на запросы)
  • Обнаружение опасных/поврежденных файлов с помощью ClamAV
  • Компактную конфигурацию через переменные среды
  • Поддержку нестандартных архитектур вроде arm32v7

Что-то выглядит банально, что-то может показаться излишним (зачем мне пересобирать nginx, если я запускаю контейнер на x86_64?), но благодаря гибкой настройке почти всё можно настроить на свой вкус и под свои нужды.

Запуск


Установка

docker pull bunkerity/bunkerized-nginx

HTTP-сервер с настройками по умолчанию

docker run -p 80:80 -v /path/to/web/files:/www bunkerity/bunkerized-nginx

Файлы раздаются из каталога /www.

HTTPS-сервер с автоматическим управлением Let's Encrypt

docker run -p 80:80 -p 443:443 -v /path/to/web/files:/www -v /where/to/save/certificates:/etc/letsencrypt -e SERVER_NAME=www.yourdomain.com -e AUTO_LETS_ENCRYPT=yes -e REDIRECT_HTTP_TO_HTTPS=yes bunkerity/bunkerized-nginx

Сертификаты хранятся в каталоге /etc/letsencrypt directory. Можно запретить серверу слушать HTTP, добавив LISTEN_HTTP: no. Не забудьте настроить перенаправление, потому что Let's Encrypt нуждается в открытом 80 порту.

Здесь были использованы следующие переменные:

SERVER_NAMEFQDN (полное доменное имя) вашего сервера
AUTO_LETS_ENCRYPT — автоматически создаёт и обновляет сертификаты Let's Encrypt
REDIRECT_HTTP_TO_HTTPS — перенаправляет HTTP на HTTPS (кэп)

Работа в режиме обратного прокси

Собственно конфигурация обратного прокси ложится на пользователя:

  location / {
    if ($host = www.website1.com) {
      proxy_pass http://192.168.42.10$request_uri;
    }
  
    if ($host = www.website2.com) {
      proxy_pass http://192.168.42.11$request_uri;
    }
  }

Все файлы конфигурации (.conf) в каталоге /server-confs будут включены в серверный контекст. Достаточно просто примонтировать том с конфигами к контейнеру:

docker run -p 80:80 -e SERVER_NAME="www.website1.com www.website2.com" -e SERVE_FILES=no -e DISABLE_DEFAULT_SERVER=yes -v /path/to/server/conf:/server-confs bunkerity/bunkerized-nginx

Здесь:

SERVER_NAME — список валидных заголовков Host, посылаемых клиентом
SERVE_FILES — разрешает (yes) или запрещает (no) nginx раздавать файлы из /www
DISABLE_DEFAULT_SERVER — nginx не будет отвечать на запросы, у которых Host не будет находиться в списке SERVER_NAME
Здесь можно найти больше средств гибкой настройки

Работа за обратным прокси

docker run -p 80:80 -v /path/to/web/files:/www -e PROXY_REAL_IP=yes bunkerity/bunkerized-nginx

При включении PROXY_REAL_IP: yes активируется nginx модуль ngx_http_realip_module для получения реального IP клиента из-за прокси.

Обязательная антибот-проверка

docker run -p 80:80 -v /path/to/web/files:/www -e USE_ANTIBOT=captcha bunkerity/bunkerized-nginx

При USE_ANTIBOT: captcha все пользователи при заходе будут вынуждены проходить капчу. Также доступны варианты cookie, javascript, recaptcha. Доки здесь.

Ещё есть примеры в репозитории, здесь.

Заключение


bunkerized-nginx это удобный вариант для тех, кому нужно быстро запустить nginx и не париться в будущем о его безопасности, закрытии уязвимостей и конфиденциальности. Буквально в одну строчку можно запустить готовый контейнер и забыть про него. При этом, несмотря на простой старт, это всё ещё полноценный nginx с его огромнейшим функционалом, что позволяет максимально гибко всё настроить.



На правах рекламы


Эпичные серверы — это виртуальные серверы которые прекрасно подойдут для размещения разнообразных сайтов. Сумасшедшая производительность благодаря мощным процессорам семейства AMD EPYC и очень быстрым NVMe дискам Intel. Обязательно закажите!

VDSina.ru хостинг серверов
Серверы в Москве и Амстердаме

Похожие публикации

Комментарии 21

    +5

    Идея вообщем-то хорошая тем, что можно получить некое решение по безопасности "из коробки", но бесполезная.
    Перекидывать входядий траф в докер, а из докера в апп или в вебрут, который модет лежать где угодно — сомнительное удовольствие полное бесполезности.
    Особенно если хайлоад или стрим.
    Если хочется запарониться или усилить секурность, не нужно усложнять. Достаточно вынести реверс нгикс на отдельный впс (кстати не обязательно супермощный, достаточно 4 вцпу, 4гб памяти для обработки до 10м запросов в сутки — исходя из личного опыта).
    Либо ставить нгикс фронтом на сервер + докеры, где крутится апп или сайт.


    Как засекурить нгикс — полон интернет информации, начиная от всем известного стековерфлоу.
    Ксли кратко:
    1) ботов по user agent отправлять на 40x
    2) сканеров по регэкспам (think, cgi,setup, phpmy,dbadm,sysadm,mstohash,install, backup.tgz и тд) отправлять туда же + отдельно в лог, который отдавать fail2ban
    3) тупо забанить через blackhole все спам ip (списки спамовых черных ip можно найти в инете)
    4) гео бан, например весь CN или точечно по китайским подсетям
    5) limit rates на запросы и отдачу контента


    Вся инфа по настройке находится в гугле, в целом все не так сложно настроить самостоятельно.

      +3
      1) ботов по user agent отправлять на 40x

      Люди деньги на раскрутку проекта тратят, гуглю и яндексу серьезные суммы заносят, а вы предлагаете банить роботов.
      Если сайт магазин то банить ботов плохая идея.
        +4

        Мне вот интересен ход мыслей тех, кто «банит ботов по UA». Если бот не скрывает от вас того, что он бот, то он и robots.txt уважает — правильнее ему там всё сказать.

      0
      Про защиту от ботов, как у CloudFlare, было бы интересно почитать в виде отдельной статьи.
        0
        Защита CloudFlare от DDOS «подождите 5 сек сейчас все будет» обходится (потому что и рассчитана от DDOS).

        Если на уровне докажите что не робот, это эффективнее, но раздражает.
        +1
        А можно попросить Вас HowTo написать как поставить Linux-Ngnix-MariaDB-PHP7- на последней версии Debian 10 + защита сервера+ кэширование + настройка бэкапов и восстановление из них + HTTPS LetsENCript + HTTP/2 (и всё это желательно с комментариями что делаем, зачем и почему) — в розницу это всё описано, но как правило для разных версий ПО + каждый админ всё настраивает немного по своему, получатся разнобой.
        Есть некоторое количество начинающих админов которым VPS нужна для форума, СMS и т.п. квалификации нормально настроить всё это хозяйство нет :(
          0
          Хостинг для вас уже сделал такую услугу, просто приобретите работающий проект на вордпресе или что там у вас.
            0
            Зачем минусовать, ведь цены даже у владельцев блога не самые высокие и там всё есть. А каждые пол года писать однотипные статьи, практически превратится в желтуху.
              0
              Интересно, когда vdsina успел превратиться в ruvds…
                0
                Посылаю голову пеплом, мой косяк, простите.
            0
            начинающие админы никогда не познают дзен не пройдя путь самурая.
            вы просите не научить, а тупо под ключ настроить конкретное решение, заточенное под вас.
              +1
              Есть некоторое количество начинающих админов которым VPS нужна для форума, СMS и т.п. квалификации нормально настроить всё это хозяйство нет :(


              Для таких админов давным давно существует очень распространенная услуга виртуального хостинга (не путать с виртуальным сервером). Это услуга стала широко распространенной даже раньше, чем VDS.
              +1
              И тут у ваннаби сисадмина подламывают сам докер
                +2
                Сделали бы приписку что ли, что это только тупой пример и так делать не надо
                if ($host = www.website1.com) {
                      proxy_pass http://192.168.42.10$request_uri;
                }
                


                If is Evil
                  0
                  Сама по себе тема достаточно интересная, но гифка в полторы минуты и if-ы сильно портят впечатление о статье.
                    +1
                    Пользуемся на проекте 3 месяца. Почти каждый пуш автора bunkerized nginx в докер регистри ломает обратную совместимость, к сожалению пока сыровато, чтобы использовать в серьезных проектах. Версионирования нет, поэтому единственная возможность — форкнуть рабочую версию в свой регистри и тянуть стабильный образ оттуда.
                      0
                      а можно не скромный вопрос, зачем там внутри докера QEMU?
                        0

                        Он вроде через него виртуализацию делает, по крайней мере в качестве фолбэка в osx

                          0
                          Он вроде через него виртуализацию делает, по крайней мере в качестве фолбэка в osx


                          В Linux докер ранее всегда был всего лишь контейнером. Какая виртуализация, о чем это вы?

                          А в OSX ранее всегда был именно виртуальной машиной. И под Windows тоже. Точнее Linux-ом в виртуализации внутри которого уже запускался в контейнере Докер как в Linux.

                          Что то изменилось в последних версиях Докера?
                            0

                            Понятия не имею. Я видел его только с виртуалкой.
                            И тут я понял что вопрос у вас получился маленько двоякий — внутри докера в смысле внутри контейнера с nginx или в поставке с самим докером/исходниках докера.

                              0
                              Понятия не имею. Я видел его только с виртуалкой.


                              Docker изначально разработан для эксплуатации на серверах Linux.
                              И там он запускается в легковесных контейнерах. Которые куда как легче полноценных виртуальных машин.

                              А под Windows и MacOSX приходится запускать Docker в виртуалках вынужденно и только для целей отладки. Для «боевой» эксплуатации Docker в этих операционных системах не предназначен.

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

                      Самое читаемое