Содержание статьи
Тестирование на проникновение (penetration testing) — метод оценки безопасности компьютерных систем или сетей средствами моделирования атаки злоумышленника. Для кого-то это хобби, для кого-то работа, для кого-то это стиль жизни. На страницах нашего журнала мы постараемся познакомить тебя с профессией настоящего «этичного хакера», с задачами, которые перед ним ставятся, и их решениями.
Intro
Наверняка ты хотя бы раз интересовался спросом на различные «хакерские» услуги, будь то продажа/покупка траффика или веб-шеллы под дорвеи, натыкался на немыслимое число постов о предложении DDoS-атак и рассылку спама. Таких объявлений полно на любом тематическом форуме в разделе с характерным названием «Покупка/Продажа/Работа». Не составит труда провести аналогию между услугами, предоставляемыми на подобных форумах, и услугами, которые предлагают ведущие консалтинговые фирмы (их, к сожалению, до сих пор можно пересчитать по пальцам одной руки). Грубо говоря, топик «Продам доступ к серверам компании Х» мапится на «тестирование на проникновение» — процесс один и тот же (не рассматриваем мотивы, цели, законодательство).
Соответственно, DDoS, если следовать тому же принципу, отлично мапится на консалтинговую услугу «оценка отказоустойчивости Х». В 2010–2011 годы ни одна отечественная консалтинговая компания подобными услугами не занималась. Так я стал одним из product owner’ов комплекса тестирования на отказоустойчивость.
Birth of the DeathStar
Спрос рождает предложение. DDoS имел спрос на черном рынке, на белом же спроса не было. Хотя это чертовски странно, ведь один из трех китов информационной безопасности — доступность — никак не покрывался практическими проверками. Только на бумаге были расписаны угрозы, планы непрерывности бизнес-процессов, планы реализации резервирования и дублирования (в большинстве случаев в жизнь все это сразу не воплощалось — не было бюджета). И только источники бесперебойного питания стали оплотом той самой живой составляющей обеспечения доступности информации. Я решил потратить время на разработку услуги по оценке веб-приложений на отказоустойчивость.
Ты не поверишь, но несколько лет назад у пентестеров было свободное время на ресерч, на котиков и на многое другое: половина зимы и половина лета были мертвыми сезонами — когда большинство CISO уезжали в отпуска, консалтинг в сфере ИБ был не очень востребован. К счастью, сейчас это не так, точнее, сейчас это незаметно, поскольку спрос на услуги вырос. В один из таких периодов затишья была разработана клиентская и серверная часть системы, которая позволяла нагружать тестируемое веб-приложение. Серверная часть представляла собой веб-приложение, к которому раз в минуту обращались клиенты и получали новое задание, — все банально. Серверная часть была названа DeathStar, а идентификатор каждого из клиентов начинался со StormTrooper — в честь Star Wars, являюсь поклонником которых я (уже выбираю костюм, в котором пойду на премьеру в декабре, да).
Разработать серверную составляющую было самой простой задачей. Тогда я, кстати, узнал, что такое фрагментированные SQL-инъекции, да-да, in my face, после чего сделал воркшоп на эту тему на первом PHDays. Клиентская часть также оказалась несложной — обычный Perl/bash/Python-скрипт, который парсил задачи, полученные от сервера, и запускал тулзы в зависимости от рода задачи. Первые тесты, особенно с эксплуатацией техники Slow Post, показали ошеломляющий результат. Подконтрольные серверы уходили в даун, DeathStar работала!
Обеспечение распределенности и многопоточности
В результате на выходе были готовые клиент (набор скриптов) и сервер (веб-приложение, раздающее задачи). На разработку, тестирование и фикс багов ушло около месяца. Требовался хост для каждого из клиентов. Чем больше будет клиентов, тем мощнее наша «Звезда смерти». Первое, что пришло в голову, — использовать сервис EC2 от Amazon, который подкупил своим бесплатным триалом и дешевыми инстансами — непроизводительными, но вполне пригодными для генерирования трафика.
Начало было положено с двадцати инстансов (предел аккаунта по умолчанию). В Амазоне был создан образ, который при загрузке запускал клиент. После положительных результатов тестов и непродолжительного общения с техподдержкой Амазона квота на запущенные инстансы была расширена до семисот. Впоследствии было заведено еще несколько аккаунтов с расширенной квотой.
Рождение услуги
Инструмент для оценки отказоустойчивости веб-приложений был готов, дело было за продажей услуги. Проблема состояла в том, что для начала услугу нужно было раскрутить, показать кейсы, в которых к ней стоит обратиться, донести до потенциальных клиентов, что на рынке такая услуга есть. Те, кто в ней нуждается, с радостью ею воспользуются, те, кто об этом даже ничего не слышал, возможно, заинтересуются после того, как ознакомятся с матчастью. Как ты заметил, никакого анализа рынка и спроса напрямую не было. В описание услуги входили подход к оценке веб-приложений на отказоустойчивость, методология, перечень техник, реализуемых в процессе тестирования, примеры кейсов, а также рекомендации по планированию работ. Уверен, что с большинством пунктов из этого списка тебе все ясно.
В качестве начальной цены за услуги была высчитана приблизительная цена, которая должна была покрыть все расходы на использование ресурсов EC2. Речи о профите не шло. В то время для выхода услуги на рынок было проведено несколько презентаций на тему защиты от DoS/DDoS и даже вебинар.
Спрос и клиенты
Итак, услуга вышла на рынок, было проведено несколько работ. Когда и кем она была востребована? В 80% случаев это оказались банковские CISO, которые:
- внедряли онлайн-банкинг;
- сталкивались с DDoS и тестировали внедренные механизмы реагирования и защиты;
- пытались показать несостоятельность ПО онлайн-банкинга средствами функционального нагрузочного тестирования (Race condition).
В остальных 20% случаев услугой интересовались при подготовке к запуску масштабных мероприятий, которые должны были освещаться в интернете, например локального чемпионата по Magic: The Gathering, где все завязано на стриминг-видео.
Вероятно, отсутствие спроса из других отраслей было связано с тем, что для них все казалось очевидным. Зачем платить деньги за информацию, которой ты и так обладаешь? Это очень поверхностное суждение и пассивное поведение. Возможно, одной из причин этого стал FUD, крайне популярный прием маркетинга в индустрии ИБ. Все понимают, что есть предел, который система может выдержать. Этот предел прописан на бумаге, но почему-то никто не хочет проверить, так ли это на самом деле. Ничего не напоминает?
Weekdays
Тестирование на отказоустойчивость имеет смысл проводить только в продакшен энвайронменте, а значит, есть риск что-нибудь уронить так, что оно будет недоступно для конечных пользователей. Это недопустимо. Соответственно, при планировании работ необходимо свести возможность недоступности ресурса для конечного пользователя к минимуму. К примеру, идеальный вариант для интернет-банкинга — ночь с субботы на воскресенье (с учетом часовых поясов нашей родины это с 00:00 до 03:00 по Москве, если банк имеет пользователей на всей территории). Как ты понимаешь, это не очень-то удобное время для работы в офисе, и обычно все стараются избежать подобных графиков, пользуясь официально закрепленными выходными днями.
Большинство заказчиков интересовались именно функциональным нагрузочным тестированием — полной эмуляцией действий пользователей, распознать бота в которых очень сложно. Это стало проблемой — достаточно много времени уходило на написание кода, эмулирующего пользователей, ведь каждый интернет банк уникален по-своему, а цена времени растет в геометрической прогрессии при условии его нехватки.
Death of the DeathStar
Практика подсказывала: необходим отдельный человек, который мог бы себя целиком посвятить тестированию и поддержанию системы up-to-date. Код для нагрузочного функционального тестирования, отработавший единожды, становился больше не актуальным. Но, помимо этого, опытным путем было выявлено, что услуга по большому счету одноразовая. Это не делало ей чести. Услуга, не пользующаяся спросом, невыгодна как минимум материально. Какое-то время заказчиков не было вообще, и она, продержавшись в пакете услуг около пары лет, была отправлена в отставку. В настоящий момент ни одна из ведущих консалтинговых компаний подобную услугу не оказывает.
Outro
Если на рынке нет какой-либо услуги, это отнюдь не значит, что ее никто не может предоставлять или же на нее совершенно нет спроса. Даже самое невероятное предложение найдет своего заказчика, а что уж говорить о тестировании на проникновение. Вопрос только в рентабельности затрат. Не бойся проб и ошибок. Дерзай и да пребудет с тобой сила!
Stay tuned!
WWW
Полезная информация
Общая теория по пентестам
- VulnerabilityAssessment
- Open Source Security Testing Methodology Manual
- The Penetration Testing Execution Standard
