![Подслушано: кибербезопасность в дата-центрах - 1 Подслушано: кибербезопасность в дата-центрах - 1](https://www.pvsm.ru/images/2021/07/03/podslushano-kiberbezopasnost-v-data-centrah.png)
Осенью 1988 года в пригороде Бостона произошло знаменательное событие — примерно 6 тысяч узлов компьютерной сети ARPANET были парализованы вредоносной программой, написанной аспирантом факультета вычислительной техники Корнеллского университета. Червь Морриса, а именно такое название присвоили программе по фамилии автора, многократно заражал узлы сети и доводил их до состояния отказа в обслуживании. Именно это событие считается одной из ключевых вех в развитии компьютерной безопасности.
За 32 года многое изменилось: атаки становились более изощренными, а защита более интеллектуальной. Пару недель назад мы собрались вместе с ведущими Zavtracast устроить срыв покровов дискуссию вместе с нашим директором по развитию продуктов, Александром Туговым fortyseven, и архитектором систем информационной безопасности, Антоном Ведерниковым. Темой дискуссии стала кибербезопасность в дата-центрах. За подробностями добро пожаловать под кат.
Для любого провайдера инфраструктуры обеспечение безопасности своих систем задача архиважная, особенно в наш век, когда появляются новые векторы атак, такие как вирусы-вымогатели, автоматический целевой фишинг и дипфейки. Сложность и эффективность подобных атак заставляют защищаться с помощью аналогичных методов, используя возможности искусственного интеллекта и машинного обучения.
Смысл подобной защиты состоит в том, чтобы создать некий паттерн нормального состояния инфраструктуры, а затем отслеживать аномальные отклонения. Если раньше для реализации использовались статистические методы, то сейчас для этого задействуется машинное обучение. Так что если самый обычный пользователь внезапно начинает создавать необычную активность, ранее нехарактерную для него, то нейросеть на это реагирует и создает событие безопасности: «Безопасник/инженер, посмотри, у тебя здесь происходит такая штука».
И вроде бы такой способ практически идеален, но внезапно обнаруживается, что создав подобную систему безопасности, мы открываем ящик Пандоры и создаем целый класс новых угроз. Слабым звеном становится сама нейросеть, ведь видоизменив данные, подаваемые на вход, можно заставить ее выдавать неверный результат, а следовательно и предотвратить срабатывание. На Хабре, кстати, была замечательная статья о различных способах обмана нейросетей.
Тут начинается повышение ставок и можно пойти по пути натаскивания нейросети на подобные ситуации, либо же обучения на общих паттернах. Любая атака производится не с нуля. Есть уже существующие инструменты, техники и тактики, часто используемые в определенных последовательностях. Причем разные группировки задействуют разные наборы этих техник и тактик. Сопоставляя состояния системы можно распознать и шаблонизировать атаки, а затем определить порядок реагирования на них.
Такое страшное слово — фишинг
Конечно, следует понимать от чего и от кого защищаться. Технические методы — это прекрасно, но социальный инжиниринг никто не отменял. Развести на что-нибудь не очень умный мешок с мясом беспечного специалиста становится значительно более существенной угрозой, даже для систем, не подключенных к внешним сетям. С этой точки зрения, технологии создания дипфейков становятся поистине страшным оружием. Представьте, что вам звонит непосредственный руководитель и знакомым вам голосом отдает распоряжение выполнить какие-то действия.
![Подслушано: кибербезопасность в дата-центрах - 2 Подслушано: кибербезопасность в дата-центрах - 2](https://www.pvsm.ru/images/2021/07/03/podslushano-kiberbezopasnost-v-data-centrah-2.png)
Как защититься? Все просто — педантично соблюдать рабочие регламенты и распоряжения отдела внутренней безопасности. Регулярное обучение и повышение осведомленности дают хороший результат.
У нас в Selectel, например, иногда проводятся тестовые фишинговые атаки, когда прилетает письмо от какого-то партнера или сотрудника, цель которой заставить пройти по ссылке или предоставить какие-либо данные. На основе этого потом проводится разбор инцидента – ребята, мы проводили учения, такая-то статистика. Организуется обучение, почему это нельзя делать, как выявить эту фишинговую атаку, какие-то базовые вещи, домен отправителя. Лучше вообще никуда не переходить, а сразу писать в отдел внутренней безопасности.
Также часто бывают ситуации, когда фишинговой атаке подвергается саппорт. Звонки из разряда «сбросьте пароль на моем сервере» или что-нибудь такое. Мы постарались изначально защититься от такого, поэтому вся поддержка осуществляется только через тикет-систему. Ни через email, ни по телефону. Для создания тикета требуется пройти авторизацию, что однозначно гарантирует идентификацию обращающего. Вариант, когда у клиента был скомпрометирован логин и пароль от панели управления мы не берем сейчас во внимание — это уже очень плохо, крайне плохая ситуация.
Иногда случаются кейсы, когда на почту прилетают письма с непонятного корпоративного домена «Это мой сайт. Пришлите бэкап, логи, данные» или нечто подобное. Таким нехитрым способом раньше частенько пытались присвоить чужую интеллектуальную собственность или даже навредить, к примеру «Срочно отключите сервер!!!». Сейчас таких случаев все меньше и меньше, но тем не менее еще встречаются.
Правила и исключения
Естественно возможен вариант, когда случается ультра-дичь. Был случай, когда у клиента угнали доступ к панели и пытались что-то делать с его серверами. Саппорт видит с каких IP-адресов производятся авторизации. Поступил звонок с номера, привязанного к аккаунту. Звонящий просил выключить все его серверы. В панели при этом была авторизация с адреса, который никогда ранее не использовался для этого, а клиент обладал всеми данными, указанными в анкете. После максимально возможной валидации клиенту поверили, аккаунт заблокировали, а серверы выключили. Но такие случаи — это крайне редкое исключение из правил.
Теоретически возможен еще сценарий, когда угоняют аккаунт, арендуют виртуалки и с их помощью проводят какие-либо атаки. Но тут свою роль уже играют другие системы защиты. С нашей стороны есть антиспуфинг IP-адресов, который не позволяет выпустить в мир пакеты с подделанным адресом, а также системы скоринга, об одной из которых мы не так давно писали здесь же, на Хабре. Такая система способна самостоятельно принять решение о блокировке аккаунта.
Сложность в том, что мы не можем смотреть внутрь систем клиентов, дампить сетевой трафик или логировать все его соединения. Поэтому приходится валидировать клиентов еще на этапе регистрации, к примеру у нас, чтобы что-то создать или запустить требуется подтвердить хоть какой-то номер телефона. Причем вариант с SMS отнюдь не надежен.
В интернете полно сервисов одноразовых SMS, которыми часто пользуются спамеры. За условные 3 копейки можно запросить содержимое SMS через API и полностью автоматизировать процесс. 100, 200 регистраций в час из одного места, и это не предел. Так что у нас теперь используется телефонный звонок в качестве подтверждения, что значительно сложнее подделать и автоматизировать.
Большая часть недобросовестных регистраций происходит с зарубежных IP-адресов. Как только находят уязвимый сервис, то начинают массово ломиться, регистрируя сотни и тысячи фейковых аккаунтов. Но проблема тут в том, что наши клиенты за границей тоже есть. Чтобы отделить их нам пришлось внедрить систему рейтинга, так называемый «индекс доверия». Мы смотрим на страну IP-адреса, методы оплаты и многие другие параметры, выставляя на основании этого условную оценку от 0 до 100 баллов. Затем аккаунт проходит множественные проверки. Каждая проваленная проверка эти баллы снимает. Когда доходит до 0, аккаунт блокируется.
Такая система не идеальна, но позволяет соблюдать баланс между безопасностью, удобством, комфортом и обоюдным доверием между нами и клиентом. Мы не нарушаем приватность и конфиденциальность пользователей и одновременно ставим такие барьеры потенциальным злоумышленникам, которые практически убивают экономическую целесообразность проведения атак.
Об оверлейных сетях и DDoS-атаках
Многие средства массовой информации частенько поднимают темы, такие как Darknet и связанные с ним легенды. И если не особо вдаваться в детали, то кажется, что там как раз находятся самые опасные злоумышленники и самые изощренные векторы атак. Тут следует сразу обозначить такой момент, что сам по себе Darknet — это не какая-то единая глобальная сеть, а всего лишь условное название разных оверлейных сетей, работающих поверх интернета. Каждая из этих сетей создавалась с целью обеспечения анонимности и все они различаются по архитектуре и способу реализации.
Тут также следует понимать от кого защищаемся и пытаемся добиться пресловутой анонимности. Если от интернет-провайдера или владельца какого-либо ресурса — тогда задача вполне выполнима. Но если же от спецслужб государств, то наверное, это бесполезная вещь. Проблема в том, что такая сеть рассчитана на то, что состоит из какого-то определенного количества узлов и чем их больше, тем выше условная анонимность. Если же взять под контроль некое значительное количество таких узлов, то в итоге можно деанонимизировать часть клиентов, даже несмотря на стойкое шифрование и различных методик сокрытия/маскировки трафика.
Часто сбой дает даже не технология, а социальные аспекты активности человека. Могут сыграть роль даже часы активности и устройства, никак не связанные с анонимными сетями. Была в Советском Союзе такая байка, что студенты МГУшники решили приколоться и передавали друг другу в забитом московском метро несколько недель обычный пустой чемодан и выходили на разных станциях. На десятый раз их приняли КГБшники. Это к вопросу про то, что подобная активность двусторонняя, за ней следят все.
Что касается атак, проводимых их таких сетей, то тут тоже есть свои особенности. Такие оверлейные сети, как I2P работают достаточно медленно, что почти сразу ставит крест на скоростном брутфорсе паролей и прочих простых радостях мамкиных хакеров злоумышленников. Дело в том, что анонимности ради данные разбиваются на части и пересылаются от узла к узлу разными маршрутами. Чем маршрут длиннее, тем анонимность выше, но и конечная задержка выше, так что тот же DDoS через I2P реализовать крайне проблематично. Атаки уровня приложения тут представляют большую угрозу.
Раз уж коснулись темы DDoS-атак, то наверное стоит обговорить главный вопрос практически каждого клиента, который к нам приходит: «Если меня будут DDoSить, что тогда?». И здесь стоит принять во внимание, что DDoS-атаки бывают разные. Есть такие, которые направлены на то, чтобы забить канал связи, есть те, которые атакуют на уровне протокола или уровне приложения. Так что возможны варианты.
Если нам, как IaaS-провайдеру, атака способна нанести ущерб, то мы защитим свою инфраструктуру, дропнув весь трафик в адрес атакуемого клиента. Если атака уже на уровне выше, то клиент может либо защищаться самостоятельно, либо приобрести у нас дополнительную услугу по защите от DDoS-атак, пропуская трафик через узлы очистки. Некоторые наши сервисы, такие как Облако на базе VMware по умолчанию защищены от простых DDoS-атак. Имеется в виду простых по сложности, а не по объему. В обозримом будущем, вероятно, такую защиту получат все наши сервисы.
Если клиента регулярно атакуют, то мы можем предложить ему подключить защиту. Есть разные тарифы, от относительно недорогих (к примеру, 3000 рублей в месяц) до сложных и развесистых за сотни тысяч. Цена будет зависеть от того, насколько изощренные атаки использует атакующая сторона и насколько сложная защита должна быть выстроена для того, чтобы их отбить. Для этого мы задействуем партнерские решения от топовых компаний на рынке, таких как Qrator, DDoS-Guard и прочих. Через них можно защититься по-факту от любых атак.
Здесь основную роль будет играть финансовый вопрос. Кому-то проще на пару часов «прилечь», чем оплачивать дорогую защиту. Разумеется, аналогичный вопрос возникает и у атакующего ведь чем более сложная атака, тем она и стоит дороже. В итоге вопрос сводится к тому, у кого больше денег или кто сдастся раньше и скажет: «все, дальше не выгодно его атаковать, слишком дорого» или наоборот — «я на защиту потрачу больше денег, чем потеряю просто с простоя».
В последние 5 лет DDoS-атак стало значительно больше, в основном из-за распространения Internet of Shit. К сети подключаются всяческие «умные» лампочки, телевизоры, пылесосы, холодильники и еще сотни видов разного рода устройств, отвратительных с точки зрения безопасности. Так что безумные сценарии, вроде «миллионы пылесосов Xiaomi начали переходить на сайт парикмахерской в Сызрани» становятся вполне реальными. Mirai тому подтверждение.
Вопрос даже не во взломе таких устройств, а в том, что у них часто остаются открытыми оболочки Telnet или SSH. Можно заливать любые скрипты и делать вообще все что вздумается. Просто дичь! С тех пор это стало головной болью, так как атаки стали более распределенными и сложными. Организовать защиту, когда тебя атакуют не 100 тыс адресов, а 100 млн, да еще и с такого же количества разных устройств — крайне трудная задача.
Страшно то, что большая часть этих устройств так и останется незащищенными, ведь для того, чтобы это сделать придется сменить прошивку. Если модель плохо или вообще адекватно не поддерживается производителем, то ничего с этим сделать нельзя. Были истории, когда уязвимые прошивки беспроводных модулей некоторых смартфонов заражались вредоносным ПО, атакующим все Wi-Fi сети в радиусе приема. Чтобы такую уязвимость залатать, потребуется полностью пересобрать прошивку телефона, вот только никто в здравом уме кроме производителя этим заниматься не станет, SDK для таких модулей стоят на порядок дороже приобретения нового устройства.
Аппаратные закладки и программные уязвимости
Прошло почти 3 года с момента, как был грандиозный скандал, связанный с тем, что крупный производитель серверного оборудования, компания Supermicro была уличена в установке на материнские платы серверов крошечные шпионские чипы, позволяющие удаленно получать контроль над системой. По данным источников Bloomberg пострадало около 30 американских компаний, в том числе и компания Apple. Так что такой экзотический вектор атаки тоже можно рассматривать как потенциальную угрозу.
Как IaaS-провайдеру защищаться от таких ситуаций? Полностью защититься от того, что в очередной партии серверов не будет аппаратных закладок невозможно. Так или иначе встает вопрос доверия определенным вендорам и применяется риск-ориентированный подход. Но вероятность подобной атаки мала, ведь тут в игру вступает уже даже не отдельная сторона, а государство.
Если подобный вектор есть в вашей модели угроз и, предположим, аппаратная закладка существует — ее можно нейтрализовать полной изоляцией сети и правильной настройкой файервола. Закладка бесполезна, если она лишена связи с управляющим центром. Она никогда не получит команды и не никуда не сможет отправить информацию. Такой подход возможен и активно применяется.
У нас в Selectel есть услуга, позволяющая строить защищенные системы, когда клиенту отдается полное управление инфраструктурой. Никаких линков в наши коммутаторы, пограничный железный межсетевой экран, возможность установки дополнительных средств защиты, все что угодно для обеспечения конфиденциальности и приватности.
Если речь идет том, что при обнаружении 0-day уязвимостей мы имеем большую степень маневра — это так. Тесное взаимодействие с производителями серверного оборудования позволяет нам значительно быстрее реагировать на это, например, получая и применяя патчи напрямую, еще до того как они появляются в открытом доступе.Также мы стараемся всегда поддерживать прошивки всех компонентов серверов, к примеру BMC, в актуальном состоянии.
Вместо заключения
Эта статья для нас стала небольшим экспериментом и приглашением к дискуссии. Уверены, что для многих наши ответы чуть лучше прояснили ситуацию с безопасностью в дата-центрах, но тем не менее мы всегда готовы услышать вашу точку зрения и ответить на возникающие вопросы. Подписывайтесь на наш канал в Telegram и участвуйте в наших голосовых чатах, где мы обсуждаем самые разные и интересные темы в нашей сфере.
![Подслушано: кибербезопасность в дата-центрах - 4 Подслушано: кибербезопасность в дата-центрах - 4](https://www.pvsm.ru/images/2021/07/03/podslushano-kiberbezopasnost-v-data-centrah-4.jpg)
Автор: Николай Рубанов