Cisco Smart Install
Cisco Smart Install is a "plug-and-play" configuration and image-management feature that provides zero-touch deployment for new (typically access layer) switches. The feature allows a customer to ship a Cisco switch to any location, install it in the network, and power it on without additional configuration requirements. The Smart Install feature incorporates no authentication by design.
A Smart Install network consists of exactly one Smart Install director switch or router, also known as an integrated branch director (IBD)
, and one or more Smart Install client switches, also known as integrated branch clients (IBCs)
. A client switch does not need to be directly connected to the director but can be up to seven hops away. Only Smart Install client switches are affected by the misuse described in this document.
The director provides a single management point for images and configuration of client switches. When a client switch is first installed into the network, the director automatically detects the new switch and identifies the correct Cisco IOS image and the configuration file for downloading. It can also allocate an IP address and hostname to a client.
The Smart Install feature is enabled by default on client switches. No configuration is needed in the client switches.
The Cisco Talos group has developed a tool that customers can use to scan for devices that have the Smart Install feature enabled in their environment. Please see the Talos blog post
for further information on this tool.
Further information on the Smart Install feature is available in the Smart Install Configuration Guide
Protocol Misuse Opportunities
The absence of an authorization or authentication mechanism in the Smart Install protocol between the client and the director can allow a client to process crafted SMI protocol messages as if these messages were from the Smart Install director and perform actions similar to those in the following list:
- Change the TFTP server address on the IBC
- Copy arbitrary1 files from the IBC to an attacker-controlled TFTP server
- Substitute the client's startup-config file with a file that the attacker
prepared and force a reload of the IBC after a defined
- Load an attacker-supplied IOS image onto the IBC
- Execute high-privilege configuration mode CLI commands on an IBC, including do-exec CLI commands. Any output of or prompt resulting from the command(s) run will appear on the IBC’s local console (this is only possible in IOS 15.2(2)E and later, and IOS XE 3.6.0E and later)
1 Any file from any file system that can be accessed via the regular copy command on the IOS or IOS XE CLI.
Security best practices around the Cisco Smart Install feature depend on how the feature is used in a specific customer environment. The following sections provide guidance for each of the use cases.
Customers Not Using the Smart Install Feature
Customers who do not use the Cisco Smart Install feature, and who are running a release of Cisco IOS or Cisco IOS XE Software where the command is available, should disable the Smart Install feature with the configuration command no vstack
The following example shows the output of the show vstack config
command in a Cisco Catalyst switch with the Smart Install client feature enabled; this is the only output that indicates that the Smart Install client feature is enabled:
switch#show vstack config | inc Role
Role: Client (SmartInstall enabled)
Use of the no vstack
global configuration command to disable the Smart Install client feature was introduced with the fix for Cisco defect CSCtj75729 (Ability to shut Smart Install default service on TCP port 4786). If a Cisco IOS or IOS XE Software release supports the Smart Install client feature but the no vstack
command does not exist, the release does not contain the fix for Cisco defect CSCtj75729.
For networks where the no vstack
command is not available, refer to the "Customers Leveraging the Smart Install Feature for More than Zero-Touch Deployment" section.
Customers Leveraging the Smart Install Feature Purely for Zero-Touch Deployment
Customers who are leveraging the Smart Install feature purely for zero-touch deployment should disable the Smart Install feature with the configuration command no vstack
once the switch has been deployed. See the "Customers Not Using the Smart Install Feature" section for further details on the no vstack
Customers Leveraging the Smart Install Feature for More than Zero-Touch Deployment
Customers leveraging the Cisco Smart Install feature for more than zero-touch deployment and where the no vstack
command is not available should ensure that only the IBD has TCP connectivity to all IBCs on port 4786. Administrators can use the following security best practices for Cisco Smart Install deployments on affected devices:
- Interface access control lists (ACLs)
- Control Plane Policing (CoPP is not available on all Cisco IOS Software releases)
An interface ACL might look like the following example, with the IP address of the Smart Install director being 10.10.10.1 and the IP address of the Smart Install client being 10.10.10.200:
ip access-list extended SMI_HARDENING_LIST
permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
deny tcp any any eq 4786
permit ip any any
This ACL would then need to be deployed on all IP interfaces on all IBCs. It can be pushed via the IBD when the switches are first deployed.
To further restrict access to all the IBCs within the infrastructure administrators can use the following security best practices on other devices in the network:
- Infrastructure access control lists (iACLs)
- VLAN access control lists (VACLs)
For information about additional mitigations that can be deployed on Cisco devices in the network, including iACLs and VACLs, refer to the previously published Cisco Applied Mitigation Bulletin (AMB) companion document for the Cisco IOS Software Smart Install Denial of Service Vulnerability, which is available at the following location:
Indicators of Compromise
There are no indicators of an attacker changing the TFTP server address or of an attacker copying files off the device using Smart Install capabilities. Cisco recommends that customers look for access from external IP addresses.
If write operations are induced via the Smart Install feature and the logging level is set to 6
) or higher, messages will appear in the logs.
If the startup-config
is replaced, the following messsages are typically seen in the logs from the affected device:
%SMI-6-UPGRD_STARTED: Device (IP address: 0.0.0.0) startup-config upgrade has started
%SYS-5-CONFIG_NV_I: Nonvolatile storage configured from tftp://<ip-address>/my.conf by <username> on console
%SMI-6-UPGRD_SUCCESS: Device (IP address: 0.0.0.0) startup-config has upgraded successfully
The execution of high-privileged commands in configuration mode, via the Smart Install feature, typically results in the following messages created in the logs from the affected device:
%SMI-6-DWNLD_STARTED: Device (IP address: 0.0.0.0) post install file download has started
%SMI-6-DWNLD_SUCCESS: Device (IP address: 0.0.0.0) post install file has downloaded successfully
%SMI-6-UPGRD_STARTED: Device (IP address: 0.0.0.0) startup-config upgrade has started
If a reload is induced via the Smart install feature and the logging level is set to 5
) or higher, one of the following messages will appear in the logs:
%SYS-5-RELOAD: Reload requested by SMI IBC Download Process. Reload reason: Switch upgraded through Smart Install
%SYS-5-RELOAD: Reload requested by Delayed Reload. Reload reason: HULC SMI Scheduled Reload after Config Download
%SYS-5-RELOAD: Reload requested by Delayed Reload. Reload reason: HULC SMI Scheduled Reload
In addition to local logs on client switches and logs that a client switch sends to a syslog server, customers should also look into firewall logs and NetFlow data.
Cisco has published Intrusion Prevention System (IPS) signature ID 7856-0
as well as Snort rules
41722-41725 to help detect the use of Smart Install protocol messages in customer networks. Please see the Talos blog post
for details on the Snort rules.
To avoid false positives, this signature and Snort rules should be enabled only in networks not using the Smart Install feature or at places in the network where Smart Install protocol messages are not expected to be seen.
The following best practices are recommended should also be used to provide more visibility into possible anomalies in an environment:
- Implementing supplemental instrumentation focused on high-value network segments, devices, and individuals, to oversee network devices and enable traffic monitoring (Telemetry-Based Infrastructure Device Integrity Monitoring)
- Implementing Cisco IOS NetFlow for visibility into traffic flows emanating from each portion of the network for evaluation against expected traffic
- Monitoring network device event logging to identify unexpected network device-level activity
For additional best practices, see the Cisco Guide to Harden Cisco IOS Devices
and the Cisco IOS Image Verification white paper