01.02.2017 10:39
lukasafonov 16 8000 Источник

Практически каждый сайт в интернете был атакован злоумышленниками. Большая часть часть атак завершилась успешно — злоумышленники смогли скомпрометировать веб-приложение, получить доступ к серверу или базе данных. В этой статье я расскажу о механизме защиты сайтов от хакерских атак — Web Application Firewall.

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

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

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

  • отслеживают bugtraq летны о наличии уязвимостей;
  • посещают ресурсы, связанные с веб-безопасностью;
  • делятся или обмениваются приватной информацией об уязвимостях;
  • проводят собственные изыскания по изучению кода приложений для выявления уязвимостей.

У зломышленников также существует «окно возможности взлома» — время от публикации уязвимости до исправления разработчиками и внедрения патча на веб-приложении. Например уязвимость в компоненте Apache Struts2 позволила злоумышленникам скпопрометировать множество сайтов. Даже при наличии патча не всегда есть возможность его моментального развертывания на «боевых серверах».

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

Уязвимости


Если взять мировую статистику часто используемых CMS, то порядок будет следующим:

  • WordPress;
  • Joomla!;
  • Magento;
  • Drupal;
  • vBulletin;
  • ModX.

Если взять статистику уязвимостей, то видно, что уязвимости в этих CMS или их компонентах находят каждую неделю, более того, критичные уязвимости самих CMS обнаруживают приблизительно раз в 2-3 месяца.

Пример недавних уязвимоcтей:

  • 30.01.17 В WordPress пропатчены три уязвимости, в том числе возможности для межсайтового скриптинга и внедрения SQL-кода. Релиз 4.7.2
  • 31.10.16 В Joomla, начиная с версии 3.4.4 и заканчивая версией 3.6.3, обнаружена критическая уязвимость, позволяющая обходить запрет на регистрацию пользователей на сайте и повышать группу доступа зарегистрированных пользователей.
  • 26.01.17 В Magento устранено 20 уязвимостей, включая критические.

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

Web Application Firewall


Web Application Firewall — защитный экран уровня приложений, предназначенный для выявления и блокирования современных атак на веб-приложения, в том числе и с использованием уязвимостей нулевого дня. Такой защитный механизм позволяет блокировать атаки категории OWASP TOP 10, их совокупности и комбинации.

Если для десктопных и серверных систем хорошим тоном считается использование защитных программных средств (антивирус, фаервол и т.д.), то для веб-приложений такая картина не наблюдается вовсе. Только в последнее время наблюдается тенденция внедрения таких защитных средств, например указание в 3.2 редакции PCI DSS:
PCI DSS compliance: Web application firewalls (WAFs)
Web application firewalls (WAFs) are one option for those seeking compliance with requirement 6.6 of the PCI DSS.

Каким образом средства Web Application Firewall позволяют выявлять и блокировать атаки?
В первую очередь это подход к проектированию защитного средства: от составления математической модели угрозы до проверки методов обхода защитных средств при наличии той или иной уязвимости.

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

Cистематическое обновление базы сигнатур


База сигнатур так защитных средств агрегируется из нескольких источников. Например, для Nemesida WAF используются следующие источники:

  • атаки на защищаемые веб-приложения клиентов с общим трафиком: 300-800 Mbps;
  • атаки на инфраструктуру Pentestit;
  • атаки на специализированные лаборатории тестирования на проникновение «Test lab» с «чистым» трафиком атак до 30 Mbps;
  • собственные исследования;
  • специализированные ресурсы и security-рассылки, изучение исследований;
  • база атак на веб-приложения отдела анализа защищенности Pentestit (в 8 из 10 случаев аудита безопасности сайтов обнаружены уязвимости со статусом «критичный») ;
  • а также машинное обучение, позволяющее выявлять аномалии в поведении пользователей сайта.

В качестве примера работы Web Application Firewall предлагаю всем желающим ознакомится с видеозаписью вебинара:

Поделиться с друзьями
-->

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


  1. Loki3000
    01.02.2017 14:51
    #10047624
    +1

    Что-то я не понял, откуда будут браться сигнатуры для уязвимостей нулевого дня? И зачем эта база сигнатур вообще нужна, если предположить что на приложение регулярно накатываются апдейты?


    1. Alexsandr_SE
      01.02.2017 15:47
      #10047710

      Откуда сигнатура хороший вопрос.
      А апдейты частенько выкатывают спустя заметное время после нахождения уязвимости. т.е. это не панацея.


    1. LukaSafonov
      01.02.2017 15:49
      #10047718
      +2

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


  1. Asen
    02.02.2017 05:49
    #10048768
    -5

    Судя по видео, рассказывающем по всей видимости о фичах waf'a(33-35 минуты), весь machine learning «детектов» заключается в парочке if'ов…


  1. selivanov_pavel
    02.02.2017 13:11
    #10049386

    Для работы с облачным WAF надо отдавать им свой приватный SSL-ключ, некоторые стандарты безопасности типа PCI DSS это запрещают. Плюс в случае ложных срабатываний нельзя поправить что-то самому, а нужно ждать, пока это починит сторонний подрядчик.

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

    Есть интересная софтина naxsi, собирается как модуль nginx: https://github.com/nbs-system/naxsi Использует альтернативный подход — сканирует все части запроса(URL, GET и POST-переменные, хедеры, куки) на наличие любых спецсимволов, которые можно использовать в SQL или XSS. С учётом возможного двойного кодирования. Все правила для исключений прописываются явно: в таких-то URL в такой-то GET-переменной могут встречаться двойные кавычки. Преимущество такого подхода в том, что он работает одинаково хорошо и для известных, и для неизвестных атак. И гораздо более гуманен в плане потребляемых ресурсов.

    Запускаем в обучающем режиме на пару дней, парсим лог и делаем правила. Потом иногда просматриваем лог заблокированных запросов и добавляем новые правила, если требуется. Имеет порог вхождения и требует периодического обслуживания, но работает в целом очень неплохо.


    1. LukaSafonov
      02.02.2017 14:19
      #10049574
      +4

      Для веб-приложений, подпадающих под требования PCI DSS разрабатывается standalone версия NWAF. Обычно такие компании имеют собственный штат специалистов, способных обслуживать сложные системы.

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


    1. rodionovs
      02.02.2017 14:30
      #10049616
      +4

      В рамках задач по улучшению наших продуктов осуществляется анализ существующих как платных, так и бесплатных решений для выявления «лучших практик». Вы немного ошибаетесь, Naxsi не является несигнатурным WAF и для определения атаки использует сигнатуры атак, так же, как и ModSecurity. В статье нашего коллеги можно ознакомиться с механизмом работы Naxsi, с дефолтной и кастомной базой сигнатур — ссылка

      Если говорить об облачном NemesidaWAF, то при трафике в 250-300 Mbps загрузка сервера с CPU «Intel® Xeon® CPU E3-1225 V2 @ 3.20GHz» составляет менее 1 LA на 4 рабочих ядра.


      1. selivanov_pavel
        02.02.2017 15:05
        #10049712

        В Naxsi конечно можно сделать руками сигнатуру под конкретную атаку. Есть даже сборки таких правил: https://bitbucket.org/lazy_dogtown/doxi-rules Но правила в naxsi_core.rules выглядят так:


        MainRule "str:\"" "msg:double quote" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:8,$XSS:8" id:1001;
MainRule "str:|" "msg:mysql keyword (|)"  "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:8" id:1005;
MainRule "str:;" "msg:semicolon" "mz:BODY|URL|ARGS" "s:$SQL:4,$XSS:8" id:1008;
MainRule "str:=" "msg:equal sign in var, probable sql/xss" "mz:ARGS|BODY" "s:$SQL:2" id:1009;
MainRule "str:'" "msg:simple quote" "mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie" "s:$SQL:4,$XSS:8" id:1013;
MainRule "str:," "msg:comma" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1015;
...

        То есть в основном отдельные спецсимволы или сочетания 2-3 спецсимволов, плюс правила типа "пустой POST-запрос" или "некорректная hex encoding", а не сигнатуры под конкретную проблему.


        1. rodionovs
          02.02.2017 15:17
          #10049750
          +3

          Это и есть сигнатуры


          1. selivanov_pavel
            02.02.2017 15:29
            #10049780

            Ну тут мы уже спорим о терминологии, может быть я и не прав и это сигнатуры.


            Я хотел сказать, что naxsi по-умолчанию блокирует все запросы, где есть двойная кавычка в неположенном месте, а не конкретно для каждой уязвимости в конкретном движке, в духе в GET-параметре userid не должен встречаться регэксп %3E%3Cscript.


  1. McARIS74
    02.02.2017 15:07
    #10049718

    Я конечно, всё понимаю. Защита, там экран и всё такое. Но мне кажется, ключевой фактор во всём этом, когда переходишь на сайт разработчика и видишь там крупно: стоимость. Я никого не критикую. Просто, предполагая разницу между установками платного ПО и бесплатного, можно сделать вывод, платным пользуются реже. Тем более сейчас, с ростом популярности бесплатных СМС. Не хочется открывать диспут на эту тему, но, как мне кажется, в упоминаниях о возможностях проведения атак на сайты, всегда стоит помнить и упоминать о ценовых критериях (это конкретно-автору). Во многих случаях, очень во многих, пользователь уходит на тот же блог Google+, по причине уже готовой «защищённости». Причём бесплатной. Мне кажется, давно уже пора переходить на бесплатность средств защиты, без урезки функционала, зарабатывая на чём то другом.


    1. selivanov_pavel
      02.02.2017 15:23
      #10049762

      Как вы себе это представляете? Вот парни арендуют в датацентрах мощности, ставят туда серьёзное сетевое и серверное железо, нанимают спецов чтобы это всё настраивать и развивать, платят за трафик(а хороший DDOS может нагнать его ооочень много). И деньги на всё это они получают… продавая ручки и календарики со своей символикой?


      Если пользователь использует Google+/Facebook/Wordpress.com/etc, то защиту он получает, потому что эти компании защищают свою платформу, на которой они как-то монетизируют этого пользователя.


      Можно и нужно развивать open-source средства безопасности, тот же Naxsi, ModSecutiry, OSSEC, но предоставлять бесплатно аппаратные мощности — это какая-то утопия.


    1. rodionovs
      02.02.2017 15:27
      #10049770
      +4

      Google+? Вы про личные блоги? Интернет-магазины, корпоративные сайты и другие подобные веб-приложения, на которые направлены атаки злоумышленников, такой возможности не имеют — им остается или нанимать в штат специалистов, готовых и способных обеспечить защиту их ресурса, или же воспользоваться услугами аутсорсинга (к примеру, нашим сервисом).

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


  1. sp01
    02.02.2017 15:08
    #10049722
    -1

    Всё бы ничего, но в последний момент всё упрется в сертификацию во ФСТЭК.


    1. rodionovs
      02.02.2017 15:28
      #10049776
      +3

      У нас есть лицензия


      1. sp01
        02.02.2017 16:00
        #10049854
        -2

        Был бы рад ознакомится с сертифкатом, ибо ни на сайте, ни в статье этой информации нет.