Сетевое оборудование под угрозой? Давайте разбираться…02.12.2015 01:03

В последнее время мы наблюдаем определенную маркетинговую шумиху вокруг атак и уязвимостей в сетевом оборудовании. Зачастую это происходит вследствие вполне реальных событий, но чаще всего речь идет о низкопробной PR-активности отдельных исследователей или целых компаний, которые таким образом самоутверждаются, паразитируя на не очень активном освещении данной темы в среде специалистов, которые не всегда способны отделить зерна от плевел. Как ведущий производитель сетевого оборудования мы решили поднять завесу тайны и расставить все точки над i в вопросе возможности или невозможности атак на сетевое оборудование, взяв в качестве примера продукцию компанию Cisco.
SYNful Knock: что это и с чем его едят?

В сентябре 2015-го года американская компания Mandiant, входящая в состав FireEye, которая недавно обосновала снижение продаж своего оборудование тем, что китайские хакеры уменьшили свою активность, опубликовала заметку в своем блоге подробное исследования инцидента с обнаруженной подмененной прошивкой операционной системы Cisco IOS на маршрутизаторах в некоторых странах мира. Свою заметку Mandiant назвала «SYNful Knock — A Cisco router implant», что привело к очередной демонстрации поверхностного понимания отдельных исследователей того, что из себя представляет начинка сетевого оборудования и его безопасности. В частности, Илья Медведовский, генеральный директор российской компании Digital Security, которая называет себя «ведущей российской консалтинговой компанией в области информационной безопасности», комментируя исследование Mandiant, заявил:»Компания Cisco сама была вынуждена признать факт реального обнаружения у своих клиентов так называемого «импланта» в стиле АНБ, или аппаратного руткита для их сетевого оборудования». Однако ни о каком импланте, и тем более аппаратном, о котором упоминалось в цитате г-на Медведовского, речи в исследовании Mandiant не шло. Что же раскопал Mandiant?

Надо сразу сказать, что ни о какой уязвимости сетевого оборудования речи не идет! Для успешной реализации злоумышленнику требуются учетная запись администратора маршрутизатора Cisco (а не коммутатора, как писали отдельные СМИ) или физический доступ к оборудованию. Об этом Cisco написала еще в августе, за месяц до исследования Mandiant, опубликовав соответствующее предупреждение.

У вас вызовет удивление, если вам скажут, что некто, заполучив логин и пароль админа ПК, переустановил на нем ОС или поставил вредоносное ПО? Скорее всего нет. Это достаточно очевидная угроза, нередко реализуемая на практике. А рекомендация хранить в тайне пароль админа давно уже относится к неувядающей классике. Почему тогда в отношении сетевого оборудования аналогичная угроза не рассматривается, а рекомендация хранить пароль админа вызывает вопросы? Чем маршрутизатор или коммутатор отличается с точки зрения принципов обеспечения своей защищенности от мобильного устройства или персонального компьютера?

В случае с SYNful Knock, а именно так был назван инцидент/вредоносный код, обнаруженный Mandiant, злоумышленник смог установить на маршрутизатор заранее подготовленный образ операционной системы (можно ли это назвать аппаратным имплантом?!), который содержал ряд вредоносных модулей, занимающихся различными задачами:

Перенаправление трафика, подпадающего под определенные критерии, установленные злоумышленником. Это была основная «полезная нагрузка» SYNful Knock.
Обеспечение NAT для доступа извне к сетевому оборудованию, установленному внутри.
Обфускация, например, за счет скрытия вредоносной активности в списке процессов.
Инкапсуляция команд от злоумышленников и ответов на них в специально сформированные TCP-пакеты, отправляемые на интерфейс маршрутизатора.

Для идентификации SYNful Knock было предложено несколько достаточно простых механизмов и рекомендаций:

Анализ результата команды «show platform | include RO, Valid» на маршрутизаторе. Зараженный маршрутизатор не должен был выдавать никаких результатов или выдавать нечто похожее на:

16M 0×40000000:0×41FFFFFF 0×00000000:0×01FFFFFF CacheMode=3, RO, Valid
1M 0×42000000:0×421FFFFF 0×02000000:0×021FFFFF CacheMode=3, RO, Valid
1M 0×42200000:0×423FFFFF 0×02200000:0×023FFFFF CacheMode=3, RO, Valid
1M 0×42400000:0×425FFFFF 0×02400000:0×025FFFFF CacheMode=3, RO, Valid
64K 0×42600000:0×4261FFFF 0×02600000:0×0261FFFF CacheMode=3, RO, Valid
64K 0×42620000:0×4263FFFF 0×02620000:0×0263FFFF CacheMode=3, RO, Valid

Специальный сканер SYNfulKnock Scanner, написанный исследовательским подразделением Cisco Talos в виде скрипта на Python и распространяемым абсолютно свободно.
Сигнатура для системы обнаружения атак Snort с SID:36054. Аналогичной сигнатурой оснащена и система обнаружения вторжений Cisco NGIPS в составе FirePOWER Services на Cisco ASA, Cisco ISR, Cisco FirePOWER Appliance, Cisco Firepower 9300 и в виртуальном исполнении.

Результат работы такой сигнатуры показан ниже:

По доступной на настоящий момент информации серьезного урона SYNful Knock не нанес, а ареал его распространения (число пострадавших сетевых устройств) оказался ограниченным и составил на 20 сентября 2015 года 163 устройства по данным Shadowserver (из десяти миллионов проданных устройств данного поколения).

История инцидентов с оборудованием Cisco

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

Но… Прежде чем описать эти инциденты чуть более подробно, мне бы хотелось сделать важное замечание, которое я уже делал, описывая инцидент с SYNful Knock. Ни в одном из упомянутых случаев не была использована никакая известная или неизвестная уязвимость в программном обеспечении Cisco. Во всех зафиксированных нами или нашими заказчиками случаях для атаки использовались либо скомпрометированные/украденные учетные записи администратора сетевого оборудования или физический доступ к оборудованию с Cisco IOS.

В таблице ниже воедино сведены все 6 инцидентов с нашим оборудованием, зафиксированных за последние 4 года. Цвет отражает сложность реализации (зеленый — низкая, красный — высокая). «Статический» метод заражения означает, что речь идет о модификации образа IOS, сохраненного на устройстве. «В процессе исполнения» в свою очередь означает, что речь идет об изменении кода в памяти (при неизменности самого образа операционной системы). «Удаленное обнаружение» означает возможность дистанционной идентификации вредоносного кода на сетевом оборудовании с помощью сканирования его самого или его сетевого трафика, что продемонстрировано выше в разделе с описанием SYNful Knock.

Исторически первые два инцидента (варианты 0 и 1) оказались и самыми простыми с технической точки зрения. Они были направлены на конкретных заказчиков, использующих снятые уже 5 лет назад с производства модели маршрутизаторов Cisco ISR 2800, 3825 и 3845. Злоумышленники просто подменили образ IOS, загруженный на устройство. Бороться с аналогичными инцидентами достаточно легко — необходимо просто верифицировать код IOS, загружаемый на сетевое оборудование, о чем еще будет сказано дальше.

Варианты 2 и 3 оказались технически сложнее — злоумышленники, воспользовавшись скомпрометированной учетной записью администратора, смогли модифицировать часть кода IOS в памяти маршрутизаторов Cisco 7600, используя для этого некоторые отладочные возможности оборудования. Основной целью внедренного кода была захват и перенаправление пакетов IPv4 по критериям, установленным злоумышленником. Второй целью злонамеренного кода была реализация NAT для доступа злоумышленников во внутреннюю сеть извне, из Интернет. Верификация загружаемого кода IOS в данном случае уже не помогает, так как операционная система на устройстве не подвергается изменению — вредоносный код работает только в памяти, в процессе исполнения. С другой стороны после перезагрузки устройства модифицированный в памяти этот код перестает функционировать. В обоих инцидентах нейтрализовать повтор проблемы возможно путем использования традиционных мер защиты административного доступа к оборудования и авторизации доступа привилегированных пользователей, а также применением функций мониторинга аномального поведения в памяти, о которых также будет сказано ниже.

4-й вариант был схож с предыдущими двумя по способу своего попадания на маршрутизатор (подвержены модели Cisco 1800, 3800 и 7200). Однако он был первым и пока единственным, в котором мы обнаружили, что вредоносный код был устойчив к перезагрузке устройства и обновлению его ПО (за счет нахождения вредоносного кода в модифицированном коде обновления ROMMON). Одна из частей вредоносного кода, также как и в предыдущих инцидентах отвечала за перенаправление интересующего злоумышленников трафика за счет его инкапсуляции в ICMP, а вот другая часть кода была абсолютно новой. Она была построена по модульной архитектуре и позволяла подгружать по необходимости новые функциональные части. При перезагрузке устройства эти модули требовалось подгружать заново, за что отвечала базовая часть вредоносного кода, «сидящая» в модифицированном обновлении ROMMON. Защититься от данного варианта вредоносного кода можно, используя меры, описанные для вариантов с нулевого по третий, или просто нейтрализовав модифицированное обновление ROMMON путем установки штатного обновления (не зря компания Cisco внедрила механизм цифровой подписи обновлений ROMMON и образов операционной системы IOS, но на платформах предыдущих поколений проверку необходимо активировать вручную).

Наконец, последний, 5-й вариант, также известный как SYNful Knock, был схож с инцидентами 0, 1, 2 и 3. Его отличие состояло в том, что он использовал для взаимодействия с управляющими серверами протокол TCP, а не ICMP. Почему-то именно этот, не самый сложный вариант, получил широкое освещение в прессе. Хотя число зараженных им маршрутизаторов (пострадали только модели Cisco 1841, 2811 и 3825) составило около полутора сотен устройств из десяти миллионов проданных за все время существования этого поколения. Много ли это? На самом деле не очень. Например, в территориально распределенной сети Cisco 40 тысяч маршрутизаторов. У компаний, имеющих офисы в двух-трех десятках стран число маршрутизаторов и составляет около одной-двух сотен. Так может SYNful Knock был найден всего у одного заказчика, а не у множества, как писали некоторые отечественные «эксперты»? Это вполне резонное предположение, так как в том же самом варианте №3 пострадал всего один заказчик.

Краткий ликбез перед началом серьезного разговора

И вот тут впору отойти немного в сторону и дать краткие пояснения, относительно того, что сегодня представляет собой сетевое оборудование Cisco. Давайте я начну с вопроса: «Какие операционные системы Microsoft вы знаете?» «Windows», ответите вы и будете неправы. Если даже не брать в расчет MS DOS, то даже Windows у Microsoft существует несколько. Есть Windows 3.11, есть Windows 95, есть Windows NT, есть Windows 2000, есть Windows 7, есть Windows 8, есть Windows CE, есть Windows Embedded, есть, наконец, Windows 10 (и это еще не все Windows). И это не одна и та же ОС — местами они отличаются очень и очень сильно (и не только графическим интерфейсом). Вот так и у Cisco — у нас есть несколько операционных сетевых систем. Есть IOS, есть CatOS, есть AsyncOS, есть Firepower OS, есть NX OS. И даже IOS бывает разный — IOS, IOS XE, IOS XR. Причем совсем разный. Тот же IOS XR хоть и имеет общих три буквы в названии, при этом имеет мало общего с обычным IOS. В основе IOS XR лежит QNX, в то время как в основе той же IOS XE лежит Linux, а IOS базируется на BSDi. Кстати, во всех описанных выше инцидентах, включая и SYNful Knock, атаковали пока только Cisco IOS — в отношении IOS XE, IOS XR, NX-OS и других наших платформ никаких инцидентов нами не зафиксировано.

Поэтому, когда какой-либо исследователь или компания безапелляционно заявляет о том, что они «взломали IOS», то это либо признак непрофессионализма и непонимания того, что у нас существует множество разных модификаций нашей основополагающей операционной системы, либо банальное желание приукрасить и попиариться на громкой новости. А ведь помимо разных IOS, существуют и ее различные компоновки, отличающиеся функционалом (IP Base, IP Services, IP Voice, Advanced Security, Service Provider Services и т.д.). Ну и версий IOS тоже немало. Например, если кто-то пишет в своем исследовании об уязвимости версии IOS 15.1, то у меня возникает закономерный вопрос — в какой конкретно версии 15.1? 15.1(1)SY5.27 или 15.1(1)SY6 или 15.1(2)SY5.32 или 15.1(4)M11? Это все разное программное обеспечение, хотя и относится к IOS 15.1. Мне можно возразить, что наверняка в Cisco используется унификация отдельных фрагментов кода, которые кочуют из продукта в продукт, из платформы в платформу, из версии в версию. Да, такие фрагменты есть. Но что-то несмотря на это, никакого универсального для всего ПО Cisco вредоносного кода или уязвимостей пока не обнаружено.

Ну, а когда кто-то заявляет «мы взломали Cisco», то стоит мягко поинтересоваться, что конкретно было взломано, и действительно ли это Cisco. А то, например, уже упомянутая ранее российская компания Digital Security опубликовала осенью 2014-го года отчет «Безопасность абонентского оборудования телекоммуникационных сетей» и в нем почему-то оборудование Linksys называла оборудованием Cisco, ставя между ними знак равенства. Однако подразделение Linksys был продано компании Belkin весной 2013-го года, то есть за полтора года до публикации отчета отечественных «исследователей» и к Cisco уже никакого формального отношения не имело. С фактической же точки зрения, приобретя Linksys компания Cisco никогда его не интегрировала в свой бизнес, сделав обособленным и направленным только на домашних пользователей. Даже команды разработчиков и процессы разработки в Cisco и Linksys были разные. Но винить Digital Security в этом, наверное, нельзя. Все-таки написать про незащищенность оборудования Cisco гораздо круче, чем тоже самое про Linksys, компании Cisco не принадлежащий.

Легко ли атаковать сетевое оборудование?

Поняв, что сетевое оборудование Cisco представляет собой очень разнородную среду с различными типами операционных систем, их сборками и версиями, стоит вернуться к первоначальной задаче, которую я указал в самом первом абзаце, и задаться глобальным вопросом: «А насколько вообще уязвимо/защищено сетевое оборудование?»

Давайте для начала вспомним 2000-й год. Тогда Cisco выпустила первую версию своего руководства по проектированию защищенных корпоративных сетей Cisco SAFE (Security Architecture for Enterprise), в котором были описаны ключевые принципы проектирования и основные аксиомы, которые были положены в основу защищенной сетевой архитектуры Cisco.

Одной из таких аксиом стала »Мишенью для злоумышленников может стать любое IP-устройство». Уже в первой версии Cisco SAFE, кстати, переведенной и на русский язык, говорилось о необходимости пристального внимания к безопасности маршрутизаторов и коммутаторов.

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

Легко ли атаковать маршрутизатор или коммутатор? Да, они работают не на базе пока самой распространенной операционной системы Windows. Но и тайной за семью печатями принципы их работы не назовешь. Вспомним, что я написал выше. В основе разных вариантов IOS лежат BSDi, Linux, QNX. Можно ли считать их абсолютно неуязвимыми и лишенными недостатков? Увы, нельзя. Можно ли тогда удивляться, что и в сетевом оборудовании, построенном на базе данных ОС (пусть и серьезно модифицированных за последние годы), иногда находятся те или иные проблемы, которые могут привести к реальным инцидентам? Просто число такого рода инцидентов несоизмеримо меньше дутых сенсаций и просто опубликованных Cisco PSIRT (а что это такое, я напишу ниже) бюллетеней об уязвимостях.

История «сенсаций» о шеллкодах, руткитах и других проблемах в оборудовании Cisco

Помните важное замечание про описанные выше инциденты с оборудованием Cisco? Они были возможно только при наличии физического доступа к оборудованию или краже учетной записи администратора. С практической точки зрения это важно, так как просто историй об исследователях раскопавших способ взлома «любой Cisco», или описавших теоретическую возможность создания руткита для оборудования Cisco, или даже продемонстрировавших шеллкод для отдельных, как правило, уже неактуальных версий IOS, опубликовано немало.

Но на практике приходится сталкиваться с тем, что все эти истории обладают рядом схожих признаков:

Они базируются на публичной информации об уже опубликованных на сайте Cisco уязвимостях.
Они обычно применимы к неактуальным версиям сетевых операционных систем Cisco.
Они преимущественно касаются только Cisco IOS, а не IOS XE, IOS XR или NX-OS.
Они базируются на исследованиях в лабораторных условиях, далеких от реальной жизни и реальных настроек.
Они не учитывают имеющихся в оборудовании Cisco программных и аппаратных механизмов защиты.

Интересны ли данные истории с практической точки зрения? Исследователям — да. СМИ — да. Производителю — уже нет, так как к моменту выхода подобных публикаций производитель давно выпустил рекомендации по защите от таких угроз, исправления ПО, если оно было необходимо, и разослал уведомления всем своим клиентам, подписанным на их получение. Кстати, подписаться на них может любой. Потребителям — как правило, не очень, так как в реальном мире многие из описанных способов эксплуатации публичных уязвимостей не работают или очень сильно ограничены условиями эксплуатации. Об этом часто забывают различные энтузиасты, которые ради «фана», ради PR или просто интереса пытаются изучать случайно попавшее в их руки оборудование, которое они даже не знают как правильно настроить или как «залить» на него самую последнюю версию Cisco IOS, чтобы исследование было более актуальным и интересным хотя бы производителю.

Например, публикует некий исследователь информацию об эксплуатации уязвимости в интерпретаторе Tcl в операционной системе IOS версии 15.1 на коммутаторе ядра Catalyst 6500. Данная уязвимость позволяет злоумышленнику получить права привилегированного пользователя (администратора) и выполнять привилегированные команды. Получив работающий код, исследователь или его компания, уже привыкшая делать себе имя на «дутых сенсациях» и громких заявлениях, даже не удосужившись связаться с производителем сетевого оборудования, спешно вбрасывает в СМИ «жареный факт», который начинает активно обсуждаться и распространяться по сети Интернет. Многие специалисты, не имея опыта исследований сетевого оборудования, доверяют такого рода заявлениям, ведь они не могут их проверить, а мнению «первой в России» компании они доверяют, считая, что врядли компания будет писать неправду (хотя мы выше уже увидели, что далеко не всегда исследователи разбираются в серьезном корпоративном или операторском сетевом оборудовании также, как и в китайских модемах или ином ширпотребе, который можно купить для исследований на любом радиорынке).

Но давайте посмотрим правде в глаза. Сама уязвимость в интерпретаторе Tcl известна уже давно и имеет даже свой идентификатор CVE. То есть заявление о найденной уязвимости являются откровенным враньем, сделанным только для собственного PR. Серьезная ли эта уязвимость и позволяет ли она, как пишут исследователи, получить полный контроль над сетевым устройством? Cisco PSIRT относит ее к средней степени опасности. Любой ли злоумышленник может ею воспользоваться? Нет. Как минимум потому, что эта уязвимость в указанной версии IOS 15.1 на момент публикации исследования была уже устранена (как и в других, ей подверженных). Да и сама версия 15.1 (хотя мы и не знаем о какой конкретно версии 15.1 идет речь) не является уже актуальной.

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

Другой пример — «нашумевший» доклад Себастьяна Муница (Sebastien Muniz) на конференции EUSecWest в мае 2008-го года, где был представлен «руткит» для оборудования Cisco. Вообще о руткитах для IOS говорят давно и Муниц был одним из первых, кто разработал его прототип. Все бы ничего, но сделан он был не путем использования каких-либо уязвимостей, а за счет модификации образа IOS, загружаемого на сетевое устройство. Да-да, тот же вариант, что и в описанных выше инцидентах, которые были обнаружены Cisco или нашими заказчиками. А эта возможность задолго до Муница была продемонстрирована известным исследователем оборудования Cisco по имени FX (например, на BlackHat в 2003-м году). И против нее уже тогда существовал такой простой механизм нейтрализации, как верификация образа IOS, которую можно было осуществить как оффлайн (вне самого устройства), так и на самом устройстве (с помощью команды verify). По сути речь идет не об уязвимости, о чем Cisco PSIRT и написала в своем бюллетене, а об интересной возможности, которая может быть реализована на практике при несоблюдении хорошо описанных рекомендаций по защите сетевого оборудования Cisco.

Вообще, это один из самых популярных недостатков начинающих исследователей. «Найдя» уязвимость (которая, возможно, уже и на сайте Cisco давно опубликована) исследователи либо осознанно, либо по незнанию забывают уточнить исходные данные, при которых она была найдена или проэксплуатирована. А ведь от этого очень сильно зависит — можно ли будет повторить этот эксперимент в реальной жизни или он так и не выйдет за пределы лабораторных условий.

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

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

Cisco PSIRT

Наша команда по реагированию на вопросы безопасности в оборудовании Cisco PSIRT (Product Security Incident Response Team), регулярно публикует информацию обо всех найденных проблемах в различных решениях Cisco на специальном сайте — www.cisco.com/security.

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

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

Кстати, насчет процесса устранения уязвимостей. В среде исследователей, которые гонятся не только за PR, а думают о реальной, а не о декларируемой безопасности, есть практика взаимодействия с производителем оборудования, в котором находится та или иная проблема. Есть такая практика и у Cisco. Согласно нашей политике раскрытия информации об уязвимостях, мы готовы сотрудничать с любым исследователем или компанией, нашедшей уязвимости в нашем оборудовании. Тот же FX активно с нами взаимодействует и не публикуют никаких «сенсаций» до общения с PSIRT.

Из российских компаний могу назвать Positive Technologies, которая давно и плодотворно сотрудничает с нами, находя в процессе оказания своих консалтинговых услуг и направляя нам информацию об уязвимостях в различных наших продуктах. За последнее время нами было получено от Positive Technologies около пятнадцати таких уведомлений, различающихся по уровню опасности от незначительного до высокого. Компания Positive Technologies в данном контексте — это пример зрелого подхода к исследованию программного обеспечения на уязвимость и ответственного отношения к пользователям ПО, которое содержит уязвимости, раскрываемые только производителю. А вот уже дважды упомянутая отечественная Digital Security не обращалась в Cisco PSIRT ни разу по поводу найденных ею уязвимостей или иных проблем в нашем оборудовании! Более того, когда специалисты Cisco PSIRT по своей инициативе связались с Digital Security по поводу недавнего доклада на ZeroNights о якобы обнаруженной уязвимости в оборудовании Cisco, представители Digital Security не смогли ничего ответить и представить детали своего исследования.

Что делает Cisco?

Если уж зашла речь о Cisco PSIRT, то нельзя не сказать и о других наших инициативах по обеспечению безопасности выпускаемого нами сетевого оборудования. Но прежде вновь хочется вернуться к ликбезу.

К рассказу о типах, сборках и версиях IOS надо добавить, что не существует такого общего понятия как «маршрутизатор Cisco» (к коммутаторам относится тоже самое). При чтении отчетов о любых исследованиях всегда надо уточнять, о какой конкретно линейке и модели сетевого оборудования идет речь, какова была конфигурация оборудования, каким образом осуществлялось воздействие. У нас есть ISR, ASR, GSR, CSR, CRS. Самой ходовой линейкой является маршрутизатор ISR (Integrated Services Router), который, о неожиданность, тоже бывает разных поколений. Последнее время мы предлагаем заказчикам уже третье поколение маршрутизаторов Cisco ISR — ISR 4k (он же ISR 4000). Производство первого поколения Cisco ISR (модели 1800, 2800 и 3800), а именно оно фигурировало во всех вышеописанных инцидентах, включая и SYNful Knock, завершилось пять лет назад, в 2010-м году. Из чего вытекает вполне логичный и закономерный вывод — в приобретаемом сейчас оборудовании Cisco, многие из описанных ранее инцидентов невозможны в принципе. Почему я делаю такой вывод?

Все очень просто. Первое поколение маршрутизаторов Cisco ISR появилось у нас в 2004-м году, когда мероприятия по обеспечению безопасности нашей собственной продукции носили эпизодический и не системный характер. Хотя уже тогда у нас была реализована функция подписи образа (Digital Image Signing) для защиты его от несанкционированного изменения или подмены, но далеко не везде. Сейчас этот функционал присутствует в 560 различных продуктах Cisco.

В 2007-м году у нас появилась первая реализация аппаратного модуля ACT, предназначенного для контроля целостности оборудования и защиты от контрафактной продукции, которая стала иногда появляться на рынке, имея дальневосточное происхождение. В 2008-м году мы внедрили в Cisco процесс безопасной разработки (Cisco Secure Development Lifecycle, CSDL), а спустя год на свет появилось второе поколение маршрутизаторов Cisco ISR G2 (1900, 2900 и 3900), обладающее гораздо большим функционалом по собственной защите. Причем именно на аппаратном уровне. В частности, модуль ACT трансформировался в так называемый модуль Trust Anchor («якорь доверия»), который сейчас реализован уже в почти 300 продуктах Cisco. Функция защищенной, доверенной загрузки Secure Boot, позволяющей удостовериться в программной целостности устройства, впервые была реализована в 2010-м году, а сегодня она является неотъемлемой частью процесса разработки большинства продуктов Cisco.

Аналогичные изменения по части безопасности коснулись и программного обеспечения. Например, только между 10-й и 12-й версией IOS (а текущая версия начинается уже с числа 15) было выпущено несколько тысяч (!) промежуточных версий нашей сетевой операционной системы, не только устраняющих те или иные ошибки, обнаруженные в процессе тестирования и эксплуатации, но и расширяющих защитный функционал, учитывающий изменяющуюся природу вредоносного кода и действий злоумышленников. Например, если для защиты от подмены статического образа IOS достаточно механизма верификации и защищенной загрузки, то для борьбы с вредоносным кодом, работающим в памяти, нами был разработан специальный монитор, отслеживающий подозрительную и аномальную активность именно в памяти сетевого устройства. Также для борьбы с вредоносным кодом, запускаемым в памяти, нами был исключен ряд отладочных команд, ненужных при нормальном функционировании устройства, но дающих злоумышленникам дополнительные возможности по реализации своих черных дел. Кстати, изучение всех этих защитных функций является обязательным и входит в состав программы Cisco Security Ninja, о которой я уже писал.

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

Разработку специального инструмента по расследование инцидентов на сетевом оборудовании и проверки его на «вредоносность» (доступен только нашим аналитикам, помогающим заказчикам, подозревающим нечто нехорошее в отношении установленного у них оборудования).
Разработку рекомендаций по усилению защиты сетевого оборудования и контроля его целостности.
Разработку специального инструмента, используемого группой технической поддержки Cisco TAC при общении с заказчиками, и позволяющего анализировать присылаемые заказчиками дампы для обнаружения подмены образа сетевой ОС.
Запуск специальной услуги по верификации образов ПО, установленного на оборудовании Cisco.
И многие другие.

А что делать мне для защиты своей инфраструктуры на базе оборудования Cisco?

А вот ответу на этот вопрос я посвящу отдельную заметку в самое ближайшее время…

В качестве резюме

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

Дополнительная информация: