Популярное сетевое оборудование и статистика уязвимостей

    По данным аналитических агентств производителем наиболее популярного оборудования коммутации и маршрутизации для средних и крупных предприятий является Cisco Systems (около 64% мирового рынка). На втором месте HP Networking (приблизительно 9%). Далее следуют Alcatel-Lucent (3%), Juniper Networks и Brocade (по 2,3%), Huawei (1,8%) и прочие производители, которые менее заметны на фоне гигантов, но сообща занимают, тем не менее, около 17,6% рынка.

    В России ситуация особая. Кроме продукции названных выше производителей у нас достаточно распространены коммутаторы Nortel и Allied Telesis. Кроме того, часто встречаются устройства производителей D-Link и NetGear, предлагающих оборудование для малых и средних предприятий. Brocade на отечественных просторах пока что редкая птица.

    В итоге можно сказать, что наиболее часто в серверных стойках и коммутационных шкафах российских компаний встречается оборудование следующих производителей: Cisco, HP (включая 3Com), Juniper, Avaya (включая Nortel), Alcatel-Lucent, Huawei, Allied Telesis, D-Link, NetGear.

    Вопрос состоит в том, насколько безопасны те устройства, на которых строятся сети. Насколько серьезно относятся производители к безопасности своих продуктов? Мы не будем руководствоваться «классом защищенности», который был присвоен неким контролирующим органом каждой конкретной «железке». Попробуем оценить производителей по количеству известных уязвимостей, для чего воспользуемся следующей гистограммой.

    О чем говорят нам эти данные? Либо у Cisco и HP Networking — самые небезопасные в мире устройства, либо эти две компании внимательнее всех остальных подходят к поиску, обработке и исправлению уязвимостей в своих продуктах. Будем надеяться, что верно второе.

    Если производитель все делает правильно, то события естественно развиваются следующим образом.

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

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

    Не так давно, к примеру, специалисты Positive Research изучали некий продукт в линейке безопасности одного из гигантов индустрии. Практически вся настройка этого продукта производится через веб-интерфейс, в котором были обнаружены множественные уязвимости, причем одна из них была достаточно серьезной — 7.0 по шкале CVSS v. 2. Мы сообщили о ней производителю, и спустя некоторое время было выпущено исправление, однако публично производитель уязвимость не признал и, соответственно, записи о ней на cve.mitre.org вы не найдете.

    Вернемся к гистограмме. Как видно, разрыв в количестве уязвимостей между Cisco с HP Networking и всеми остальными гигантский. Однако тот факт, например, что на гистограмме видна всего одна уязвимость для оборудования Juniper, — не говорит о том, что в 2011 году их не было больше. Дело лишь в том, что сведений о них нет на cve.mitre.org, наиболее доступном и полном ресурсе. Зарегистрированные пользователи juniper.net могут получить исчерпывающую информацию о багах и уязвимостях, но обнаружить те же сведения в свободном доступе будет гораздо сложнее.

    С оборудованием Avaya, Alcatel-Lucent, Huawei, Allied Telesis, D-Link и NetGear ситуация та же: уязвимости в ПО есть, но открытой информации о них мало. Если вы о них не знаете, возможно, знает кто-то другой.
    Другими словами: не зевайте! Если уязвимости не публикуются — это не повод считать оборудование неприступным: device hardening никто не отменял. Чтобы не расслабляться, ниже приводим обобщенную статистику по типам уязвимостей за 2011—2012 годы для всех упомянутых производителей.

    Отказ в обслуживании, как всегда, — самая распространенная угроза для сетевого оборудования, но потихоньку «подтягиваются» и те уязвимости, которые ведут к возможности выполнения в системе произвольного кода (к слову, в 2010 году их было в два раза меньше). Что будет дальше — увидим.

    Автор: Дмитрий Курбатов, исследовательский центр Positive Research

    * По данным Worldwide Quarterly Enterprise Networks Tracker
    ** По данным cve.mitre.org
    Positive Technologies 155,84
    Компания
    Поделиться публикацией
    Комментарии 47
    • +25
      «О чем говорят нам эти данные?» — думаю скорее о том что дыры ищут в самых массовых продуктах рынка.
      • +3
        С вашим комментарием не поспоришь, +1
        • +4
          А d-link не массовые продукты выпускает?

          Непонятная статистика по непонятным продуктам.
          Например, у d-link только одна уязвимость за весь 2011. Первое, что приходит в голову: Wi-fi Protected Setup (WPS) — раз. И всё? До 2011 не было капчи на логине в веб-интерфейс, или за уязвимость не считается?
          • 0
            отсутствие капчи — не уязвимость, т.к. сама по себе капча — не супер защита. Гораздо полезнее блокировка на n времени посли m неудачных попыток входа с IP/подсети
            • +1
              Капча — защита от ботов, а не от людей. В таком случае, WPS тоже не уязвимость — просто возможность подобрать ключ WPS и её тоже можно ограничить количеством попыток.
              • 0
                простите, а от кого тогда блокировка по количеству неверных входов? Как раз таки против ботов. Тем более что до половины капчи расшифровывается техникой, а четверть — даже человек фиг разгадает
                • +1
                  От тупых нодов ботнетов, в которые не встроены алгоритмы разбора даже простых капч, но admin-admin и admin без пароля встроены.
                  • 0
                    если admin-admin или admin без пароля и во всех аналогичных случаях капча не спасёт:
                    — нередко включён доступ не только по веб-интерфейсу,
                    — первый попавшийся «кулхацкер Вася» такой пароль взломает. (смотрим «хакеры» и восхищаемся паролем GOD или смотрим «наиболее популярные пароли» и опять же умиляемся).
                    • 0
                      * В «домашних» у d-link нет никакого «не веб интерфейса».
                      * Еще раз повторю, капча не от «кулхацкера», а от малваре, которые меняют, например, DNS и, например, на vkontakte.ru и paypal.com вы идете совершенно по другим IP.
                      • 0
                        1. хм… вы это DIR-320`му ещё скажите.
                        2. сомневаюсь что защитит во всех кейсах, хотя небольшой смысл — да, есть.
                        • 0
                          Простите, что у dir-320 с родной прошивкой (не *wrt) включено по дефолту, кроме веб морды?
                          • 0
                            По поводу «во всех кейсах» — это и ёжику понятно. Но, если у вас есть непонимание, зачем ввели эту капчу, ну поищите в вашем любимом поисковике, не я же её придумал и внедрил.
                            • 0
                              ну по дефолту в DIR-320 отключён и терминал и капча.
                              При этом всё прекрасно включается через веб-интерфейс (без всяких прошивок). Просто вы говорили про «нет никакого не веб интерфейса», я и поправил. Более чем уверен, что в ряде устройств терминал по умолчанию — включён.
                              • 0
                                Ну, не по дефолту можно и прошивку на *wrt сменить и логин по ssh с ключом сделать. Защита капчей для других целей.
                                Извиняюсь, моя фраза была неправильная, не хватало слов «по умолчанию». Спасибо. что поправили.
              • 0
                Согласен, а блокировку на n времени после m неудачных попыток обычно относят к device hardening, иначе говоря “грамотная и безопасная настройка”
              • 0
                Это, несомненно, баг, но в данном случае для статистики уязвимостей мы брали исключительно публично заявленные и имеющие CVE идентификатор
              • 0
                +100500

                Привет недавнему Mac-ботнету.
              • 0
                Ну тогда уж и Asus можно было бы вспомнить, если бы речь шла о «домашнем» пользователе.
                С капчей поспорю, в 2010 точно уже была на DIR-300, возможно не на всех устройствах.
                • 0
                  не туда ответил… на сообщение пользователя «router».
                  • +1
                    Капчу в 2010 не видел, но, может, не сильно приглядывался.
                    Количество уязвимостей за 2011 год оценена по производителям, как написано в статье, или для оборудования, используемого в «средних и крупных предприятий»? Список участников несколько разный, а формулировки предложений расплывчаты. Поэтому и написал, что непонятная статистика по непонятным продуктам.
                    • 0
                      По производителям для продуктов enterprise сегмента
                • 0
                  Временами читаешь рассылку цисконого bug search tool, и бледнеешь. Как вам, например, бага «неуспешная попытка авторизации через консоль вызывает рестарт свитча»? С другой стороны — да, циска очень дотошно записывает все баги. С моей подачи уже пару-тройку создали, причем на том этапе, когда разработчики даже еще не смогли воспроизвести проблему. Это указывает на некоторую честность вендора. Таблица из поста наглядно показывает, как другие производители относятся к вопросу информирования покупателей об имеющихся проблемах.
                  • 0
                    В целом согласен, но к «информированию покупателя» всегда относился не однозначно.
                    С одной стороны вроде умолчал, значит практически обманул, но с другой стороны не распространил информацию об уязвимости (скорее не сопутствовал ее распространению), ведь даже на момент выходя обновления с заплатой — сколько еще «железяк» серии может годами стоять не обновляясь. Сложно трактовать, во благо это или нет…
                    • 0
                      не распространил информацию об уязвимости (скорее не сопутствовал ее распространению)
                      Ну разумеется, они не публикуют експлоиты. Просто говорят, например, «дырка в SNMP позволяет обрушить IOS». Какой OID пакостит и при каких условиях не говорится. Рекомендация — убедиться, что SNMP прикрыт ACLом.

                      Меня больше бесит нечто вроде:
                      CSCXXX
                      Symptoms: A router crashes.
                      Conditions: A router crashes.
                      Workaround: None

                      Множество таких багов заставляют здорово очковать… Но по факту шанс нарваться на них почти нулевой (раз нет нормального описания, значит, был один кейс по аварии, TAC попытался воспроизвести проблему, и не получилось)
                      • +1
                        Хорошей практикой было бы уведомлять своих клиентов чуть раньше чем интернет-общественность. Но тут, конечно, много проблем, не до каждого дозвонишься :) image
                      • +4
                        Моя любимая от Cisco:
                        CSCso05336

                        Symptoms: A Cisco 1811 router reloads when trying to connect to
                        irc.freenode.net during the first 36 hours following a reload.

                        Conditions: The symptom is observed only in the first 36 hours
                        following a reload.

                        Workaround: Do not connect to irc.freenode.net the first 36 hours
                        following a reload


                        Вольный перевод:
                        Маршрутизатор Cisco 1811 перезагружается при попытке соединения с irc.freenode.net
                        в первые 36 часов после перезагрузки.

                        Workaround: Не присоединяйтесь к irc.freenode.net в первые 36 часов после перезагрузки.
                        • +1
                          С другой стороны, опять же вопрос, уязвимость ли это, или просто баг?
                          • 0
                            Да, такие баги веселят. А как вам эта?
                            • 0
                              У меня много чего прикольного записано…

                              CSCtj79676
                              Symptoms: The router crashes sometimes once CEF is enabled.
                              Conditions: This symptom occurs when CEF is enabled.
                              Workaround: There is no workaround.

                              CSCtk31401
                              Symptoms: A Cisco router crashes when the SSH session from it is exited.
                              Conditions: This symptom is observed when «aaa authentication banner» is configured on the router.
                              Workaround: There is no workaround.

                              CSCto00318
                              Symptoms: SSH session that is initiated from a router that is running Cisco IOS Release 15.x may cause the router to reboot.
                              For now, consider not initiating a SSH session from the Cisco router that is running a Cisco IOS Release 15.x train.
                              Conditions: This symptom is observed on a router that is running Cisco IOS Release 15.x.
                              Workaround: There is no workaround.
                              • 0
                                Cisco такая. Еще очень напрягают «косметик баги»: ошибки на интерфейсах, которых на самом деле нет, или загрузка CPU 80% при запросе по SNMP всегда…
                                • 0
                                  Не все же пакеты в ASIC обрабатывать, и процессор должен чем-то заниматься :)
                            • 0
                              О да, рассылка Cisco Security Advisory это одновременно повод повеселится и погрустить.
                          • 0
                            Неожиданно, Huawei оказался в списках. Я думал, что только наша контора его на L2 использует.
                            • +1
                              Знакомый в Яндекс рассказывал, что они там Huawei (но не только) тоже используют на L2.
                              • 0
                                Году в 2009 на российский рынок «хлынули» железки Huawei-3Com, как раз были L2/L3 устройства. У вас такие?
                                • 0
                                  Huawei (без 3com) Quidway с копипастом Cisco CLI (особенно в некоторых местах) вполне так ничего, особенно, если скидки выбить.
                                  • 0
                                    Ну да, главное что работают. К команде display вместо show можно привыкнуть :)
                                    • 0
                                      «display вместо show» — это так маркетологи Huawei говорят, не все так просто :)
                                  • 0
                                    Да, Quidway S2326 и 2352
                                • +3
                                  Пятница. На главной пост про сиски, жизнь налаживается.
                                  • 0
                                    У нас стоит в основном Cisco, Alcatel и Huawei. Остальное мультисервисное — Искрател (скорее даже ИскраУралТел). Малой ёмкости ADSL чаще всего Zyxel и Натекс.
                                    • 0
                                      Большое количество маленьких однотипных железок это, кстати, та ещё проблема. Читали про AT&T Microcell FAIL?
                                    • +1
                                      Adam J. O’Donnell в исследовании Games, Metrics, and Emergent Threats описал причины переключения внимания злоумышленников с цели X на цель Y, на примере Win и Mac, выдвигая различные гипотезы. Вывод был следующим: концентрация внимания злоумышленников к продукту резко возрастает, как только доля его рынка переваливает за 12-16%. Наличие/отсутствие публикаций об уязвимостях скорее всего также коррелирует с долей рынка/популярностью.
                                      • 0
                                        Спасибо за ссылку, интересное исследование
                                      • 0
                                        Если на CVE мало инфы (а её там действительно мало), почему не был рассмотрен вариант сбора информации с других источников, к примеру osvdb, uscert?
                                        P.S. Весьма огорчает, что и баги и целые классы баг в статистику попадают под одну гребёнку.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое