Пользователь
0,0
рейтинг
18 марта 2013 в 19:09

Разработка → Готовим Nginx к PCI Compliance

Всем привет.

Cегодня наша цель — подготовка Nginx к прохождению PCI Compliance. Если конкретнее, то SSL протоколов и шифрования. Ну или просто поднять безопастность наших SSL соединений и избавиться от уязвимостей.

Всего то и нужно, что привести часть конфига вот в такой вид:)

        ssl_certificate       /etc/nginx/card.pem;
        ssl_certificate_key  /etc/nginx/card.key;
        ssl_ciphers      RC4:HIGH:!aNULL:!MD5:!kEDH;
        ssl_session_cache shared:SSL:10m;
        ssl_prefer_server_ciphers on;


Однако добавлю немного подробностей, рассмотрим по пунктам.

Если у вас последнии версии nginx, то скорее всего по умолчанию будут «стойкие» шифры. Но все же, мы немного поменяем дефолтные значения:

ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;


Это делаем, для того, что бы шифрам с CBC-режимом предпочитался RC4-SHA, так как они подвережены уязвимостям.

Посмотреть полный лист шифров можно командой:

openssl ciphers


Исключаем возможность BEAST-атаки CVE-2011-3389:

ssl_prefer_server_ciphers on;


Подключаем кеш SSL сессий, это избавит нас от постоянных SSL handshake при повторных соединениях, и добавит несколько баллов в конечном тесте. В 1 мегабайт кэша помещается около 4000 сессий.

ssl_session_cache shared:SSL:10m;


Для версий 0.7.64, 0.8.18 и более ранних, следует добавить, что бы отключить SSLv2:

ssl_protocols           SSLv3 TLSv1;


В версиях 0.7.65, 0.8.19 и более поздних: протоколами SSL по умолчанию являются SSLv3, TLSv1, TLSv1.1 и TLSv1.2, что нас вполне устраивает.

Идем на тест от SSL Labs и получаем «Grade А» и «PCI Compliance Yes»:

www.ssllabs.com/ssltest

Полезные ссылки:

Nginx.org Настройка HTTPS-серверов
SSL/TLS Deployment Best Practices
SSL Server Rating Guide

UPD:
В связи с найденой уязвимостью RC4 (http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html), спасибо alist, советую обновить OpenSSL до версии 1.0.1, где поддерживаются GCM и TLS 1.2. Пока это все что мы можем сделать со своей стороны и ждать действий со стороны браузеров.
Antonio @astlock
карма
46,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (41)

  • –11
    Мне кажется, или подобных статей сотни?
    • +4
      Значит показалось.
  • 0
    Исключаем возможность BEAST-атаки CVE-2011-3389:

    ssl_prefer_server_ciphers on;
    



    А мне вот что то не помогло. Пишет что BEAST attack Vulnerable INSECURE
    • 0
      ssl_ciphers такие же как в статье?
      • 0
        Да.

        Добавлю, что ssl_session_cache shared:SSL:10m; следует указывать в http секции. ссылка в nginx форума
        • 0
          Прошу прощения, но релоад вы не забыли сделать?
          Добавлю, что ssl_session_cache shared:SSL:10m; следует указывать в http секции. ссылка в nginx форума

          Можно, но не обязательно.
          • 0
            Прошу прощения, но релоад вы не забыли сделать?

            Я его полностью перезапустил.
            Можно, но не обязательно.

            У меня только после этого Session resumption проставилось в Yes.
            • +2
              Обновил nginx c 1.2.2 до 1.2.7 и все встало на свои места.
    • 0
      так ciphers'ы ограничили RC4ми?
  • 0
    Я бы ещё добавил:

    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    • 0
      Немного исправил эту часть статьи, спасибо.
    • 0
      А протоколы не в обратном порядке должны идти — от самого предпочитаемого?
      • 0
        В данном случае порядок в конфиге неважен. Это просто опция, которая передаётся в OpenSSL.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        На том же сайте проверки некоторые смельчаки вообще оставили TLSv1.2 без вариантов.
        Еще одна хорошая причина начинать уходить от IE6.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      HSTS вообще важная штука. Если делать редирект http->https, то HSTS очень желательно ставить. Но у вас max-age 3600, я бы рекомендовал что-нибудь подольше, 31536000, например.
  • +3
    Это делаем, для того, что бы шифрам с CBC-режимом предпочитался RC4-SHA, так как они подвережены уязвимостям.


    На самом деле RC4 тоже уязвим из-за того, как он шифрует начало потока, где среди недеров в том числе передаются куки. Пока что в реальных условиях атака трудно воспроизводима, но может проводиться крупными организациями. BEAST и Lucky 13 требуют какого-то хитрого джаваскрипта, а эта атака основана на статистике и «просто» требует несколько миллионов HTTPS-запросов.

    Есть workaround — в респонсе сервера передавать HTTP-хедеры в разном порядке и добавлять левае заголовки случайной длинны, чтобы положение куки в теле запроса менялось. Для AJAX-запросов это можно делать на стороне браузера, а вот для простых запросов тут уже нужно, чтобы браузер сам этим занимался. Пока, конечно, ни один браузер такого не делает, но и атака тоже пока в стадии «практически трудно выполнима».

  • 0
    Хмм, действительно помогло. Большое спасибо!

    Может стоит это вынести в дефолтный конфиг nginx?
  • 0
    а как насчёт совместимости со старыми браузерами, ваши настройки на это сильно влияют?
    • 0
      Смотря на сколько старые. Тут надо для себя решить минимальные версии, которые надо поддерживать.
  • 0
    Это только часть теста на PCI…
    Как-то сервер клиента тестили, насколько я помню там докучи еще всего.
    • 0
      Остальное как правило — это уязвимые формы регистрации, инъекции в них же, открытые порты на веб сервере и т.д. Но все таки это уже «зона отвественности» не Nginx :)
  • 0
    Спасибо, прыгнул с F на A :)
    Единственное что смущает в отчете, дык это следующая строчка:
    Chain issues Incorrect order, Contains anchor

    Никто не в курсе что за беда? Вроде тут описано, но прочитав ничего не понял.
    • 0
      Судя по вашей ссылке — в цепочке, которую передаёт сервер клиенту присутствует коревой (самоподписный ?) сертификат, что не обязательно, так клиент и так должен был его принять.
    • +1
      Это частый случай и весьма нехорошо, т.к. некоторые браузеры без правильной цепочки сертификатов могут откзаться с вами работать.
      • 0
        Дык а в чем-то проблема? Что мне нужно пофиксить, что бы эта ошибка ушла.
        • 0
          Если у вас валидный сертификат, а не самоподписанный, то следует проверить правильную последовательность цепочки сертификатов.

          http://nginx.org/ru/docs/http/configuring_https_servers.html#chains
          • 0
            Проверил тестом от sslshopper. Цепочка сертификатов следующая:
            1. Сертификат домена — Common name: *.domain.com
            2. Корневой сертификат startssl — Common name: StartCom Certification Authority
            3. Class 2 сертификат startssl — Common name: StartCom Class 2 Primary Intermediate Server CA

            Вроде ж все правильно…
            • +1
              Нашел тут более подробное и понятное объяснение. Оказывается нужно что бы был следующий порядок:
              1. Сертификат домена — Common name: *.domain.com
              2. Class 2 сертификат startssl — Common name: StartCom Class 2 Primary Intermediate Server CA
              3. Корневой сертификат startssl — Common name: StartCom Certification Authority
              • 0
                Так в большинстве случаев и бывает. домена-промежуточный-корневой.
        • 0
          Посмотрите в более простом чекере, как это выглядит у других например.

          http://www.sslshopper.com/ssl-checker.html#hostname=paypal.com
  • 0
    Одно использование стойких шифров и ссл протоколов это не полное PCI Compliance веб сервера.
    Там много пунктов которые надо выполнить, что б быть комплайант
  • 0
    Забавно, у меня было 100/85/80/90 (A), но сейчас подтяну, спасибо.
  • 0
    что то у меня только Read timed out возвращает :(
  • 0
    Внезапно!
    RC4 Yes WEAK (more info)

    RC4 in TLS is Broken: Now What?
    • 0
      Это то, о чем писал выше alist. Сделал небольшой апдейт.
  • 0
    Сработало. Спасибо!

    А как у этого метода в плане совместимости со старыми браузерами? Как минимум интересует IE7
    • 0
      Не тестировал в виста, но под ХР работает.
    • 0
      IE7 это поддерживает без проблем.
      С IE6 там некоторые сложности с TLSv1 только.
  • 0
    Вот чему-чему, а RC4 я свою бы безопасность никогда бы не доверил. Жаль, пока что выбирать особо не из чего, а новые победители estream не включены в стандарт (

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