Pull to refresh

Comments 69

Алексей! Будут ли переосмыслены дефолты на оборудовании с целью повышения безопасности устройств?
Будут. Хотя в любых наших руководствах написано про то, что не стоит открывать в Интернет интерфейсы управления
Немало контор, у которых интранет размазан по всей стране и получить доступ туда очень несложно. Может лучше не делать такие явные бэкдоры совсем?
Это сложный вопрос. Я думаю выводы будут сделаны, но сказать, какая из функций может быть использована не по назначению, заранее нельзя. Та же самая дискуссия была недавно про майнеры. Кто-то их считает злом и говорит, что их надо блокировать по умолчанию, кто-то так не считает. А истина где-то посередине
Фишка в том, что у нас вот, к примеру, уже отдельная страница в wiki «Что надо отключить на циске сразу после распаковки». Кстати, выключить — в соответствии с вашими руководствами.
Так какого ж чорта ваши дефолты не соответствуют вашим руководствам?
А вот еще бы ссылку на страницу выложили — цены бы не было!
Это может быть внутренний ресурс. Да и как рекламу могут расценить.
Да, это во внутреннем вики, для своего использования.

Возможно скинете в ЛС?

Некоторые команды дважды, т.к. они на разных IOS немного разный синтаксис имеют или нужного параметра нет, поэтому выбираем другой.
no cluster run
no cdp enable
no cdp run
no vstack
no setup express
vtp mode transparent
vtp mode off
no ip http server
no ip http secure-server

no service pad
no logging console
no ip source-route
no ipv6 source-route
no ip forward-protocol nd
no ipv6 pim rp embedded
ip ssh version 2

interface Null0
no ip unreachables
no ipv6 unreachables

Ну и, конечно же, не забываем думать, что эти команды делают, вместо тупого применения. ;)

Про это я и писал в cisco, когда сообщал об это фиче. Сделайте железный тумблер на устройстве, который бы включал ее. Большинство людей просто покупают ваше устройство и ждут что оно будет работать, никто не ожидает от вас бэкдор из коробки. Такими ответами вы подпываете доврерие к бренду.

Мы не можем железно отключит то, что может быть востребовано кем-то. И устройство работает когда его купили. Если человек не хочет читать руководства по настройке и защите, то он может обратиться за консалтингом и ему все настроят. Нет нашей вины в том, что люди не читают ни руководства, ни бюллетени по уязвимостям.
Если оно будет востребовано кем-то, то он это возьмёт и включит.
А где у нас в руководстве написано про отключение SMI? В Hardening Guide написано, что надо отключить неиспользумые сервисы. Мы же не знаем заранее, что используется, а что нет, где будет установлено устройство — на периметре или нет?
ramax, в новых обновлениях IOS эта функция уже отключена
Сдается мне, что наличие уязвимостей на руку некоторым структурам, более того, есть мнение, что многие из уязвимостей скрыто созданы/заложены именно для этих структур, потому что обеспечить иным способом соблюдение договора с этими структурами о предоставлении доступа к оборудованию или целым комплексам, просто невозможно. Не создавать же учетку с именем nsa, fsb и прочее, гораздо проще создать уязвимость, рассказать о ней кому нужно и надеятся, что какой-нибудь эксперт не найдет ее. Ну а когда найдет, то свалить все на ошибку десятилетней давности.
Но это только моя теория.
Это теория. Про SMI мы написали еще в феврале прошлого года. Да и злравый смысл подсказывает, что открывать в Интернет интерфейс управления — это некомильфо
UFO just landed and posted this here
Так что мешает отключить — команда выше показана
если бы всё было так просто.

Note: The no vstack command does not persist across reload due to Cisco defect CSCvd99197 in the following releases of Cisco IOS and IOS XE:
Cisco Catalyst 4500 and 4500-X Series Switches:
3.9.2E/15.2(5)E2
Cisco Catalyst 6500 Series Switches:
15.1(2)SY11
15.2(1)SY5
15.2(2)SY3
Cisco Industrial Ethernet 4000 Series Switches:
15.2(5)E2, 15.2(5)E2a
Cisco ME 3400 and ME 3400E Series Ethernet Access Switches:
12.2(60)EZ11
В новых обновлениях IOS эта функция уже отключена
«Чтобы обеспечить безопасность и контроль периметра, вендорам необходимо вовремя выпускать патчи»

Вас Медведовский с какого года предупреждал? С 2016-2017? Что ему ответили? Мол, эксплойта нет, патч выпустим через год.

ПОЗОР!!!
Мы еще год назад выпустили рекомендации. Патч выпустили за полторы недели до того, как бомбануло. На зарубежных форумах такого ажиотажа нет — там почему-то большинство пропатчилось. А у нас все обсуждают отключение Телеграма и мало кто думает о том, чтобы следовать рекомендациям по правильной настройке оборудования, смотрящего в Интернет; в том числе и те, кто ищут дыры и глумятся в Твитере по поводу и без.
Может быть атака была направлена на Россию и Иран? Очень подозрительно выглядит её начало в пятницу вечером по нашему времени и американский флаг в сообщении.

Впрочем, в США, Великобритании и Западной Европе рынок поделен между крупными операторами у которых совсем другой подход.
Вы просто видите новости только по России и Ирану. Я смотрю внутренние рассылки и там говорится, что накрыло и многие американские компании и другие. В США, кстати, открытых портов SMI больше в разы, чем в России — 55 тысяч.

А «пятница вечер» — это вообще забавно и сродни атрибуции «русских хакеров» по времени атаки, схожем с московским часовым поясом :-) Пятница вечер — это четверть всего мира, начиная с Восточной Европы и заканчивая европейской частью России. В Азии, Японии и Австралии так вообще была ночь
заменить имидж сетевой операционной системы
Красота! А какой имидж у вашей операционной системы? :-D

Сдается мне, это была шутка)

Отключение этой фичи не позволило бы воспользоваться багом

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

Вопрос приоритезации усилий. При отсутствии экслойта и низкой вероятности доступа к этой уязвимости извне (ну кто бы мог подумать, что админы будут открывать такую фичу из Интернет) мы посчитали достаточным выпустить рекомендации по отключению функции, что предотвратило бы и эксплуатацию дыр в ней. Но как показал анализ активности в Интернет, кто-то не унимался и активно искал такие устройства для каких-то своих целей. Поэтому и был выпущен патч. Но это как-то не сильно помогло — его накатили далеко не все судя по новостям
Выпустили бы год назад — обновилось бы гораздо больше народу. И я не понял «будут открывать» или «не будут закрывать»?
А выпустили что? В пятничном кейсе бага RCE вообще не использовалась — там было только использование протокола SMI
Два дня назад, был очередной Cisco Connect и не один из сотрудников замечательной компании Cisco даже полслова не сказал об этой уязвимости. Интересно, почему.
Потому что на Cisco Connect мы не говорим о конкретных уязвимостях, а о методах борьбы с ними. Презентации о том, как защищать сетевое оборудование, мы делаем на Cisco Connect регулярно
UFO just landed and posted this here
UFO just landed and posted this here
Данная уязвимость, как написано в бюллетене, распространяется только на IOS и IOS XE. На ASA данная уязвимость отсутствует.

Бесплатно мы устраняем уязвимости — обновление ПО на новую версию требует сервисного контракта.
UFO just landed and posted this here
PSIRT will investigate and disclose vulnerabilities in Cisco products and services from the date of First Commercial Shipment (FCS) to the Last Day of Support. Cisco customers with service contracts that entitle them to regular software updates should obtain security fixes through their usual update channels, generally from the Cisco website. Cisco recommends contacting the TAC only with specific and imminent problems or questions.

As a special customer service, and to improve the overall security of the Internet, Cisco may offer customers free software updates to address high-severity security problems. The decision to provide free software updates is made on a case-by-case basis. Refer to the Cisco security publication for details. Free software updates will typically be limited to Cisco Security Advisories.

If Cisco has offered a free software update to address a specific issue, noncontract customers who are eligible for the update may obtain it by contacting the Cisco TAC using any of the means described in the General Security-Related Queries section of this document. To verify their entitlement, individuals who contact the TAC should have available the URL of the Cisco document that is offering the update.

Customers may only install and expect support for software versions and feature sets for which they have purchased a license. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license. Additionally, customers may only download software for which they have a valid license, procured from Cisco directly, or through a Cisco authorized reseller or partner. In most cases this will be a maintenance upgrade to software that was previously purchased. Free security software updates do not entitle customers to a new software license, additional software feature sets, or major revision upgrades.
UFO just landed and posted this here
Я не совсем понимаю вашего комментария. Критические уязвимости устраняются бесплатно. Если у вас есть сервисный контракт, то обновление получается в рамках стандартного процесса. Если сервисного контракта нет, то обновление получается через TAC.
Я недавно обновил 5520. Кейс с вебморды открыть, естественно, при отсутствующем контракте, нельзя, пришлось звонить. Человек выслушал, повыяснял, потом заявил — у вас гарантия кончилась, контракта нет, не дадим. Говорю — ну так у вас же статья о критической уязвимости. — А скажите номер статьи? Сказал. Открыли кейс, в результате выложили мне 917интерим.
UFO just landed and posted this here
Мне было интересно пройти правильным (предлагаемым вендором) путём. У меня получилось. Утром почитал, потом 22 минуты на телефоне 8800, минут через 10-15 мне назначили инженера, и он спросил какую версию я хочу. На ответ 9.1.7-интерим со ссылкой — спросил — какую точно версию я хочу. пришлось указать 917(23). Файл выложили по прямой ссылке, я выкачал, ответил, что установлю ночью, потом отпишусь. На следующий день отписался, что все успешно, можно закрывать. Более того, инженер ближе к вечеру еще и отзвонился (судя по номеру — Иордания), все ли у меня получилось.
Как-то так.
Вы представитель Cisco Systems? Отлично! Тогда у меня к Вам 3 вопроса:

1. Зачем надо было оставлять по умолчанию включённой никому не нужную, устаревшую и бажную фичу? Кому нужно — включил бы.

2. Где были вы с вашими рекомендациями раньше, например позавчера?

3. Эта уязвимость доступна не только через интерфейс управления, но и через любой вторичный интерфейс, коих на маршрутизирующем коммутаторе могут быть сотни и тысячи. Интерфейс управления был закрыт снаружи, только это не помогло. Поэтому заголовок Вашей статьи заведомо лукавый. Зачем Вы это делаете?
1. Я не Product Manager по IOS и не знаю причин.
2. Наши рекомендации были даны в феврале 2017-го года, а патч для уязвимости был выпущен 28 марта, то есть до начала массовой атаки.
3. Когда я писал заметку я не имел ввиду слово «интерфейс управления» буквально. Речь шла об отключении сервиса, который не используется.
Опечатка. Просьба исправить.
есть ли у вас устройствас
«Зачем выставлять в Интернет интерфейс управления»
согласно описанию уязвимости, к интерфейсу управления она не имеет ровно никакого отношения. И закрытый (с помощью ACL на line vty) интерфейс управления никак не спасает от данной уязвимости.
Сам cisco smart install, согласно configuration guides на сайте cisco, как отдельный интерфейс управления не позиционируется. И фильтровать доступ к нему предлагается через ACL на SVI, что тоже не является характерной чертой интерфейсов управления.
Я выше ответил, что не надо понимать термин «интерфейс управления» буквально. Речь идет о способе управлять устройством, который почему-то открыт из Интернет.
Я правильно понимаю, что грубо говоря на любом интерфейсе в аплинк (читай любой интерфейс с публичным ip-адресом) должен висеть acl весьма специфичного вида, который каждый раз отличается (копи-паст не пройдет)?
P. S. Обновление ПО — всегда плановые работы с возможным или гарантированным отключением сервисов. Мало того что такие работы надо согласовывать за весьма длительный срок так ещё могут стоять всевозможные запреты на такие работы. А если на географически распределенной сети стоит >>1000 узлов, то только ПО на них будешь обновлять год.
Не совсем так. Если вам не нужен SMI, то он отключается одной командой no vstack. Если он нужен на интерфейсе с публичным адресом, то логично, что необходимо контролировать, кто использует SMI. Для этого и нужен ACL.

Что касается обновления ПО, то мы опять возвращаемся к вопросу, на скольких устройствах нужен SMI? Если на всех, то да, это проблема. Но ее критичность можно нивелировать накатыванием ACL. Если у вас свыше 1000 сетевых устройств, то наверное вы не вручую управляете ими и есть система, которая позволяет провижинить устройства в автоматическом режиме.
Этот SMI нужен только в тех случаях, когда железки массово устанавливаются и на них надо залить первоначальный конфиг. А это когда на оборудовании ещё вообще нет никакого конфига. Я могу понять там cdp, stp, etc Но зачем вообще ЭТА опция включена по умолчанию.
Ну тут я не могу ничего сказать — не Product Manager по IOS
UFO just landed and posted this here
Это не опровергает того, что опция нафиг не нужна уже после инсталяции (когда залит первоначальный конфиг).
В новых обновлениях IOS эта функция уже отключена по умолчанию после инсталляции
мы сделаем классную технологию…
В ней, конечно будут уязвимости, но мы просто напишем, что они есть. А сервис, конечно, будет по дефолту включен. Админам же заняться больше нечем, чем постоянно выяснять, что же ещё такое надо выключить, что бы спасть спокойно.

Напоминает МТС с его услугами, которые он сам подключает (ну потому что бесплатно), а потом делает их платными. И все пользователи только и делают, что следят какую услугу надо успеть отключить.
Самые догадливые, конечно, ухадят на других операторов… или на джунипер… или на хуавей… Ну вы поняли, да?
Задача админа включить то, что нужно для работы, а остальное отключить. Делается это не так часто, что характерно. Это не ПК, который включается/выключается раз в день. Поэтому отключать сервисы не придется каждый день. Оперативно получать уведомления об уязвимостях и решать вопрос накатывания патчей — это тоже задача админа. Заниматься мониторингом изменений в сети — это тоже задача админа (сетевого или безопасности). Задача вендора — улучшать качество кода и оперативно уведомлять о найденных уязвимостях.
Так сделать всё или почти всё выключенным и пускай админ включает то, что нужно. Вероятность отключения ненужного много ниже чем вероятность его включения. Хотя бы потому, что «работает — не трогай». И вообще часто в должностных инструкциях админов или их аналоге есть «обеспечить работу того и этого нужного», но нет «отключить всё ненужное».
Мне всегда казалось, что задача админа — обеспечить работоспособность своего участка (сети/ПО/серверов). А работоспособность включает в себя не только включение того, что нужно, но и отключение того, что не нужно. По крайней мере, когда я работал админом, я свою работу понимал именно так. Хотя в мое время Интернет в России был диалапный, но администрирование сотен ПК в нашей компании поднялась тем же правилам.

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

Ну это философия уже :-) Соблюдение политик безопасности требуется всегда. А отключение ненужных сервисов еще и положительно влияет на надежность и работоспособность устройства
Кстати, по поводу заголовка статьи. А точно ли это касается только интерфейсов управления? На l2 устройствах — понятно, это vlan1 и в нормальной ситуации ни пользователям ни кому-то еще он доступен быть не должен (как минимум — напрямую, т.е. в сегменте vlan1 не должно быть клиентов, каналов и т.п.)
А вот так слушается искомый порт на l3 свиче, например. Сдается мне, что с любого пользовательского влан-а это доступно, если не закрыто ацл-ем. И если это так и почему-то не отключается, то ацл надо вешать на все интерфейсы, причем так формировать ацл, что бы не навредить лигитимному трафику, где порт 4786 — это, допустим, порт источника, т.е. порт, с которого происходит тсп-коннект, а не порт конечного сервиса, к которому происходит подключение.

sh tcp brief all
TCB Local Address Foreign Address (state)
0443E2DC *.4786 *.* LISTEN
0552D460 *.443 *.* LISTEN
Я выше уже писал, что не надо термин «интерфейс управления» воспринимать буквально
И кстати, про те же l3 свичи. Если брать за аналогию ssh, telnet, https и проч., что можно заюзать для удаленного администрирования — по умолчанию, по крайней мере, это доступно с ип любого l3 интерфейса. Ну, на тех свичах, что я сталкивался, может это не универсально.
С 4786 портом, думаю, аналогично. И тогда уже несколько понятней, откуда именно в инете оказывается столько уязвимых устройств, вовсе не от того, что в инет выставляют голой ж… vlan1 или лупбэк, используемый для администрирования.
Забавно читать обсуждение.
Не технические специалисты, а настоящие «блоггеры»
Алексею надо немного другие вопросы задавать, ИМХО)
Он всего лишь довел до нас информацию и более популярно объяснил, тем кто не удосуживается просматривать и реагировать на rss.
А так да… сегодня весь день дикая истерия, начиная с ЦБ и заканчивая последним анеликом)
Sign up to leave a comment.