Не так давно я вместе с членами своей команды обнаружил уязвимое место в оборудовании корпорации Cisco Systems, которое мы используем для подключения к Глобальной сети.

На базе технологии IP v.4 можно создать 253 различных протокола, причем работа с четырьмя из них грозит серьезными осложнениями большинству маршрутизаторов и коммутаторов Cisco. Если существующую брешь не закрыть программными «заплатками», оборудование окажется незащищенным от атак, нацеленных на отказ в обслуживании (DoS).

Мы выяснили, что как только устройство Cisco получает определенное число пакетов IP под заголовками 53, 55, 77 или 103, оно перестает функционировать. Дело в том, что если коммутатор или маршрутизатор не знает, что делать с тем или иным пакетом, он просто оставляет его в очереди. А когда очередь переполняется, устройство прекращает свою работу.

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

Чтобы защитить свои маршрутизаторы от атак DoS, мы определили правило, в соответствии с которым эти устройства принимали специфичный трафик типов только тогда, когда он исходил от управляющих машин нашей внутренней сети. В этом случае не нужно было заботиться о составлении списков всех типов «сомнительных» данных (пакетов). Вместо этого мы отбрасывали все пакеты, за исключением некоторого числа типов действительно нужного нам трафика. В результате, маршрутизаторы отвергали все четыре уязвимых протокола. То же самое происходило и с любым другим протоколом на базе IP, кроме TCP и UDP.

Казалось бы, это означает, что никаких дополнительных мер для защиты маршрутизаторов Cisco принимать не нужно. Или же все-таки стоило этим заняться? Чтобы развеять сомнения, мы проверили внутренние маршрутизаторы сети, желая убедиться в том, что имеющихся мер предосторожности вполне достаточно, а затем выполнили аналогичную проверку на маршрутизаторах, подключенных к Internet. Межсетевые экраны сразу отбросили трафик четырех вышеупомянутых протоколов, что позволило сделать вывод о том, что атаковать внутренние маршрутизаторы сети представляется делом весьма затруднительным. Однако внешние маршрутизаторы, подключенные к провайдерам Internet, находятся снаружи межсетевого экрана, и при неверной настройке конфигурации они начнут обрабатывать уязвимые протоколы.

Покончив с внутренними маршрутизаторами, мы решили проверить надежность внешних устройств подключения с удаленного узла провайдера. Каково же было мое удивление, когда, подключившись к каждому из них и просканировав порты и протоколы, я получил положительный ответ на запрос по протоколу Telnet! Этот протокол, как известно, используется для организации управления некоторыми маршрутизаторами, поскольку не все версии системы Cisco IOS поддерживают метод шифрования Secure Shell, которому мы отдаем большее предпочтение. Логичным выходом в сложившейся ситуации представлялось ограничение перечня возможных соединений в списке ACL этого маршрутизатора с внутренними адресами нашей сети.

После соответствующей настройки списка ACL ненужный трафик, как и положено, стал отбрасываться. Однако после этого я обнаружил, что IP-адрес, определенный правилом безопасности, не соответствует адресу проверяемого мною маршрутизатора, а присвоен другому узлу, подключенному к Internet. Должно быть, сетевой администратор скопировал набор правил для списка ACL внешнего маршрутизатора, не отредактировав IP-адрес.

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

Ураган TTL-пакетов

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

Умные люди догадались: для того чтобы заставить маршрутизатор обрабатывать данные, вовсе необязательно направлять трафик непосредственно ему. Каждый пакет в Internet имеет счетчик продолжительности жизни (Time To Live, TTL), и всякий раз, когда пакет попадает на очередной маршрутизатор, его номер уменьшается на единицу. Это предотвращает бесконечную циркуляцию данных в сети.

Если счетчик TTL уменьшается до нуля при прохождении пакета через какой-либо маршрутизатор, устройство должно определить, следует ли посылать уведомление о том, что пакет не достиг цели. Из источника, заслуживающего доверия, я получил электронное письмо, в котором утверждалось, что в тех случаях, когда значение счетчика TTL в пакетах типа 53, 55, 77 или 103 достигает нуля, при попадании на маршрутизатор Cisco, данные обрабатываются, невзирая на запрещающие установки ACL. Причина в том, что пакеты не согласовываются со списком контроля доступа ACL, поскольку они адресованы не самому этому узлу, а устройству, находящемуся дальше за ним. Когда маршрутизатор обрабатывает трафик четырех уязвимых протоколов, пакеты застревают в его буфере, и устройство прекращает свою работу.

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

Когда же началось тестирование, с нами связались представители Cisco, утверждавшие, что никакого риска, связанного с заменой ПО, нет и в помине. По их словам, маршрутизаторы с обновленной IOS отбрасывали пакеты с нулевым значением TTL без всяких осложнений. Выходит, мои знакомые хакеры ошиблись? Я полагаю, что должен доверять инженерам Cisco, которые знают, на что способно их оборудование.

По завершении тестирования и развертывания новой версии IOS мы, наконец, почувствовали себя в безопасности. До того момента приходилось тщательно следить конфигурациями списков ACL, защищавших нашу сеть.

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

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

Недооценка уязвимостей

Подразделение STAT компании Harris, специализирующееся на вопросах сетевой безопасности, опубликовало список уязвимых мест корпоративной сети, которые недооцениваются чаще всего. После недавнего нашествия червя Blaster перечень «слабых мест» возглавляют уязвимости, через которые злоумышленник проникает в систему путем вызова удаленных процедур. Теперь «черный список» администратора информационной безопасности выглядит так:

  1. Уязвимости, связанные с вызовом удаленных процедур
  2. Уязвимости технологии Distributed Component Object Model
  3. Уязвимости беспроводных сетей
  4. Уязвимости, связанные с обработкой и регистрацией клавиатурного ввода
  5. Программы-шпионы