Почему готовые решения не дадут 100% защиты?

Сейчас во всех крупных компаниях имеются межсетевые экраны с системами обнаружения и предотвращения вторжений (IDS/IPS), а для защиты своих сайтов многих используют Web Applications Firewall (WAF). И просто купив готовое решение люди имеют ложное чувство безопасности, а "эффективные" менеджеры продаж внедренцев активно предлагают всё новые и новые решения. Они могут красиво расписать почему нужно купить новый продукт, и будут сыпать множеством красивых технических терминов, которые они узнали не из опыта эксплуатации продукта, а из тренинга по продажам. И они не смогут объяснить почему продукт, который они годом ранее расписывали как панацею сейчас не обеспечивает обещанный уровень защиты. Что вы от них ждёте? Интеграторы не эксплуатируют то, что продают - они это только внедряют и иногда решают проблемы с этим продуктом. Обратите внимание на то, что большая часть взломов крупнейших мировых компаний была именно через подобных подрядчиков.

Однако продукт обновляется активно, и вроде-бы такой красивый, но почему тот же IDS или WAF не может гарантировать обнаружение зловредного действия? Тут дело не в ранее неизвестной уязвимости или чем-то подобном. Некоторые угрозы нулевого дня могут эксплуатироваться десятилетие прежде, чем их обнаружат.

Начну издалека. На множестве ресурсов в интернете публикуется информация об уязвимостях, так называемые CVE. Можно их смотреть и в БДУ ФСТЭК. Для большинства уязвимостей нет технической информации, которая позволила бы понять, как это работает, чтобы написать правило для системы обнаружения вторжений. У некоторых есть возможность изучить некую техническую информацию и посмотрев открытый исходный код попробовать понять, как может проходить вектор атаки. Информация об уязвимостях публикуется для того, чтобы специалисты обновили свой продукт до версии, которая не содержит эту уязвимость, или применили патч, или другие указанные разработчиком меры.

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

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

Если набрать в поиске по github cve-ГОД-, то можно увидеть примерно следующее количество репозиториев в результатах поиска:

• 2024 1.9k
• 2023 2.3k
• 2022 2.1k
• 2021 2.5k
• 2020 1.6k
• 2019 1.4k
• 2018 1.1k
• 2017 881
• 2016 368 
• 2015 268
• 2014 315
• 2013 100
• 2012 76
• 2011 57
• 2010 46
• 2009 37
• 2008 33
• 2007 54
• 2006 23
• 2005 10
• 2004 24
• 2003 19
• 2002 19
• 2001 12

Сразу хочу отметить, что не все репозитории среди результатов поиска прям эксплоиты - там есть и инструменты только проверки наличия уязвимости. Да и поиск не по точной словоформе, то есть под cve-2020-2001 почему-то подходит "cve-2001-". Поиск по github не очень точный, и не такой удобный, как тот же Google или Яндекс.

Общее количество более 14000.

Можно зайти в Банк данных угроз безопасности информации на сайте ФСТЭК России и увидеть 62811 записей об уязвимостях (на 14.11.2024). 

В известной базе эксплоитов exploit-db 46102 записи (на 14.11.2024).

Вся эта предыстория была к тому, что их можно изучать и писать на их основании правила для IDS или WAF. 

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

Многие компании просто берут общедоступные правила и копируют их в свои IDS на борту межсетевого экрана. Правила из открытого набора ET Open встречаются во многих платных и бесплатных межсетевых экранах. Речь про вообще все, а не только отечественные. И хорошо, когда они их перерабатывают или хотя-бы переименовывают.

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

Во всём мире не так много компаний, которые действительно могут писать эти правила расследуя взломы. Это конечно не десятки компаний, скорее сотни, но тем не менее. И специалисты, которые способны на такое стоят просто космических денег. Настолько космических, что такие зарплаты ни одному Московскому программисту даже и не снились. При этом тебе недостаточно иметь несколько таких специалистов - с целью своевременного анализа и написания правил для IDS их нужно держать в десятки раз больше. Уязвимости появляются каждый день просто бешенными темпами, а для анализа лишь одной уязвимости может потребоваться изучение громадного количества исходного кода на языке программирования, с которым специалист должен быть не просто на ты, а на уровне профи.

Такая же история и с WAF. Если вы думаете, что лучшие WAF в мире знают все эксплоиты для веб-приложений, то вы заблуждаетесь. У них есть очень качественная база правил и даже используется искусственный интеллект для анализа HTTP запросов, но никто из них не включает все или хотя-бы большую часть эксплоитов для веб-приложений в правила. Имею введу, что не пишут правила по результатам анализа всех эксплоитов из общего доступа.

При анализе журнала Nginx хороший веб-разработчик и знаток своего сайта всегда сможет понять какие HTTP запросы явно нелегитимные. Любой популярный сайт подвергается массовым сканированиям, поэтому очень полезно изучать журналы веб-сервера. Такие сканирования могут проводить поисковые системы или специализированные сервисы, скрипт-кидди или самые настоящие хакеры.

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

Более профессиональные специалисты могут направлять не более одного запроса с одного IP-адреса (хотя и не всегда), и по их запросам можно заметить насколько они продуманны. Часто они ищут обратный web-shell, или обращаются к файлу .php, которого у тебя нет и среди известных уязвимостей он не упоминается, однако, через какое-то время все таки публикуется уязвимость, связанная с этим файлом.

При анализе журналов веб-сервера популярного сайта можно находить подозрительные запросы, и если пытаться понять что хотел пользователь, тогда можно обнаружить много интересного. Пример, обращение к какому-то php файлу, которого у тебя никогда не было, и даже директории такой не было и нет. И поисковики не дают вразумительных результатов, но при поиске на специальных сайтах узнаешь, что это web-shell и человек при помощи скрипта хочет найти сайты, на которые была успешно проведена атака. Именно во избежание обнаружения после взлома вредоносный код может не инициировать соединение с командным центром, а тихо ждать обращение по определенному url-адресу. Есть огромные китайские сайты с невероятным количеством информации по уязвимостям, в которых есть то, что невозможно найти в других. Зачастую именно на них нахожу информацию, что конкретный путь это web-shell.

Попробуйте спросить про подобные запросы у поддержки вашего WAF и они скажут что-нибудь красиво, но с одним и тем же смыслом, мол это массовые сканирования и это не страшно. Китайцы сейчас массово ищут уязвимые версии DedeCMS по всему интернету, а если бы у меня была именно эта CMS? Тогда была бы вероятность, что это сканирование дало бы злоумышленнику положительный результат, а вам негативный. Еще поддержка может предложить вам самим писать правила, но вы же хотели получить продукт, который из коробки защищает от всех злодеев и при этом не блокирует легитимные запросы.

Всё сводится к тому, что самое важное в этой схеме значение играет прокладка между рулём и сидением, то есть специалист по информационной безопасности эксплуатирующей WAF или IDS организации. При чем, он должен не просто знать как взломать сайт и идеально знать теорию по информационной безопасности - он должен обладать навыком взлома сайта. Для этого не обязательно взламывать чужие сайты, так как сейчас большое количество тренировочный сервисов. И именно при наличии таких специалистов в организации может получиться обеспечить близкий к 100% уровень безопасности.