«Противостояние» глазами защитника: Рассказ о PHDays CTF от участника соревнований

Автор: Андрей Дугин,
инженер по защите информации телеком-оператора

В этом году главный хакерский конкурс PHDays сменил формат: мы отошли от привычного CTF. Вместо этого на форуме развернулась настоящая битва хакеров и безопасников. В этот раз сражались три команды: «хакеры», «защитники» и SOC (security operations centers). События на полигоне соревнования были максимально приближены к реальности. В распоряжении команд находилась эмуляция города, в котором есть банк, телеком-оператор, офис крупного холдинга, электроэнергетическая компания и другие объекты. 

Андрей Дугин, участвовавший в CityF на стороне защиты, в своем блоге подробно описал ход соревнований и свои впечатления. С разрешения автора мы собрали все его публикации в один топик. 

Описание

17-18 мая 2016 года на конференции Positive Hack Days в Москве проводился характерный для крупных событий по практической информационной безопасности конкурс Capture The Flag (CTF). В этом году организаторы несколько модифицировали состязание, придав ему формат «противостояния» сил добра и зла в виртуальном городе, как и анонсировалось на сайте конференции PHDays.

Естественно, что желающих попробовать свои силы в конкурсе было немало. Участников разделили не на 2, а на 3 функциональных направления:

• Хакеры — естественно, их целью было получить несанкционированный доступ к защищаемым ресурсам.
• Защитники — как очевидно из названия, главной задачей является предотвращение взлома и/или быстрое устранение его причин и последствий.
• SOC — оперативный мониторинг подозрительных событий информационной безопасности, оповещение «защитников», совместный анализ и реагирование на инциденты.

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

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

По результатам двух дней «противостояния» вкратце скажу, что нам в партнеры как SOC досталась команда профессионалов из JSOC, с которыми мы понимали друг друга с полуслова (не рекламы ради, но констатации факта для). Настолько плотно, как с JSOC'ом в этом конкурсе, мы не всегда работали даже с «родственными» подразделениями в своей компании. Звучит пафосно, но это правда, из песни слов не выкинешь. 



Сборная команда телеком-защитников «You Shall Not Pass» из крупных операторов связи и Solar JSOC, команда «False Positive»

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

Получилось довольно интересно, но подробности состязания позже. Я во многих случаях пытаюсь понять изначальную причину любой трансформации в сторону усложнения. Логично, что конференция должна идти в ногу с мировыми тенденциями, но тут, возможно, на волне впечатлений от участия в состязании, скажу, что Positive Technologies, похоже, даже шагнула на полшага вперед (прогиб засчитан?) — надолго ли? (компенсация прогиба для сохранения нейтральности).

Итак, явных причин несколько, часть из которых является следствием других.

1. Обратить внимание государства и бизнеса на: 

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

2. Дать специалистам почувствовать, что такое работа при постоянной угрозе взлома инфраструктуры в некотором приближении к реальности (почему некотором — об этом позже).

3. Придать мероприятию масштабности.

4. Продвижение на рынке:

• продуктов и услуг информационной безопасности;
• тестирование и популяризация среди услуг ИБ такого сервиса, как SOC (Security Operation Center).

Что из вышеперечисленного первопричина, а что следствие — думаю, очевидно.
На полноту и широту анализа не претендую, потому что свой угол обзора описал ранее.

Подготовка

Итак, наша сборная команда защитников телекома в тандеме с JSOC защищала публичные сервисы на базе IP, характерные для оператора связи: личный кабинет, портал, сервисы отправки платных сообщений, прочий VAS и т.п. Конечно, неотъемлемой частью нашей задачи было обеспечение безопасности сетевого оборудования.

По поводу команды: нам пришлось работать с коллегами-конкурентами, с которыми мы до этого не были знакомы, и я, когда только узнал об этом, думал, что сначала мы, как в «Мстителях», пересобачимся друг с другом, определяя, кто круче, а потом начнем дело делать. К счастью, я оказался неправ, и причина банальна: у нас не было на это времени. Негласный принцип был такой: если ты крут — красава, молодец, мы в тебя верим, твой талант признаем и не оспариваем, РАБОТАЙ! А я просто пересмотрел боевиков.

В «виртуальном городе», где происходили вышеописанные события, было 5 объектов инфраструктуры, за которые и шла борьба:

• городской офис;
• банк 1;
• банк 2;
• энергетическая компания;
• телекоммуникационная сеть.

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

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

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

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

Рабочие места как таковые для нас отсутствовали, только ethernet для подключения ноутбуков и розетки электропитания. Но это нормально: мы бы только озадачили организаторов, чтобы унести ПК назад. За своим ноутом работать привычнее. Рабочие места в виде стационарных ПК были только у статистов-пользователей, которым надо было изображать активность среднестатистического юзера: читать почту, кликать вредоносные ссылки, сидеть в соцсетях и жаловаться, что мало платят. Взаимодействовать с пользователями было запрещено.

Карта сети содержала исключительно L3-информацию по подсетям и их топологическому расположению. Что в какой сети находится — нужно было выяснить самостоятельно. С одной стороны — усложнение задачи, с другой — лишний впрыск драйва. То есть, чтобы найти и обезвредить сервера, мы использовали ARP-таблицы L3-терминирующих устройств и сканнеры, разворачивали элементы инфраструктуры типа всусов и т.п., обновляли, переконфигуряли, интегрировали… Все это, в том числе и сетевое оборудование, было на виртуалках. На установочной встрече Сергей Павлов из Positive Technologies обещал, что вычислительных мощностей будет, по крайней мере, больше, чем у него на домашнем компе, и, похоже, не обманул. Но потело это оборудование от нагрузки знатно, мы-то не стеснялись в запросах необходимых виртуалок, да и хакеры запускали вагон сканов одновременно.

По средствам защиты информации: я было полагал вначале, когда Гена только-только начал нас пинать, что «Позитивы» как организаторы будут пытаться навязать свои продукты и решения для их пиара, ан нет, была не только полнейшая свобода выбора любых средств, но и активное содействие в получении временных лицензий у любых коммерческих поставщиков. Это тоже легко объясняется: загоняя в рамки использования своих продуктов, организаторы ограничили бы защитников, резко превратив противостояние в публичное тестирование и дали бы пространство для обвинений в рекламе и манёвра по отмазкам в случае резонансного взлома. Да я и сам какой-нибудь жесткий косяк в защите старался бы списать в этом случае на впаренное решение, что греха таить. Плюс, если навязываешь для реального противостояния — изволь обучить довольно глубоко и бесплатно, да еще дай золотой саппорт на время конкурса, потеряв свои человекочасы, что явно не входило в планы организаторов.

А так: уважаемые защитники и «соки», вот вам глоток свободы, смотрите, не захлебнитесь. Будет все хорошо — ну и ладно, если же будет все не совсем хорошо, всегда можно сказать: «А вот если бы у вас был наш MaxPatrol сканнер или MaxPatrol SIEM...», а можно и не сказать, в зависимости от ситуации. Правда, не слышал пока, чтобы такое говорили или даже намекали.

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

Мнение о резонансном взломе ГЭС

Бои без правил. Организуется поединок между бойцами Орком и Гоблином. Бойцы начинающие, но публика козырная и при деньгах. Влиятельный любитель таких боев, чиновник, крышующий организаторов, делает очень крупную ставку на то, что Гоблин победит. И тут Орк наносит хороший удар в корпус, после которого Гоблин «плывет». Судья, вопреки правилам, засчитывает это как удар в пах, отводя в сторону Орка со штрафным очком и предоставив время на восстановление Гоблина. В процессе быстро шепчет Орку: «Тебе нужно лечь. Папа сказал». И Орк, отлично понимая, что даже если он победит и заберет приз, то в будущем карьера бойца в этой организации для него закрыта, начинает быстро соображать, глядя на постепенно приходящего в себя Гоблина, как подставиться под «нокаутирующий» удар, чтобы было правдоподобно и убедительно для зрителя.

Уже на следующий день после PHDays VI весь интернет пестрел новостями о том, как школьник взломал электростанцию и как хакеры после успешного взлома остановили ГЭС и затопили город. 

Я участвовал в составе «защитников» телекома, поэтому мнение основано на анализе ситуации и аналогиях с моей колокольни, но без знания деталей взлома SCADA.

Как я писал в первой части своей серии отзывов о PHDays, одной из ключевых для организаторов целей было обратить внимание государства и бизнеса на необходимость защиты «интернета вещей» и других подключаемых к публичным сетям систем управления критической инфраструктурой. Хотя сам и не работал с защитой SCADA, но по публичным источникам вижу, что когда любое устройство начинает управляться по IP, а тем более через Интернет, на его безопасность мало кто обращает внимание. Как всегда, сначала развиваются технологии, а потом уже их безопасность. В итоге образуется «интернет дырявых вещей». Чем это может грозить — зависит от того, к какому устройству получить доступ. Донести до общественности это можно через новости, а чтобы привлечь журналюг — нужно то, что будет воспринято как сенсация. А куда уж сенсационнее, чем остановка электростанции и затопление города хакерами, которых воспринимают, как максимум, мальчиками с осанкой обезьяны за ноутбуком, умеющих воровать пароли?



Изображение: Xakep.ru

Есть команда «защитников», которые захарденили системы управления. Есть SOC, который подключил все на мониторинг событий. Детали подготовки описаны в одноименной второй части. Это, насколько я знаю, коммерческие компании в профилем информационной безопасности, которые на этом конкурсе, наверное, хотели бы попиариться, и поэтому отнесутся серьезно к защите промышленных объектов. И тут, несмотря на всю описанную серьезность защиты, ГЭС ломают 2 раза… Неужели так все плохо с ИБ АСУТП в России?

Мои варианты причин того, что произошло:

1. Защитники плохо защитили: либо нормальных средств защиты SCADA не существует в природе, либо халатно отнеслись к защите;
2. SOC недосмотрел: либо плохо интегрировали с мониторилками, либо прощелкали;
3. Ограничения организаторами на средства защиты;
4. Папа сказал.

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

Чтобы не быть голословным с утверждением об ограничениях со стороны организаторов, скажу как участник команды «защитников» телекома: ограничения на применение защиты были, и довольно крепкие. Дополнительные средства защиты используй какие угодно, но из фундаментальных средств нам запретили даже закрыть на firewall из мира SSH/RDP к защищаемым ресурсам, только к самому сетевому оборудованию, не говоря уже о других неиспользуемых сервисах. Меняй пароли, обновляй, патчуй, реконфигуряй сколько угодно, но сервис должен быть доступен… А я вообще хотел поставить default deny, как и делается в реальной жизни (подробности о степени приближенности к реальной жизни позже). Но мне не разрешили организаторы.

И стратегически это правильно: иначе не будет шоу, хакеры будут ныть, рассказывая, что это все нечестно, что организаторы дали колоссальное преимущество защитникам и сокам. Не будет впрыска нужной информации в СМИ, руководства промышленных предприятий будут отмахиваться от защиты. Пожертвовал пешку (SOC и защитники SCADA) в этой игре, но получил стратегическое преимущество на несколько лет вперед (будущие заказы от бизнеса и государства на обеспечение безопасности). А самое главное — мир задумался о том, как не дать плохи парням оставить людей без света и с чрезмерным избытком воды в городе.



Изображение: Xakep.ru

Если все так и развивалось, то больше всего не хотелось бы, чтобы во взломе ГЭС и затоплении города обвинили «защитников» и SOC, оборонявших SCADA.

Более внимательные коллеги и представители организатора поправили меня, уточнив, что защитников ГЭС действительно не сломали. После взлома защитники и SOC очень точно описали процесс взлома (то есть, всё видели, но не делали, ибо, все-таки, шоу надо) и хакеры это подтвердили. Похачить скаду получилось только после того, как защитники ослабили, а потом и совсем сняли защиту. Утром второго дня, оказывается, объявили это во всеуслышанье со сцены. Видать, я после бессонной ночи не особо был в состоянии воспринимать то, что там вещается.

Но, тем не менее, по прошествии нескольких дней я вижу в Интернете информацию не о том, что ГЭС не защитили, а о том, что ее взломали. И со временем из этой путанной фразы останется очевидным только то, что ГЭС можно взломать. Продолжая логику — а значит, ее нужно защитить. То есть, тень на доброе имя «защитников» и SOC если и упала, то очень быстро рассосется. Наверное, специалисты по пиару знают свое дело лучше, чем инженер по защите информации (не хватало еще, чтобы было наоборот).

Вот она, официальная информация от организаторов:

Форум наглядно показал, что бывает с незащищенной критической инфраструктурой. Специалисты по информационной безопасности в силах обеспечить очень высокий уровень защиты без нарушения технологического процесса — но развернуться так, как на PHDays, им дают очень редко. После отключения средств защиты нападающие проникли в технологическую сеть АСУ через корпоративную, атаковали физическое оборудование системы, взломали ГЭС, провели сброс воды, отключили линии электропередачи.

Ограничения

На официальном сайте конференции есть довольно пафосная цитата:

На этот раз вместо привычных соревнований CTF, мы устраиваем настоящие военные действия. События на площадке будут максимально приближены к реальности: на полигоне PHDays VI СityF развернется масштабная эмуляция городской инфраструктуры.

Вот насчет выделенного жирным и хотелось бы поговорить.

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

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

Default permit. С другой стороны, было запрещено выполнять default deny на пограничном firewall. А в реальном мире так делается в первую очередь. Это меня возмутило до глубины души, я плакал и матерился, но продолжал участвовать в конкурсе. Как я уже раньше и писал, одной из основных целей «противостояния» было шоу, которое не получилось бы, запрети я все лишнее. Хакеры потыкались бы в засекуренные интерфейсы, ничего не сделали бы, и обхаяли организаторов в потакании светлой стороне силы. Так что здесь приближение к реальности практически нулевое. Дали хакерам фору по самые помидоры. Из-за таких фор и ГЭС поломали, и город затопили.

No ban for IP-address. Запрещено было также банить по src IP. Естественно, если бы это было просто запрещено словами, то я бы мог и «подзабыть», особенно на ночь, чтобы спокойнее спалось, да и вообще чтобы спалось. Но хитрые организаторы натили всех в один IP: и хакеров, и свой service-checker. Если мы гасили лишнее — прибегали к нам и говорили, что ай-яй-яй, так нельзя. Причем сервисы проверяли вообще любые, которые были изначально доступны на серверах, даже на фиг не нужные. Шоу, чо.

Тоже курьез получился в самом начале противостояния: SOC обнаружил, что нас кто-то сканирует с IP-адреса, который никак не указан на предоставленной схеме. Найдя точку стыка, я заблокировал его, выведя неизвестную подсеть из маршрутизации, несмотря на запрет. Точка стыка была внутри доверенного сегмента, поэтому логика простая: на схеме нет — считаю за закладку и происки хакеров, которые должны быть выдавлены из нашей сети. Естественно, сначала прибежали организаторы с криком: «Все пропало! Наше все не работает!». Потом поняли, что не пересобрали стык с нашим сегментом, и согласились с моими действиями.

Доступ к оборудованию. Нам, конечно, предоставили админский доступ и к сетевым устройствам, и к серверам. Ведь сложно защищать то, что не можешь конфигурировать. Возможно, но сложно. К активному сетевому оборудованию уровня L2-access доступа не дали. Причина проста: шоу. Когда организаторы замечали уныние на хакерских физиономиях и скуку на наших — поднимали где-то без предупреждения еще один уязвимый сервис. Ну а SOC с защитниками, соответственно, начинают: «лови его, дави его!». Чтобы мы не мешали лишними секурити-настройками и не видели лишнего, доступ к свичам доступа нам не давали и как объект защиты их нам не вручали.

Вроде, ничего не забыл. Если вспомню — допишу. В общем, ограничения хоть и были, но не лютые. Конечно, default permit до сих пор будоражит мое потревоженное мировоззрение, о чем я периодически продолжаю ворчать в разговорах с организаторами, но шоу есть шоу. Это был реслинг, а не MMA.

Сражение

Стоит приступить к описанию самого процесса противостояния — так сказать, битвы, которая длилась 29 часов — с 11:00 17 мая 2016 по 16:00 18 мая 2016.

Предварительно командами защиты и оперативного реагирования было проведено:

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

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

Схема сети (упрощенная, без филиального офиса) была приблизительно такой:



Интернет был псевдо-, а не настоящий, хакеры попадали в него из ограниченного сегмента. Будь Интернет настоящим, нельзя было бы понять, где атака участника соревнований, а где посторонний хакер, да и гарантии, что кто-то не психанет и не начнет DDoS, не было.

Первым делом я решил засекурить периметр, то есть, навесить на влет со стороны Интернета ACL, который разрешал бы обнаруженные сканом порты серверов DMZ, кроме управляющих (SSH/TELNET/RDP/SNMP) и баз данных (MySQL, Oracle), а остальное закрыть по принципу default deny. Предупредил организаторов, и сразу получил отказ: нельзя, все порты из псевдоинтернета должны быть доступны. Описать мою реакцию можно двумя словами «удивился» и «возмутился», которые выражаются одним словом вместе.



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

• патчить дырявые сервера в DMZ;
• навесили ACL на сервера в подсетях Servers1 и Servers2, разрешив к ним доступ из DMZ и админов (организаторы);
• перенесли сканер безопасности, развернутый изначально в DMZ, в подсеть Defense_servers — не хватало еще, чтобы сканер похачили;
• к серверам в подсети Defense_servers запретили доступ отовсюду.

Как я уже упоминал в первой части, с нами в тандеме работал JSOC, который интегрировал инфраструктуру со своим SIEM и мониторил подозрительную активность. Стоит отдать ребятам должное, они мало того, что взяли под колпак любой чих (процессы, входы, сетевая активность) инфраструктуры, так еще и мониторили c экстрасенсорной оперативностью. Вначале, пока не выучили IP-адреса друг друга, меньше чем через минуту после действия мы слышали от них вопросы: «кто зашел на сервер ххх с адреса ууу?», «на сервере поменялся sshd — это что?» и т.п… Ну и отвечали им типа: «нормально, свои, это я, обновил дырявый сервак». Если они так же и коммерческих клиентов мониторят, то аплодисменты, рекомендую.

Периодически, когда организаторам становилось грустно и заканчивались темы для рассказа на сцене, хакерам — уныло, а нам — скучно, Миша Левин щелкал пальцами — и в DMZ появлялся дырявый сервак. Щелкал не над нашими ушами, поэтому мы обнаруживали это дело сами, и дальше начинали думать, что за сервак, сканить, патчить, менять легкие пароли. Прямо как распорядитель Голодных игр в одноименной саге о Зойке-Пересменщице, где выпускалось что-то противоестественное, если трибуты долго не умирали.



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

Только в самом начале, как я уже писал в четвертой части, зафиксировали скан из участка сети, не показанного на схеме. А моя логика как сетевого безопасника простая: раз на схеме сети участка не было — значит, непорядок. Мало ли, может, по условиям соревнований у нас в сети была закладка, которую нужно найти и обезвредить. Поэтому я, быстро обнаружив статический маршрут на проблемную подсеть в сторону неизвестного девайса, сначала навесил ACL на интерфейсах. Заблокировали его — и сразу организаторы предъявили, что у них все пропало и надо вернуть. После недолгого спора пришли к выводу, что это уже перебор. Хотите сканить нас и проверять доступность сервисов — стыкуйтесь со стороны псевдоинтернета и оттуда хоть непрерывно творите безобразия. В итоге стык пересобрали, проблемную сеть я из маршрутизации вывел.

Ближе к вечеру первого дня оказалось, что хакерам сказали не ту сеть, они в большинстве своем сканили нечто несуществующее и порядком приуныли. Тогда мы поняли, что теперь как раз и начнется самый смак. Кроме того, чем дальше, тем больше и чаще начали подниматься дырявые сервера, и к ночи наш DMZ начал становиться похожим на дуршлаг. Сервера взлетали как юниксовые, так и виндовые. Результаты сканов новых серверов показывали уязвимости, в основном PHP, OpenSSL и SSH. Собственно, работы на ночь нам насыпали, чтобы не скучно было. Да еще постоянный риск, что темная сторона силы быстрее обнаружит эти дырки, нас крепко подстегивала. В общем, поспать нам толком не дали. С ночевкой на соревнованиях был SOC всем составом, кроме их босса, и трое от защитников. Ребята умудрились немного поспать, а мне, видать, страх быть похаченным мешал, поэтому я все время что-то делал: то по работе, то по соревнованиям.

PHP, насколько я помню, был 5.3.<чегототам> и 5.4.<чегототам> еще мохнатых 2013-2014 годов. Приходилось обновлять, потому что хакеры первым делом будут ломать веб. Сразу до свежачка не обновлялось, приходилось через тернии по шагам минорных версий топать.

SSH практически везде был уязвим по CVE-2015-5600, что означало отсутствие защиты от перебора паролей и перегруза CPU. Прям как на заказ подобрали. Самое интересное, что не во всех репозиториях были пропатченные на этот случай обновления, нужно было обновлять из исходников. Похожая ситуация и с OpenSSL. Если с последним никуда не денешься, приходилось врукопашную работать, да и меньше их было на порядок, то с SSH я дико возленился делать одно и то же на всех серверах DMZ. И в ходе ночных размышлений мне пришла идея завернуть весь SSH и RDP, который прилетает на сервера DMZ из псевдоинтернета, через Balabit SCB, который я поставил, думая, что смогу прозрачно завернуть через него управляющие протоколы для контроля. До сих пор удивляюсь, как мне пришла эта идея, но она оказалась очень результативной. Итоговая архитектура, несмотря на ее определенную комплексность и трудность в тиражировании на большие инфраструктуры, на соревнованиях нас практически спасла от атак на SSH.

Несмотря на то, что Balabit используется как средство контроля управляющих сессий, а также дополнительно может выступать в роли интеграционной прослойки при управлении плохо/частично/никак интегрированными сетями, ночью с 17 на 18 мая ключевым фактором его применения оказалась неуязвимость проксирующего модуля zorp-ssh к CVE-2015-5600.

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

Ночью, как и ожидалось, поперли сканы, а на второй день началось восстание машин, когда новые дырявые сервера начали расти, как грибы после дождя. Миша Левин махнул рукавом — и все козыри высыпались в DMZшную подсеть.

В общем, 18 мая у нас прошло довольно интенсивно. Хорошо, что днем нас больше, можно распараллелить задачи и хотя бы быстро пообедать. Справедливости ради скажу, что один из дырявых веб-серверов, выросших на второй день, темная сила таки успела похачить через веб, получив единственный «флаг» с нашего тандема. Сервер никак не был взаимосвязан с телекомовским бизнесом и отразился на нас только в виде галочки о снятом флаге. Обнаружил его JSOC через 5 минут, причину мы диагностировали моментально, после чего активировали блокирующую сигнатуру на IPS (была по дефолту в режиме мониторинга и верещала алерт) и пропатчили сервер.

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



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

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

Нестандартный метод защиты SSH

— Почему нам нельзя перенастраивать сетевое оборудование, если мы его защищать должны? Без этого никак.
— А, вы телеком-защитники. Тогда вам можно, но сервисы должны быть доступны и чтобы не терялось управление. Иначе мы подойдем к вам и спросим: «Что за дела?». Если не сможете быстро починить — вернем к настройкам до начала соревнований, а вам выставим штрафные баллы. Поэтому с изменением сетевых настроек будьте аккуратны.
— Это не проблема. А если для обеспечения безопасности нам нужно будет развернуть трафик по-другому, завязать узлом, но при этом все будет работать?
— Тогда мы придем к вам с бумажкой — записать, что и как вы делали, интересно ведь.

— А зачем ты на Positive Hack Days решил Balabit использовать? Чем он там поможет?
— Будем админов мониторить. Они обещали периодически на серверах взводить дырявые сервисы.
— Ну, как знаешь.

Это два реальных разговора при подготовке к PHDays. До определенного момента я сам не думал, что они будут настолько плотно взаимосвязаны. Естественно, после разговора с организаторами я подумывал, что надо бы и удивить, раз грозился. По ходу соревнований вектор настроения потихоньку сдвинулся от первоначального желания в сторону «забетонироваться». Но чудесным образом получилось так, что в итоге они слились. И об этом пойдет рассказ.

Как я уже писал в части 5, и говорил на сцене PHDays, довольно интересное и нестандартное у нас получилось решение по защите уязвимых серверов Unix, управляемых по SSH.

Напомню, сама по себе архитектура упрощенно выглядела следующим образом:



Но, как упоминалось в части 4 и части 5, использовать ACL на firewall с правилом default deny нам не разрешили организаторы. Поэтому изначально из псевдоинтернета трафик шел к серверам DMZ по всем протоколам и портам. Но сейчас речь пойдет об SSH. 

Сервера, которые нам поставили в DMZ, практически все были уязвимы к CVE-2015-5600, что означало отсутствие защиты от перебора паролей и перегруза CPU. Совмещаем эти 2 условия — и получаем идеальную для хакеров ситуацию: «Не подберу — так хоть завалю». При этом, начиная с вечера первого дня, сервера появлялись, как тараканы в общаге. SSH был дырявый везде. Обновления, содержащие фикс к указанной уязвимости, были далеко не во всех репозитариях. То есть, зайти единоразово на все линукса разных версий и втоптать пару команд, чтобы дальше оно само — не вариант. Только сырцы, только хардкор. Лень — двигатель прогресса. Возможно, человек, плотнее в повседневной жизни работающий с Open Source решениями и Unix, пошел бы в сторону реализации своего репозитария либо еще как, но во мне в 3 часа ночи проснулся архитектор. 

Я вспомнил об одиноко стоящем Balabit SCB, который, несмотря на игнор первого дня, исправно крутился и жрал некоторые ресурсы вычислительной инфраструктуры организаторов. Поскольку я настраивал еще самую первую инсталляцию Balabit в СНГ, не считая остальных в течение нескольких лет, мысль попробовать пустить через него SSH смотрится вполне закономерно.

Настроив пару проксирующих правил на Balabit, я его просканировал. Модуль проброса SSH zorp-ssh оказался неуязвимым к CVE-2015-5600, равно как и к другим, известным на тот день сканеру MaxPatrol, уязвимостям. Теперь осталось придумать, как разделить трафик таким образом, чтобы SSH к серверам в DMZ балабитизировался, а остальные протоколы шли своим обычным путем. 

Рассмотрим на примере SSH, но таким же образом можно поступить и с RDP, и с Telnet, и с VNC, и с ICA (правда, чуть попотеть).

По задумке, реализованной в схеме сети, к серверам из DMZ хакеры попадали по всем протоколам и портам, проходя через пограничный firewall.



Поскольку как пограничный firewall использовался не ACL на роутере, а CheckPoint, стандартные для firewall фичи типа NAT можно было настраивать во всю мощь. Как firewall, защищающий сервера «ЦОД» — Cisco ASAv.
Чтобы не запутать в сетевых терминологиях и реализации NAT двух разных производителей, опишу вендорнезависимую концепцию, применимую на оборудовании любых производителей, поддерживающих такую технологию. 

Для заворота трафика SSH на Balabit можно пойти такими путями:

1. Выделенные порты для серверов.

• Выделить диапазон портов на Balabit.
• Реализовать динамический NAT many-to-one на пограничном CheckPoint таким образом, чтобы пакеты, прилетающие из псевдоинтернета в направлении серверов DMZ на порт SSH, транслировались в пакет, где src ip подменяется на IP CheckPoint, dst ip — на IP Balabit, dst port — на выделенный для этого сервера порт на Balabit.

• Открыть доступ для этих TCP-сессий на вход в Firewall ЦОД:

• Настроить правила проксирования на Balabit с возвратом на нужный сервер, порт 22 (SSH):

• Разрешить выход таких пакетов с Balabit в сторону DMZ на обоих firewall:

Готово. SSH-сессия функционально не нарушена, другой трафик не задет, условия игры соблюдены.

2. Выделенный пул адресов.

• Выделить в ЦОД подсеть той же размерности, что и DMZ.
• Поместить в нее интерфейс Balabit, принимающий трафик.
• Настроить маршрутизацию.
• Сконфигурировать Balabit с IP-адресами той же подсети.
• Реализовать статический NAT one-to-one на пограничном firewall:

Можно, конечно, и не прятать SRC IP за адрес CheckPoint, но тогда необходимо, чтобы DMZ строился на серых адресах. На «противостоянии» DMZ строили на «белых»…

• Разрешить входящий трафик на Firewall ЦОД:

• Настроить правила проксирования на Balabit:

• и разрешение на обоих firewall:

где Balabit_ip0 — адрес Balabit, сконфигурированный на интерфейсе как основной, а не IP alias (Balabit_ip1...4). Можно, конечно, настроить так, чтобы src ip был Balabit_ip1...4, но в ситуации на PHDays это было лишним.

Готово. SSH-сессия функционально не нарушена, другой трафик не задет, условия игры соблюдены. 

***

В обоих случаях, чтобы иметь возможность пускать определенные подсети на сервера DMZ мимо Balabit, необходимо на пограничном firewall перед описанными правилами поставить такое:



Учитывая то, что остальные правила срабатывают по умолчанию после описанных, в итоге схема прохождения трафика получается следующей:



Видно, что подобное решение немного напрягает при масштабировании его на большое количество серверов. Нельзя сделать «настроил и забыл» для всей подсети одной строкой. Дополнительные затраты времени вызывает необходимость:

• В случае 1 — добавления правила для каждого нового сервера DMZ и на Balabit, и на firewall.
• В случае 2 — разработка сетевого дизайна и настройка сети (единоразово), а также добавление нового правила на Balabit для каждого сервера DMZ.

То есть, в обоих случаях — настраивать Balabit для каждого сервера. Задача, по сути, не громоздкая, занимает 5-10 минут, и при статичности жизни сервера вполне терпима, но если все часто течет и меняется…

Оба этих ограничения связаны с тем, что сеть с точки зрения L3 была плоской, с одной таблицей маршрутизации. Есть решение, которое помогло бы прозрачно балабитизировать всю подсеть одним махом, а там хоть каждую секунду добавляйте-удаляйте сервера в подсети. Но для этого потребуется единоразово настроить MPLS L3VPN либо vrf lite на активном сетевом оборудовании (если поддерживает) и аккуратно соединить с его помощью Balabit и пограничный firewall.
Но это уже тема для совсем отдельной статьи…

Вижу немой вопрос в глазах читателей: а как же ты настроил на PHDays?
Ответ: по варианту №1 – выделенные порты.

Выводы

Итак, описав в шести частях наше участие в противостоянии, неплохо было бы сделать выводы по результатам соревнований. Несмотря на то, что нас не победили, я понял, что нам еще есть куда расти как защитникам. Противостояние дало возможность поработать в считающихся нереальными условиях абсолютного админского косяка: default permit на пограничном firewall и неконтролируемое появление дырявых серверов в DMZ. Как некоторый итог, для проверки степени защищенности инфраструктуры необходим определённый checklist, с которым нужно сверяться.

Чтобы не распыляться на большое количество слов и фраз, я возьму за основу SANS Top 20 Critical Security Controls, в котором описаны точки контроля ИБ. Они применимы как к соревнованиям, так и к реальной жизни. В табличке попробую несколько разграничить зоны ответственности защитников (DEF) и SOC, несмотря на то, зачастую они плотно переплетаются.

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

№	Control name	DEF	SOC
1	Inventory of Authorized and Unauthorized Devices	+	+
2	Inventory,of Authorized and Unauthorized Software	+	+
3	Secure Configurations for Hardware and Software on Mobile Device Laptops, Workstations, and Servers	+	+
4	Continuous Vulnerability Assessment and Remediation	+	+
5	Controlled Use of Administrative Privileges	+	+
6	Maintenance, Monitoring, and Analysis of Audit Logs		+
7	Email and Web Browser Protections	+
8	Malware Defenses	+	+
9	Limitation and Control of Network Ports, Protocols, and Services	+
10	Data Recovery Capability
11	Secure Configurations for Network Devices such as Firewall Routers, and Switches	+
12	Boundary Defense	+
13	Data Protection	+	+
14	Controlled Access Based on the Need to Know	+	+
15	Wireless Access Control
16	Account Monitoring and Control		+
17	Security Skills Assessment and Appropriate Training to Fill Gaps	+	+
18	Application Software Security	+
19	Incident Response and Management		+
20	Penetration Tests and Red Team Exercises	+	+

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

Какие ошибки мы допустили в противостоянии с хакерами:

1. 
2. 
3. 

Во избежание подобных ошибок я вижу такой перечень действий на будущее:

1. 
2. 
3. 

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

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

P. S. Агрегировав весь свой поток подсознания по результатам участия в соревнованиях PHDays «Противостояние», я перевел его на более-менее официальный язык и описал смысловое наполнение в одной статье для журнала «Системный администратор». С текстом статьи можно ознакомиться в июньском выпуске по ссылке.