Сканер безопасности - верный друг и помощник

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

• Собственный профессионализм разработчика (мы ведь все с вами молодцы);
• Web Application Firewall, который отфильтрует атаки на веб-приложение в реальном времени;
• Статический анализ кода, который подскажет возможные уязвимости в коде;
• Непрерывная работа нашей команды по обеспечению безопасности API и компонентов Битрикс;
• Сторонний анализ безопасности веб-приложения различными средствами (к примеру с помощью w3af).
  

Но когда приложение «ушло на золото» и введено в эксплуатацию, начинается наибольшее число неприятностей. Увы, зачастую разработчики и системные администраторы не имеют надлежащего опыта в конфигурировании серверного ПО с позиции ИБ, а штатного эксперта в команде нет. И это хорошо, если проект располагается на VPS/VDS, где можно использовать нашу виртуальную машину, но если это не так, особенно в случае с виртуальным хостингом, то мы можем видеть все что угодно — от полного доступа к вашим бэкапам до использования одного Memcached на все виртуальные хосты. Не стоит так же забывать, что к перечню доменных имен множества зон (ru, рф, com и т. д.) существует публичный доступ, чем с радостью пользуются злоумышленники, периодически проходя по нему и анализируя на предмет уязвимостей связанных с неправильно сконфигурированным серверным ПО. Автоматизировать весь этот процесс от обновления списка до попыток атаки через найденные «огрехи», как вы сами понимаете, достаточно не сложно, и мы не редко отмечаем подобную активность.
Именно с этими мыслями мы сели проектировать наш собственный «сканер безопасности», который выйдет в версии 12.5.0.
Давайте для начала разберемся, что он умеет на текущий момент:

1. Выполнять внутренние сканирование окружения проекта, к примеру, безопасно ли хранятся файлы сессий.
2. Выполнять проверку настроек сайта, к примеру, включен ли WAF, установлен ли пароль к БД и т. д.
3. Выполнять поиск потенциальных уязвимостей в коде проекта с помощью статического анализа.
4. Запускать внешнее сканирование.
   

Каждый из приведенных пунктов - это целый комплекс различных тестов и анализов преследующих одну цель — дать возможность понять, как можно улучшить общую безопасность проекта. Разумеется, ни аудиторы, ни автоматизированные средства не смогут вам сказать безопасен ли проект, все они говорят лишь, «есть ли в проекте уязвимости». А учитывая тот факт, что каждое работающее серверное приложение и каждая строка кода веб-приложения может полностью решить судьбу проекта — задача эта не так легка.
Давайте поближе глянем на сканер безопасности, который вы сможете найти, пройдя в Настройки->Проактивная защита->Сканер безопасности либо просто кликнув по кнопке «Выполнить» в гаджете безопасности на рабочем столе административной части сайта:

Войдя в сканер безопасности, вам сразу же будет предложено пройти сканирование:

Жмем «Запустить сканирование» и ожидаем результатов:

После завершения сканирования вы увидите его результаты. Посмотрим что получилось у меня:

Как видно из результатов, всего на моей тестовой установке было обнаружено 12 потенциальных проблем, из них 5 критичных. Рассмотрим подробнее результаты приведенные на скриншоте:

1. Статический анализ обнаружил явную SQLi, без комментариев
2. Внешнее сканирование обнаружило один публично доступный сервер memcached из пула, заведенного в модуле веб-кластер. Нужно в обязательном порядке закрыть порт (в моем случае 11212), а лучше и вовсе закрыть любой публичный доступ к этому серверу.
3. Внутреннее сканирование обнаружило файлы с доступом для other (к примеру -rw-rw-rw-), такое часто происходит в последствии выполнения всяких how-to, где написано что после установки права на какой либо файл или директорию нужно выставить в 777. К примеру, вот: http://www.opengs.ru/lampubuntu/77-ustanovka-i-nastroika-lamp-i-phpmyadmin.html
   

Думаю никто не станет спорить с критичностью найденных проблем и с необходимостью их исправления.
В этот раз я не буду детально останавливаться конкретно на тестах, желая осветить лишь общую концепцию его работы. Так же, хотел упомянуть тот факт, что нами рекомендовано проходить сканирование хотя бы раз в месяц о чем вам напомнит административный информер. Это обусловлено и планами по развитию сервиса и ситуацией, когда хостинг провайдеры прозрачно для клиента меняют какую либо часть конфигурации сервера, которая в последствии может стоит вашему проекту репутации и честного имени.
Если у вас есть какие вопросы либо предложения — спрашивайте, пожалуйста, либо пишите в нашу отважную ТП. Всем безопасных проектов, продолжение следует!