smart port cisco что это
Auto Smartports Configuration Guide
Book Title
Auto Smartports Configuration Guide
Chapter Title
Auto Smartports and Static Smartports Macros
View with Adobe Reader on a variety of devices
Results
Chapter: Auto Smartports and Static Smartports Macros
Auto Smartports and Static Smartports Macros
Auto Smartports Macros
Auto Smartports macros dynamically configure ports based on the device type detected on the port. When the switch detects a new device on a port, it applies the appropriate m acro. When there is a link-down event, the switch removes the macro. For example, when you connect a Cisco IP phone to a port, Auto Smartports applies the IP phone macro. The IP phone macro enables quality of service (QoS), security features, and a dedicated voice VLAN to ensure proper treatment of delay-sensitive voice traffic. Auto Smartports uses event triggers to map devices to port macros.
You can also manually configure and apply global macros.
The macros embedded in the switch software are groups of CLI commands.
You can also create user-defined macros by using the Cisco I OS Shell scripting capability, which is a BASH-like language syntax for command automation and variable replacement.
For information, see Chapter 2, “Configuring Auto Smartports and Static Smartports Macros.”
Static Smartports Macros
Static Smartports macros provide port configurations that you apply manually based on the device connected to the port. When you apply a static macro, the macro CLI commands are added to the existing port configuration. When there is a link-down event on the port, the switch does not remove the static macro configuration.
Event Triggers
Auto Smartports uses event triggers to map macros to the source port of the event. The most common triggers are based on Cisco Discovery Protocol (CDP) messages received from another device. A CDP event trigger occurs when these devices are detected:
Note 
Although Auto SmartPort detects the Cisco switch it does not invoke the event trigger automatically. The event trigger needs to be manually invoked to map the switch to macros.
Additional event triggers for Cisco and third-party devices are user-defined MAC address groups, MAC authentication bypass (MAB) messages, 802.1x authentication messages, and Link Layer Discovery Protocol (LL DP) messages.
LLDP supports a set of attributes used to discover neighbor devices. These type, length, and value attributes and descriptions are referred to as TLVs. LLDP-supported devices use TLVs to receive and send information. This protocol advertises details such as device configuration information, capabilities, and identity. Auto Smartports uses the LLDP system capabilities TLV as the event trigger. Use the event trigger control feature to specify if the switch applies a macro based on the detection method, device type, or configured trigger.
For more information about configuring the LLDP system capabilities TLV attributes for Auto Smartports, see the “Configuring LLDP, LLDP-MED, and Wired Location Service” chapter in the switch-specific software configuration guides.
Auto Smartports can detect devices based on Dynamic Host Control Protocol (DHCP) options. There are predefined and customizable macros for devices detected through DHCP options.
For devices that do not support CDP, LLDP, MAB, or 802.1x authentication, such as network printers, laptops, or legacy Cisco Digital Media Players, you can configure a MAC address group with a MAC operationally unique identifier (OUI)-based trigger or MAC address based trigger. You map the MAC address group to a built-in or user-defined macro that has the desired configuration.
User-Defined Files
You can designate a remote server location for user-defined macro files. You can then update and maintain one set of macro files for use by multiple switches across the network.
Macro Persistence
The macro persistence feature causes macro configurations to remain applied on the switch ports regardless of a link-down event. This eliminates multiple system log and configuration change notifications when the switch has link-up and link-down events or is a domain member or an end point in an EnergyWise network.
Managing Macros
You can use the Cisco LAN management system (LMS) tools to deploy macros to switches. When you define a custom macro, you must also configure and associate a trigger for it. For information on configuring user-defined triggers, see the “Configuring User-Defined Triggers for User-Defined Macros” section.
Auto Smartports and Cisco Medianet
Cisco Media net enables intelligent services in the network infrastructure for a variety of video applications. A service of Medianet is autoprovisioning for Cisco Digital Media Players and Cisco IP video surveillance cameras through Auto Smartports. The switch identifies Cisco and third-party video devices by using CDP, 802.1x, MAB, LLDP, and MAC addresses (Figure 1-1). The switch applies the applicable macro to enable the appropriate VLAN, standard quality of service (QoS), and auto-QoS settings for the device. The switch also uses a built-in MAC address group to detect the legacy Cisco digital media player (DMP), based on an OUI of of4400 or 23ac00. You can also create custom user-defined macros for any video device.
Figure 1-1 Cisco Medianet Deployment Example
Digital media player
Cisco IP video surveillance camera
Device Classifier
The DC collects information from MAC-OUI and protocols such as CDP, LLDP, and DHCP to identify devices. You must enable CDP and LLDP on the switch. To make DHCP options information available to the DC, you must enable the DHCP snooping feature on the switch. The device attributes collected from these protocols are evaluated against a set of profiles available to the DC to find the best match. The best-matched profile is used for device identification.
Device-classifier uses profile definitions—built-in and default profiles. The built-in profiles contain the device profiles that are known to the Auto Smartports module, comprising a limited set of Cisco devices. They are built into Cisco IOS and cannot be changed. The default profiles are stored as a text file in nonvolatile storage and allow the DC to identify a much larger set of devices. The default profiles are updated as part of the Cisco IOS archive download.
When a new device is detected, the corresponding shell trigger executes the Auto Smartports configuration macro. Auto Smartports has built-in mappings for a large set of devices. You can use the commands described in the “Configuring User-Defined Triggers for User-Defined Macros” section to create new mappings. You can create the trigger mappings based on the profile name or device name that is provided by the DC.
For switch stacks, the DC runs only on the stack master. All the attributes for devices connected to stack master and stack member switch ports are available to the DC on the stack master. The device classification results are available only on the stack master. During a stack master failover event, the new stack master reclassifies all the devices. The device attributes for the existing and any new devices are available to the DC on the new stack master.
Device Visibility Mode
The DC function is enabled on the switch by default. You can disable it by using the no device classifier global configuration command. The DC feature provides show commands to display the devices that are connected to the switch. It also provides information about the physical port to which the device is connected, along with device MAC address and other vendor information. Only directly connected devices, such as another Layer 2 switch, are classified on nonaccess ports. On access ports that are connected to hubs, device classification is limited to 32 devices.
When you enable Auto Smartports, the DC is automatically enabled. The total number of sessions supported on DC is 1024.
Configure Smartport Properties on a Switch through the CLI
Available Languages
Download Options
Objective
This article provides instructions on how to configure auto smartport properties on your switch through the Command Line Interface (CLI).
To configure smartports on a web-based utility, click here.
Applicable Devices
Software Version
Configure Smartport Properties
Configure Global Smartport Properties
A smartport, when enabled, allows a switch to identify the types of devices connected to it. You can enable by setting up Cisco Discovery Protocol (CDP) and/or Layer Link Discovery Protocol (LLDP).
CDP is a proprietary Data Link Layer protocol that is used to share information about other directly connected Cisco equipment. CDP enables a device to advertise the type of device, operating system version, IP address, configuration, and capabilities to neighboring devices and then stores it in the Management Information Base.
The information shared among the neighbors helps reduce the time needed to add a new device to the Local area Network (LAN) and also provides details necessary to troubleshoot many configuration problems.
LLDP performs the same functions as CDP. The difference is that LLDP facilitates vendor interoperability and CDP is Cisco proprietary.
Step 1. Log in to the switch console. The default username and password is cisco. If you have configured a new username or password, enter those credentials instead.
Note: To learn how to access an SMB switch CLI through SSH or Telnet, click here.
Note: The commands may vary depending on the exact model of your switch. In this example, the SG350X switch is accessed through Telnet.
Step 2. From the Privileged EXEC mode of the switch, enter the Global Configuration mode by entering the following:
Step 3. To configure the Auto Smartports administrative global state in the switch, enter the following:
SG350X(config)#macro auto [enabled | disabled | controlled]
Note: You cannot enable Auto Smartport globally if the OUI Voice Virtual Local Area network (VLAN) is enabled.
— Auto Smartport Operational state is disabled when the OUI Voice VLAN is enabled.
— Auto Smartport Operational state is enabled when the Auto Voice VLAN is enabled.
Note: Regardless of the status of Auto Smartport, you can always manually apply a Smartport macro to its associated Smartport type. A Smartport macro is either a built-in macro or a user-defined macro.
Step 4. To enable CDP capability information to identify the type of an attached device, enter the following:
SG350X(config)#macro auto processing cdp 
Note: In this example, CDP is enabled.
Step 5. To enable using LLDP capability information to identify the type of an attached device, enter the following:
SG350X(config)#macro auto processing lldp 
Note: In this example, LLDP is enabled. This will allow LLDP to detect and identify the type of device attached on the switch.
Step 6. To enable automatic detection of devices of given type, enter the following:
Note: By default, auto detection of ip_phone, ip_phone_desktop, switch, and wireless access point (ap) is enabled.
Note: In this example, auto detection of IP Phone is enabled.
Step 7. (Optional) To replace the default Auto Smartport values of built-in Smartport macros, enter the following:
Step 8. To go back to the Privileged EXEC mode of the switch, enter the following:
Step 9. (Optional) To display the macro auto processing information about which discovery protocols are enabled and which device types can be detected automatically, enter the following:
SG350X#show macro auto processing
You should now have successfully configured the global Smartport properties on your switch.
Configure Smartport Properties on an Interface
A smartport macro is a user-defined set of Cisco IOS Command Line Interface (CLI) commands. It allows you to set up common configurations quickly, easily, and consistently. It enables features, settings and communication for network devices.
A Smartport macro can be applied to an interface by the macro name, or by the Smartport type associated with the macro. Applying a Smartport macro by macro name can only be done through the CLI.
Note: When a macro is applied to an interface, the existing interface configurations are not lost. The new commands are added to the interface and are saved in the running configuration file.
Note: The network access and Quality of Service (QoS) requirements vary if the interface is connected to an IP phone, printer, router, or Access Point (AP).
For more information about Cisco-Provided Smartport Macros, click here.
There are two ways to apply a Smartport macro by Smartport type to an interface:
When Smartport types are applied to interfaces, the Smartport types and configuration in the associated Smartport macros are saved in the Running Configuration File. If you save the Running Configuration File into the Startup Configuration File, the device applies the Smartport types and the Smartport macros to the interfaces after reboot as follows:
To configure Smartport settings on a specific interface on your switch, follow these steps:
Step 1. From the Privileged EXEC mode of the switch, enter the Global Configuration mode by entering the following:
Step 2. In the Global Configuration mode, enter the Interface Configuration context by entering the following:
Step 3. To enable the Auto Smartport feature on the interface, enter the following:
SG350X(config-if)#macro auto smartport 
Note: In this example, Auto Smartport is enabled on the interface.
Step 4. (Optional) To set the interface as a Smartport persistent interface, enter the following:
SG350X(config-if)#macro auto persistent
Note: A Smartport persistent interface retains its dynamic configuration in the following cases: link down/up, the attaching device ages out, and reboot. For persistence and the Smartport configuration to be effective across reboot, the Running Configuration file must be saved to the Startup Configuration file.
Note: In this example, Auto Persistent is enabled on the interface.
Step 5. To manually or statically assign a Smartport type to an interface, enter the following:
Note: In this example, interface ge1/0/19 is statically assigned with an IP Phone.
Step 6. Enter the end command to go back to the Privileged EXEC mode:
Step 7. To display information about all Smartports or a specific one, enter the following:
Note: In this example, the Auto Smartport information of interface ge1/0/19 is displayed.
Step 8. (Optional) In the Privileged EXEC mode of the switch, save the configured settings to the startup configuration file by entering the following:
SG350X#copy running-config startup-config
Step 9. (Optional) Press Y for Yes or N for No on your keyboard once the Overwrite file [startup-config]. prompt appears.
You have now successfully configured the Smartport settings on a specific port or ports on your switch.
View a video related to this article.
Cisco Smart Install. Изучаем технологию, ищем векторы атаки
Доброе время суток! Невозможно было даже себе предположить, что обычная «студенческая» тема, предложенная для летней стажировки в компании Digital Security, сможет вырасти в полноценное исследование безопасности.
О самой технологии, требованиям к оборудованию и т.п., конечно же, лучше всего почитать на сайте производителя:Cisco Smart Install.
Если в двух словах: «Smart Install представляет собой технологию, позволяющую автоматизировать процесс первоначальной настройки конфигурации и загрузки актуального образа операционной системы для нового сетевого коммутатора. Это означает, что новое оборудование, будучи извлеченным «из коробки», может быть сразу же установлено на свое постоянное место и все необходимые данные для его начальной работы будут доставлены по сети без участия администратора. В процессе работы технология обеспечивает так же резервное копирование конфигурации при ее изменении».
Соответственно, чтобы это все как-то работало, технология включена по умолчанию. Полный список устройств, где данная технология используется, можно увидеть на сайте производителя: Cisco Smart Install Supported devices.
Важно понимать, что все описанные ниже атаки буду касаться «Клиентов».
Первым делом, конечно же, необходимо воссоздать действующую модель инфраструктуры «Cisco Smart Install» и поначалу была уверенность, что это возможно сделать в «виртуальной» среде (gns3 – например), но после долгих безрезультатных поисков образа устройства с поддержкой Smart Install от этой идеи пришлось отказаться.
Здесь очень помог случай. В моем распоряжении совершенно случайно (один проект так и остался незавершенным) оказалось оборудование, подходящее для воссоздания тестовой среды для исследования технологии.
Схема и конфигурация тестовой среды
Как видно из приведенной конфигурации, я использовал группировку устройств по Product ID.
После загрузки «Клиентов» и регистрации их на «Директоре» получаем такую картину:
Первые попытки
Почему-то каждый раз перед изучением какой-либо совершенно новой для меня темы в памяти всплывают строки из бессмертного произведения Льюиса Кэрролла «Алиса в стране чудес» когда Король просит Кролика прочитать стихи — главную улику на суде:
С чего начинать, ваше величество? — спросил Белый Кролик.
Начни с начала,- торжественно произнес Король,- и продолжай, пока не дойдешь до конца. Тогда остановись! (в переводе Бориса Заходера)
Попробую начать «с начала», т.е. просто посмотрю на систему со стороны.
Подключаю ноутбук в сеть «Директора» и получаю от него сетевые параметры по DHCP. Запускаю Wireshark и наблюдаю за сетевыми пакетами, которые приходят на сетевую карту.
Конечно же, ни чего интересного я не увидел. Здесь вновь вмешался случай: мне не понравилось, как проходит сетевой провод к «Клиенту 2». Отключив его, я проложил шнур «более качественно» и включил коммутатор.
При получении «Клиентом 2» сетевых параметров от «Директора» я наблюдаю широковещательный пакет – ответ на DHCP-запрос, который помимо сетевых настроек содержит специфические параметры для сети «Директора», в частности место расположения и имя резервной копии файла-конфигурации:
Практически за считанные минуты сформировался алгоритм эксплуатации найденной «уязвимости»:
Замена файла конфигурации устройства
Далее я решил собрать сетевые пакеты, отправляемые «Директором» для «Клиента», при наборе команд на принудительное обновление конфигурации и программного обеспечения.
Для того, чтобы «прослушивать» весь сетевой трафик на порту у Cisco есть великолепный инструмент: monitor session.
На «Директоре» настраиваю «зеркалирование» сетевого трафика с порта, к которому подключен «Клиент 1» на порт, к которому подключен Notebook:
monitor session 1 source interface FastEthernet0/1
monitor session 1 destination interface FastEthernet0/2
Запускаю Wireshark и наблюдаю за сетевыми пакетами, которые приходят на сетевую карту.
На «Директоре» последовательно даю команды на принудительное обновление конфигурации «Клиента 1»:
Соответствующие сетевые пакеты:
Без особой надежды на успех средствами Python 2.7 с пакетом socket я попытался сформировать и отправить на «Клиента 1» с ноутбука аналогичные сетевые пакеты (ноутбук подключил к «обычному» порту «Директора» — без «зеркалирования»).
«Клиент 1» обработал команды также, как при получении их от «Директора»!
Получается, что на «Клиента» можно загрузить произвольный файл конфигурации и тем самым получить над ним полный контроль. Правда, текущая его конфигурация будет утеряна, поэтому пока это лишь – «отказ в обслуживании».
В процессе исследования стало очевидно, что необходимо написание инструмента, который бы осуществлял все атаки. В качестве языка был выбран Python. Результат выложен на гитхабе.
Для того чтобы заменить конфигурацию устройства, нужен файл конфигурации, если у вас такого нет, а попробовать хочется, утилита может создать дефолтный, с возможностью дальнейшего доступа по telnet.
Замена образа IOS
Продолжая наблюдать за сетевыми пакетами, которыми обменивается директор и клиент. Возникла идея: если удалось заменить файл конфигурации устройства, почему бы не заметь всю IOS целиком. В протоколе для этого предусмотрены соответствующие возможности:
Эксперимент с отправкой этих пакетов с ноутбука «Атакующего» завершился аналогично предыдущему — «Клиент 1» повел себя так же, если команды на обновление IOS поступили от «Директора».
И тут меня осенило, что совершенно не важно используете ли вы Smart Install, есть ли в вашей сети «Директоры» и «Клиенты». Команды протокола будут обрабатываться в любом случае.
Теоретически получается, что есть возможность подготовить образ IOS, наполненный всякими нужными нам «закладками», и «залить» его на сетевой коммутатор.
Попробовал таким образом обновить конфигурацию и IOS нового коммутатора Cisco 2960 «из коробки» — успешно.
Получается, что к командам на обновление конфигурации и программного обеспечения восприимчивы все устройства, подходящие под требования «Клиентов» Smart Install даже в отсутствии «Директора»!
Попробовать обновить образ можно командой:
В процессе обновления будет запрошен файл с образом IOS. О том, как встроить свой шел код в прошивку IOS можно прочитать тут.
Похищение файлов конфигурации с устройств
На момент завершения работ, описанных ранее, мне казалось, что программа стажировки, в целом, выполнена. Предмет исследования изучен. Уязвимость найдена и успешно использована для несанкционированного доступа к сетевому коммутатору.
Однако, руководитель стажировки GrrrnDog (за что ему отдельное «спасибо») убедил в необходимости продолжения изучения протокола с целью найти возможность «взять» конфигурацию у устройства напрямую.
Меня заинтересовал момент в технологии «Smart Install», посвященный автоматическому созданию резервной копии устройства либо при записи конфигурации (команда write memory в консоли «Клиента»), либо при перезагрузке «Директора».
На консоли «Клиента 2» даю команду на запись конфигурации в энергонезависимую память (write memory).
Сетевой пакет от «Директора» на создание резервной копии конфигурации содержал в себе три команды «copy»:
Видно, что сохраняется также предыдущая резервная копия конфигурации.
Не избежал я соблазна вставить в сетевой пакет несколько другую последовательность команд, например, такую:
Но, к сожалению, кроме команд “copy” «Клиент» ничего не воспринимает. В процессе составления «однозначно рабочего» сетевого пакета выяснилось, что на «Клиентах» Cisco Catalyst с версией IOS выше 15.0, первой командой обязательно должна стоять команда копирования на flash.
В итоге, пакет, инициирующий на «Клиенте» передачу своей конфигурации на наш TFTP-сервер, состоит из двух команд:
Таким образом, дело оставалось за малым, добавить в утилиту возможность отправки таких пакетов, что и было успешно сделано. Командой:
можно попытаться скопировать файл конфигурации на свое устройство, отредактировать его нужным образом (например добавив себя в администраторы) и применить его на удаленном устройстве.
После некоторого опыта эксплуатации, мы выяснили что иногда бывает полезно массово скопировать файлы конфигурации с большого количества устройств, с целью собрать максимально большое количество паролей привилегированных пользователей. К сожалению, первая версия утилиты делала это медленно и однопоточный tftp-сервер не справлялся с массовым наплывом файлов.
В утилиту была добавлена многопоточность, но пока она не до конца протестирована.
где list.txt – файл со списком ip-адресов со открытым портом 4786. А дальше дело за grep.
Много ли Вас?
После обнаружения возможности не просто вызвать отказ в обслуживании, но и похитить конфигурацию устройства и в теории получить полный доступ над ним, решено было просканировать интернет с целью обнаружить, сколько можно встретить устройств в «дикой природе».
Так как простое сканирование по порту tcp 4786 не было бы до конца объективным («Директоры» также имеют этот порт), понадобился способ идентификации таких устройств.
Для этой цели отлично подходят «пробы» nmap (https://svn.nmap.org/nmap/nmap-service-probes) с помощью которых он определяет версии сервисов:
Дальше дело за малым, организовать сканирование Интернета и отправлять на обнаруженные устройства пробы, и записывать ответ. Здесь нам на помощь приходит zmap в сочетании с zgrab:
В результате было найдено 251801 устройство. Но, к сожалению, данный результат сложно назвать точным, так как нет уверенности, что данная проба nmap подходит для всех устройств. Устройств с открытым портом 4786 было найдено около 9 млн., но большая часть – это роутеры и не подвержены данным атакам.
Выполнение команд на устройстве
После осознания открытых нами возможностей, было принято решение рассказать о проделанной работе на конференции, посвященной вопросам информационной безопасности, ZeroNight 2016.
В процессе подготовки доклада к конференции я вновь посетил страницу на сайте Cisco с описанием технологии «Smart Install» и обнаружил, что разработчики добавили новый функционал – возможность указание команд консоли, которые необходимо выполнить после успешной инициализации нового устройства в сети «Smart Install». Эти команды оформляются в виде файла, т.н. «post install script».
Пример такого файла (приведен на сайте Cisco):
Очевидно, что каждая строка в файле – это последовательность команд, набранных после входа в режим конфигурирования терминала на коммутаторе (configure terminal). На эту мысль наталкивает присутствие «exit» в конце второй строки.
Для исследования этого нового функционала пришлось взять в качестве «Директора» Cisco Catalyst 3750 (WS-C3750X-48P), IOS 15.2 (4) E2. Конфигурация была скопирована со старого «Директора», а в секцию настроек группы «c2960SLan» добавил строку:
Формирую файл – «post install script»:
«Очищаю» конфигурацию «Клиента 2» (команда write erase) и перезагружаю его. Вместе с уже известным нам процессом обновления IOS и загрузкой типовой конфигурации происходит считывание содержимого файла c2960-lanbase_post_install.txt и выполнение, записанных в нем команд.
Сетевой пакет, получаемый «Клиентом 2» от «Директора», выглядит так:
Выяснилось, что для загрузки и выполнения команд из файла «Клиенту» достаточно передать в сетевом пакете только информацию о месте расположения этого файла (остальное заполняется «нулями»).
Очень эффектно смотрится «фокус», когда мы пытаемся безуспешно авторизоваться на устройстве под пользователем ccc, но после отправки нашего сетевого пакета «Клиенту», внезапно авторизация «проходит».
Пути защиты
На мой взгляд, самым простым способ решения этой проблемы, будет добавление «железного тумблера» включающего функционал протокола при необходимости. Таким образом, не будет нарушена концепция «Zero-Touch Installation». Те же, кто не пользуются возможностями протокола, не поставят под угрозу свои устройства.
Для уже выпущенных устройств, нужно отключить Smart Install, если он не используется. Сделать это можно командой no vstack в консоли устройства. После этого, вывод команды show vstack config должен стать примерно следующий:
Все-таки, грамотное применение технологии Cisco Smart Install позволяет достаточно эффективно управлять сетевым оборудованием, состоящим из большого числа устройств. Особенно эта эффективность проявляется при управлении сетью, распределенной по разным зданиям и даже регионам.
Практически на 100 % обезопасить себя от описанных выше атак возможно, включив в типовые конфигурации оборудования настройки списков доступа (access-list), в которых однозначно указываются ip-адреса «Директоров», с которых возможно принимать сетевые пакеты на порт Smart Install (tcp 4786).
Приведу пример такой конфигурации «Клиента» для тестовой среды, описанной в данной статье:
Реакция вендора
После сообщения в компанию Cisco о найденных проблемах. Мы получили ответ примерно следующего содержания:
After thorough analysis and internal discussion we have, however, determined that this is not a vulnerability
in Cisco IOS, IOS XE, or the Smart Install feature itself, but the misuse of legitimate capabilities of the Smart Install protocol, that does not require authentication by design.
Компания обновила информацию о протоколе на своем сайте, добавив туда раздел, предупреждающий пользователя о возможной опасности.
А спустя 3 месяца, выразили благодарность за исследование и публично, еще раз, сообщили о проблеме.
Послесловие и благодарности
Данная публикация является результатом нашей совместной работы с sabotaged. Именно им написан весь материал по эксплуатации найденных уязвимостей.
Повторюсь, но особую благодарность хочу выразить руководителю стажировки GrrrnDog, без которого не было бы ни этой темы, ни этого исследования, ни, конечно же, этой статьи.