Заодно и своим расскажем, так как не все сотрудники еще видели этот модуль и понимают, что он делает Вчера прошла техническая презентация модуля для технической поддержки и отдела документирования и вопросов было много. Я буду неторопливо рассказывать, так что наберитесь терпения
Итак...[spoiler]
Проблематика
Сначала несколько слов о том, как у нас устроен производственный цикл по выпуску нового функционала. Перед выпуском модуля идет обязательная процедура тестирования: включает в себя тестирование разработчиками на внутренних серверах с разными базами данных, операционных систем и версиями PHP, потом отдел тестирования проверят на соответствие бизнес-функциональности и наличие ошибок, потом отдел безопасности проверят на наличие уязвимостей, потом уже модуль может поступить в бета-тестирование клиентам и партнерам.
Большинство разработчиков работает в нашей компании уже по 5-8 лет и можно сказать, что ребята очень хорошо обучены и натренированы в вопросах безопасности специалисты. Т.е. как тезис я бы сказал, что мы располагаем наиболее квалифицированными веб-разработчиками с прекрасными знаниями вопросов безопасности.
Но, несмотря на это, отдел безопасности регулярно находит потенциальные уязвимости и возвращает модули на доработку.
Мы с Юрой Тушинским, техническим директором, как-то обсуждали эту ситуацию. Почему тезис "обучение веб-разработчиков безопасности" не дает полной уверенности в качестве разработки?
Ответ довольно просто формулируется - разная психология. Разработчик думает как решить бизнес-задачу быстро, эффективно, сделать производительно, удобно для пользователя, совместимо и другие аналогичные аспекты. Хакер думает совсем в другом векторе: как сломать, как подменить данные, что сделать с плохой обработкой ошибок, как злоупотребить....
Юра рассказывал, что он сам после 3 недель работы по теме безопасности потом не может начать нормально программировать довольно долго, голова думает совсем не о разработке...
Получается, что обычный цикл производства программного продукта обязательно должен включать в себя специалиста по безопасности, который думает только о том, как сломать продукт и обойти защиту. На основании этого вывода начиная с версии 4.0 в нашей компании появился отдел безопасности и нам удалось поднять качество производства в вопросах безопасности на очень высокий уровень.
Но это у нас в компании, мы все же специализируемся на разработке продукта. А что же происходит в компаниях веб-разработчиков? Я знаю сегодня всего пару компаний у которых в штате есть специалист, частично разбирающийся в безопасности. Но при этом, он не работает как безопасник, а только изредка подключается к проектам для проверки безопасности, а основное время он работает обычным веб-разработчиком.
Следовательно, можно предположить, что в разработках на базе продукта теоретически должны быть потенциальные уязвимости. И это не потому, что веб-разработчики плохие или продукт дырявый. Это потому, что так устроена жизнь, отличается психология.
Еще одна проблема - на безопасность клиенты никогда не дают деньги. А если клиенты и дают деньги, то компаниям сложно найти специалистов и содержать их на нерегулярных контрактах.
Напомню статью по этой проблематике Алексея Лукацкого -
В общем, получается - безопасность через незнание.
Классические решения
Учитывая положение вещей мы старались сделать Bitrix FrameWork максимально устойчивым и проверенным по безопасности.
API функции делались безопасными, стандартные инструменты по работе с переменными многократно проверялись и страховали разработчика от большинства типовых ошибок. Потенциально опасные действия собирались в классы и экранировали веб-разработчиков от необходимости думать о безопасности. Так работа с файлами, которая несет в себе массу угроз, собрана в отдельные классы, многократно контролируемые по безопасности. Политика безопасности групп пользователей защищала пароли и запоминанемые хэш функции от похищения. Привязки авторизованных сессии к IP, единая авторизация на всех проектах, трехуровневая система разграничения прав, CAPTCHA и масса других решений.
Все это было и есть в продукте. И я думаю, что нам удалось всеми этими действиями очень сильно поднять уровень защищенности и качество разработки приложений написанных на базе Bitrix Framework.
Но это не дает 100% защиты. Веб-разработчик теоретически может проигнорировать рекомендованные функции, взять переменную прямо из запроса, без обработки вставить в запрос к базе данных и получить одновременно и SQL Injection и эксплуатируемый XSS. И тогда все усилия оказываются напрасными, человеческий фактор сводит на нет усилия.
Угрозы безопасности
Стоит отметить, что веб-разработчику требуется очень много времени и системное обучение, чтобы стать хорошим специалистом по разработке безопасных веб-приложений. Причем достигает он высокого уровня, только если его приложения проходят критическое тестирование на безопасность.
А вот хакеру не требуется долгого обучения, чтобы воспользоваться классическими и самыми массовыми уязвимостями веб-приложений, такими как XSS, SQL Injection, PHP Including... И проверить свои знания он может с легкостью на любом сайте.
Более того, есть даже инструменты для автоматизированного поиска уязвимостей на сайтах.
Я бы охарактеризовал соотношение квалифицированных веб-разработчиков к хакерам как 1:100. Опять же, не поймите это как укор. Так получается, что рядовой веб-разработчик начинает глубоко вникать в вопросы безопасности только когда впервые сталкивается с проблемами.
Безусловно, к угрозам безопасности необходимо относить не только веб-приложений, но и угрозы безопасности Информационной среды. Но это уже за пределами этого сообщения. Подробнее я писал на нашем сайте:
Аудит безопасности
Как вариант мы долгое время рассматривали направление платных аудитов безопасности.
Наш отдел безопасности выполнял аудит безопасности по запросам крупных клиентов и партнеров. Очень интересная практика и ценнейшие данные для анализа!
Но невозможно проверить такое большое количество сайтов, бизнес-логики и решений партнеров. На одном клиенте можно было застрят на 1-2 месяца и даже не проверить все, а параллельно разработчики выпускают новые модули и их опять нужно проверять
Мощности по проверке у нас незначительные, это не основная для нас деятельность. Наращивать объем оказания услуг нет возможности.
В итоге, услуга аудит-безопасности не получила широкого тиражирования и была снята с продажи.
Мы решили изменить направление развития по теме безопасности. И стали искать решения, которые могли бы помочь всем партнерам и клиентам в равной степени.
Проактивная защита
Такое длинное вступление я сделал, чтобы вы лучше поняли, почему мы выбрали направление по разработке модуля и какие мы ставим перед собой задачи, в чем мы надеемся помогать веб-разработчикам и клиентам.
Для себя мы определили модуль "Проактивной защиты" как комплекс технических решений по обеспечению безопасности продукта и разработанных веб-приложений, включающий несколько уровней защиты от большинства известных атак на веб-приложения, существенно повышающий уровень безопасности интернет-проектов.
"Проактивная защита" является важным дополнением к стандартной политике безопасности продукта. Модуль включается во все редакции Управления сайтом кроме Старта и в Корпоративный портал.
Модуль включает в себя комплекс систем по защите веб-приложений:
* Панель безопасности с оценкой уровнями безопасности
* Проактивный фильтр (Web Application FireWall)
* Технологию одноразовых паролей (OTP)
* Защиту авторизованных сессий
* Контроль активности
* Защиту редиректов от фишинга
* Шифрование канала передачи через SSL
* Журнал вторжений
* Защиту административных разделов по IP
* Стоп-листы
* Контроль целостности
* Рекомендации по настройке
* Защиту редиректов от фишинга (пока в разработке)
* Шифрование канала передачи через SSL (пока в разработке)
* Монитор обновлений (в разработке)
* Внешний контроль инфосреды (в разработке)
Сейчас я по порядку расскажу о возможностях модуля и какие задачи мы решаем тем или иным функционалом.
Проактивная защита: панель безопасности и оценка уровня безопасности
Несмотря на сложность темы безопасности, мы ставили перед собой задачу сделать функционал модуля доступным для работы обычными пользователям. Нам кажется важным, чтобы клиенты и партнеры понимали, что происходит на сайте и каким уровнем защищенности они располагают.
Мы реализовали панель безопасности на которой все функиции модуля сгруппированы в уровни: Начальный, Стандартный, Высокий, Повышенный
Начальный уровень безопасности получают проекты на базе Bitrix Framework без установленного модуля Проактивной защиты. Это был тема большой дискуссии внутри компании, почему так называть и почему такой уровень. И все же мы решили, что так как партнеры не проверяют свои разработки на безопасность, клиенты иногда не устанавливают обновления продукта, мы будем ставить Начальный уровень безопасности.
Стандартный уровень безопасности получают проекты с включенными элементами проактивной защиты:
Проактивный фильтр (Web Application FireWall) на весь сайт без исключений, включен Контроль активности, ведется журнал вторжений. Уровень безопасности для группы Администраторы должен быть установлен в Повышенный.
Напомню, какие параметры там устанавливаются:
* Время жизни сессии (минут)
* Маска сети для привязки сессии к IP
* Максимальное количество компьютеров на которых может быть одновременно быть запомнена авторизация
* Маска сети для привязки сохраненной авторизации
* Срок хранения авторизации, запомненной на компьютере пользователя (минут)
* Срок действия контрольного слова для восстановления пароля (минут)
* Минимальная длина пароля
* Пароль должен содержать латинские символы верхнего регистра (A-Z)
* Пароль должен содержать латинские символы нижнего регистра (a-z)
* Пароль должен содержать цифры (0-9)
* Пароль должен содержать знаки пунктуации (,.<>/?;:'"[]{}\|`~!@#$%^&*()-_+=)
* Количество попыток ввода пароля до показа CAPTCHA (защита от перебора)
Все эти правила устанавливаются в настройках группы пользователей и включаются в ядро продукта.
Мы так же посчитали важным, чтобы на сайте был включен параметр "Использовать CAPTCHA при регистрации". Режим вывода ошибок (error_reporting) был установлен в Только ошибки, чтобы не раскрывать информацию о конфигурации системы.
В дальнейшем мы планируем в уровне Стандартный добавить проверку на наличие рекомендованных и не установленных обновлений продукта, включенность защиты редиректов от фишинга,
Высокий уровень безопасности получают проекты выполнившие требования Стандартный плюс:
* включившие Журналирование событий главного модуля
* установившие Защиту административной части по IP
* включивших Хранение сессий в базе данных
* и Смену идентификатора сессий
В дальнейшем в уровень Высокий попадут проверки включенного SSL сертификата для авторизации и работы с продуктом.
Повышенный уровень безопасности можно будет получить включив в дополнение к Высокому уровню защиту одноразовыми пароля OTP для администраторов, Контроль целостности и еще ряд параметров (уточняются).
Начиная с версии 8.0 модуль Проактивной защиты будет по умолчанию включен в продукте. Все текущие клиенты загрузят и установят этот модуль по технологии SiteUpdate и он автоматически установит параметры соответствующие уровню безопасности Стандартный.
Теперь немного подробнее о функционале.
Проактивный фильтр (Web Application Firewall)
Проактивный фильтр (Web Application Firewall*) - обеспечивает защиту от большинства известных атак на веб-приложения. В потоке внешних запросов пользователей проактивный фильтр распознает большинство опасных угроз и блокирует вторжения на сайт.
Проактивный фильтр (Web Application Firewall) – наиболее эффективный способ защиты от возможных ошибок безопасности, допущенных при реализации интернет-проекта (XSS, SQL Injection, PHP Including и ряда других).
По данной теме рекомендую посмотреть следующие ссылки:
Чаще всего такие решение разрабатываются и устанавливаются выше веб-приложения в виде аппаратных устройств или модулей для веб-сервера, как например ModSecurity. Но в большинстве своем это требует сложного администрирования, не позволяет работать на уровне приложения, зачастую делает само приложение неработоспособным...
Мы доработали концепцию и наши вариант включения Web Application Firewall непосредственно в продукт. Фактически, фильтр проверяет на каждом хите все данные, которые могут поступить на сайт через переменные GET, POST, куки, серверные переменные. Если происходит сработка, возможно несколько видов реакции на ситуацию:
1 Сделать данные безопасными
2 Очистить опасные данные
3 Добавить IP-адрес атакующего в стоп-лист на ХХ минут.
4 Занести попытку вторжения в журнал
Сделать данные безопасными означает, что данные будут модифицированы. Например "select" будет заменен на "sel ect", а "<script>" на "<sc ript>". Ну не понимайте буквально, но в общем примерно так
По умолчанию сайт будет менять данные, чтобы вызвать наименьшее неудобство для пользователей. Обратите внимание, что некоторые действия пользователей, не представляющие угрозы, тоже могут выглядеть подозрительно и вызывать ложное срабатывание фильтра. По нашим расчетам, число ложных сработок будет минимальным. Пока идет обкатка и фильтр дорабатывается, например сегодня была доработка фильтра для англоязычных клиентов.
Обновления проактивного фильтра доступны вместе с общими обновлениями продукта по технологии SiteUpdate.
Рекомендуется включить для стандартного уровня.
Маска исключений поможем вам отключить работу фильтра на некоторых разделах или страницах сайта. Например, если ваш сайт для разработчиков SQL приложений, то работу фильтра лучше будет отключить для форума и соцсети.
Но все же, для большинства проектов исключения мы считаем недопустимыми и будем снижать уровень безопасности, есть они настроены.
Журнал вторжений
В случае если Проактивный фильтр срабатывает, в системном журнале появляется запись в одной из трех категорий безопасности.
Сегодня мы выделяем три категории атак:
* Попытка внедрения SQL
* Попытка атаки через XSS
* Попытка внедрения PHP
За два выходных дня на нашем сайте фильтр сработал больше 400 раз!
Большинство записей в журнале относится к роботам, которые автоматическим образом ищут уязвимости на сайте. Но часть записей показывает что идет ручной поиск XSS или SQL уязвимостей.
Попалось несколько и ложных срабатываний. Я уже отмечал выше, что будет выпущено улучшение фильтра, надеемся исключить неверные срабатывания фильтра.
Напомню, что наш интерфейс позволяет вам вывести больше полей в список, чем вы видите и в том порядке, который вас больше устраивает. Так что не забывайте.
Одноразовые пароли
Модуль Проактивной защиты позволяет включить поддержку одноразовых паролей и использовать таковые выборочно для любых пользователей на сайте.
Данная технология позволяет быть однозначно уверенным, что на сайте авторизуется именно тот человек, которому вы выдали брелок. Похищение и перехват паролей теряет смысл, так как пароль одноразовый. Человек не может передать пароль другому человеку и при этом продолжить сам пользоваться входом, так как брелок физический и дает уникальные одноразовые пароли только при нажатии.
Система авторизации с использованием одноразовых паролей (One-Time Password - OTP) разработана в рамках инициативы .
Реализация основана на алгоритме HMAC и хэш-функции SHA-1. Для расчета значения OTP принимаются два входных параметра - секретный ключ (начальное значение для генератора) и текущее значение счетчика (количество необходимых циклов генерации). Начальное значение хранится как в самом устройстве, так и на сайте после инициализации устройства. Счетчик в устройстве увеличивается при каждой генерации OTP, на сервере - при каждой удачной аутентификации по OTP.
Партия устройств OTP поставляется с зашифрованным файлом, содержащим начальные значения (секретные ключи) для всех устройств партии, связанного с серийным номером устройства (печатается на корпусе устройства).
В случае нарушения синхронизации счетчика генерации в устройстве и на сервере, её можно легко восстановить - привести значение на сервере в соответствие значению, хранящемуся в устройстве. Для этого администратор системы или сам пользователь (при наличии соответствующих разрешений) должен сгенерировать два последовательных значения одноразовых паролей (OTP) и ввести их в форму на сайте.
Система дополняет стандартную систему авторизации и позволяет значительно усилить систему безопасности интернет-проекта. Для включения системы необходимо использовать аппаратное устройство (например, ) или использовать соответствующее программное обеспечение, реализующее . Система одноразовых паролей рекомендуется к использованию администраторам сайтов для повышения уровня безопасности.
Как пользоваться
При включении системы одноразового пароля, этот пользователь сможет авторизоваться только с использованием своего имени (login) и составного пароля, состоящего из пароля и одноразового пароля устройства (6 цифр). Одноразовый пароль (см. 2 на рисунке) вводится в поле "Пароль" стандартной формы авторизации на сайте сразу после обычного пароля (см. 1 на рисунке) без пробелов.
Расширенная аутентификация с одноразовым паролем начнет работать после ввода секретного ключа и двух последовательно сгенерированных одноразовых паролей, полученных с устройства.
Инициализация
При инициализации или повторной синхронизации устройства с пользователем необходимо заполнить два последовательно сгенерированных одноразовых пароля, полученных с устройства.
Обратите внимание, что в настройках одноразовый защиты можно указать "Размер окна проверки паролей". По умолчанию указано 10. Это означает, что если ваш ребенок нажмет на кнопку брелка и получит больше 10 паролей, вам придется идти к администратору сайта и опять проводить инициализацию.
Мы отнесли поддержка OTP к категории Повышенная защита. Я так же не исключаю, что в скором времени будут найдены или написаны приложения для мобильных телефонов реализующие OTP в более простом варианте использования.
Ограничение доступа к административной части по IP
Очень часто компании строго регламентируют сети, которые считают безопасными и из которых разрешают сотрудникам администрировать сайт.
Мы разработали специальный простой интерфейс, который позволяет вам указать список IP адресов или диапазоны адресов из которых можно управлять сайтом. Система проверяет, чтобы вы не закрыли себе доступ в момент установки блокировки. Но вообще при желании вы можете допустить и такую ошибку
на этот случай загляните в настройки модуля Проактивной защиты. Там вы найдете путь к файлу-флажку запрета блокировки по IP. Для каждого проекта это уникальное имя файла.Настроив такой вариант вы сможете просто и очень эффективно защитить папку /bitrix/admin/ от доступа извне ваших сетей.
Настройка требуется для получения уровня безопасности Высокий.
Защита сессий
Большинство атак направлены на похищение авторизованной сессии пользователей и в особенности администраторов.
Выше я отмечал, что мы в базовой поставке защищаем сессии следующими способами:
* Время жизни сессии (минут)
* Маска сети для привязки сессии к IP
Настраивается это в группах пользователей в политике безопасности.
Привязка сессии к IP или подсети пользователя делает похищение сессии крайне проблематичным. Но не всегда такие строгие настройки удается ввести.
Мы реализовали еще два инструмента защиты сессий.
Защита сессий: Хранение в базе данных
Хранение данных сессий в таблице модуля позволяет избежать чтения этих данных через скрипты других виртуальных серверов, исключив ошибки конфигурирования виртуального хостинга, ошибки настройки прав доступа во временных каталогах и ряд других проблем настройки операционной среды. Кроме того, это разгружает файловую систему, перенося нагрузку на сервер базы данных.
Рекомендуется включить для высокого уровня.
Защита сессий: Смена идентификатора
У каждой сессии есть идентификатор который передается при каждом запросе к серверу в куках.
При включении смены идентификатор сессии пользователя начнет изменятся через заданный промежуток времени. Это создает дополнительную нагрузку на сервер, но позволяет сделать похищение делает похищение авторизованной сессии неэффективным.
Механизм пробный и уникальный. На нашем сайте я включил его и пока надежность не вызвала нареканий.
Необходимо включить для высокого уровня.
Оба механизма защиты сессий в сочетании со стандартными возможностями позволят надежно защитить авторизованную сессию администратора.
Контроль активности
Данный инструментарий внесен в модуль Проактивной защиты из модуля Веб-аналитики. Так случилось, что часть инструментов появилась в продукте там, где могла быть реализована. Сегодня эти инструменты плавно переводятся в модуль Проактивной защиты.
Сайты зачастую подвергаются DDoS атакам, по ним ходят интенсивные автоматизированные роботы, которые извлекают контент, спамят и всячески подстраиваются под посетителей...
Пока их активность не очень высока, на них не обращают внимание. Но вот с активными уже нужно бороться. И как раз для этого предназначен контроль активности.
В параметрах Контроля активности вы можете установить порог нормальной для человека активности. У нас по умолчанию стоит порок в 15 хитов на 10 секунд. Проверенная временем характеристика позволяет выделить автоматизированные скрипты и заблокировать их работу на установленное время.
В течение времени блокировки пользователю будет выдаваться 503 ответ сервер, т.е. сервер занят и не может обрабатывать запросы. Все остальные пользователи смогут работать с сайтом совершенно нормально.
Данная характеристика подобрана таким образом, что поисковые роботы под нее не попадают.
Стоит обратить внимание, что в случае срабатывания системы Контроль активности в журнал событий будет добавлена соответствующая запись. Вы сможет увидеть кто и по каким причинам был заблокирован.
За выходные у нас в журнале появилось 43 записи заблокированных "посетителей".
Коллеги, статья в процессе написания... мало времени, но стараюсь, будет доработана и помечена (ДОПОЛНЕНО).
Фото:
И задумались над исправлением своих дырок в сайтах сейчас, а не после того как их ломанули.
А почему в Старт не включили? Он тоже хочет проактивный фильтр )
Мы приняли такое решение, чтобы не перегружать Старт и сохранить его простым и доступным.
Долго спорили об этом в закрытых форумах. Проактивная защита войдет во все редакции кроме Старта.
Вы сможете получить модуль через обновления только если у вас активна техническая поддержка. Если ключик истек, необходимо будет продлеваться.
В районе 0.5-1% Но опять же, по ряду тестов отклонений нет, незаметны изменения. По ряду тестов они есть, но небольшие. На наших проектах время исполнения страниц не увеличилось. Разницу после установки я не смог выявить.
Было бы очень полезно оперативно реагировать на ситуацию, ведь не всегда можешь каждый день заходить на сайты, которые на техподдержке, чтобы проверять эти журналы.
Но вообще настроенная защита не требует немедленной реакции на вторжение, это скорее повод и информация для размышления и демонстрация эффективности работы.
Не подскажите, где это было? Там, кажется, даже картинки были.