Home > Articles > Infrastructure Security and Segmentation

Infrastructure Security and Segmentation

Chapter Description

In this sample chapter from Integrated Security Technologies and Solutions - Volume I: Cisco Security Solutions for Advanced Threat Protection with Next Generation Firewall, Intrusion Prevention, AMP, and Content Security, you will review security of the three planes of network infrastructure, the importance of segmenting traffic and methods for doing so, and the benefits of NetFlow.

Securing the Management Plane

Any function related to management of a device resides in the management plane. The primary means of managing Cisco routers and switches are the console and the vty. Both of these provide access to the command-line interface (CLI). In most cases, even when a GUI interface for management is available, it uses the CLI to issue commands to the device. Apart from direct access to the CLI, SNMP can be used for information gathering and change configuration.

Other noteworthy functions that reside in this plane relate to logging and time management. In this section, we discuss security of the CLI and SNMP. Before we discuss the specific topics, some of the general security practices associated with the management plane should be understood:

  • Zero trust and minimum required access: Network devices are the backbone of your information technology infrastructure and should have very strict and restrictive access control applied. Few selected and trained individuals should have access to network devices, and their activities on devices should be authorized and logged. Centralized access control using an authentication, authorization, and accounting (AAA) server along with command authorization are highly recommended. While this chapter briefly discusses AAA, an entire chapter in Integrated Security Technologies and Solutions, Volume II covers it in depth.

  • Central monitoring and log collection: Logs from network devices provide important event and performance data. They should be collected, analyzed, and correlated in a central location for preventive measures as well as incidence response. Similarly, monitoring the network devices using SNMP provides a constant view of the network security and performance while reducing the need for logging in to the device directly.

  • Secure communication: Multiple protocols can be used to access network devices for management. The devices should be configured to use only secure protocols. For example, SSH, HTTPS, and SFTP provide encrypted transfer, whereas Telnet, HTTP, and FTP do not. Similarly, SNMP Version 3 (SNMPv3) should be used instead of earlier versions to provide secure and authenticated access.

  • Central configuration management: Using centralized configuration management provides change versioning and archiving while also keeping your policies consistent across the network.

  • Disabling unnecessary services: Routers and switches contain many services that listen for packets. Services that are not required on your network should be disabled to prevent the chance that they will be used to launch an attack on the device. Special attention should be paid to what Cisco calls small servers. These are disabled by default but can be enabled by using the service tcp-small-servers and service udp-small-servers commands.

Securing the Command Line

The Cisco IOS CLI is divided into 16 privilege levels, each of which defines what commands are available to a user. The privilege levels are divided into four categories:

  • Privilege level 0: Includes the disable, enable, exit, help, and logout commands.

  • User EXEC mode: Also called privilege level 1. By default, users log in to this mode, and it is denoted by a greater-than sign (>) at the end of the prompt. Commands available in this level cannot affect the device configuration.

  • Privileged EXEC mode: Also called privilege level 15. This level can be entered by using the enable command in the user EXEC mode and is denoted by the hash sign (#) at the end of the prompt. All commands are available at this level.

  • Custom privileged modes: Whereas level 1 provides no access to configuration, level 15 provides full access to it. In some cases, neither of these levels can fulfill the requirements of access control policies. To provide tailored access control, IOS has privilege levels 2 to 14. By default, these levels do not provide any more access than level 1 but can be configured to provide access to required commands.

Each of these privilege levels can be protected by passwords. The first level is protected by the passwords configured in the terminal lines. Different devices have different numbers of lines that can be ascertained with the show line command. Typically, Cisco switches and routers have 1 console line and 16 vty lines. You can configure a password to protect the lines by using the password command on the terminal lines as shown in Example 2-1.

Example 2-1 Configuring Passwords on Terminal Lines

R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#line vty 0 15
R1(config-line)#password L3tm31n!
R1(config-line)#exit
R1(config)#line console 0
R1(config-line)#password L3tm31n!
R1(config-line)#

In addition to the password, the vty lines should be configured to use SSH instead of Telnet to allow for encrypted communication with the device. Before SSH can be enabled on the vty lines, an SSH key must be generated on the device, as shown in Example 2-2.

Example 2-2 Generating an SSH Key

R1(config)#ip domain-name cisco.com
R1(config)#crypto key generate rsa modulus 2048

After the SSH key is generated, the vty lines can be configured to use SSH only. To do this, use the transport input command, as shown in Example 2-3.

Example 2-3 Changing the Transport Protocols on vty Lines

R1(config)#line vty 0 15
R1(config-line)#transport input ssh
R1(config-line)#exit

vty lines can be further secured by applying an access list such that SSH sessions are accepted only from certain IP addresses or ranges. This requires an access list that contains the allowed IP addresses. That access list can be applied to vty lines using the access-class command, as shown in Example 2-4.

Example 2-4 Using an ACL to Restrict Access to vty Lines

R1(config)#access-list 1 permit host 192.168.1.10
R1(config)#access-list 1 permit host 192.168.1.15
R1(config)#line vty 0 15
R1(config-line)#access-class 1 in

The line mode provides some other commands that can be used to secure terminal access. Some of the most important ones are discussed here:

  • autocommand: This command is used to configure the lines to execute a specific command when a remote access session is established and authenticated. The session disconnects after execution is completed. The command to be executed is specified as the argument in this case. In Example 2-5, the lines are configured to execute show running-config as soon as the SSH session is established. The SSH session is disconnected after the configuration is displayed.

    Example 2-5 Executing a Command on Session Establishment

    R1(config)#line vty 0 15
    R1(config-line)#privilege level 15
    R1(config-line)#autocommand show running-config
  • exec-timeout: This command configures the duration, in minutes, for which an idle session will be kept alive. It is important to configure a short duration to safeguard against unauthorized access as well as to prevent all vty lines from being used up by idle sessions. Example 2-6 shows how this is configured.

    Example 2-6 Configuring the Idle Timeout

    R1(config)#line vty 0 15
    R1(config-line)#exec-timeout 5
  • privilege level: This command configures the default privilege level that the user lands into after an access session is established on the terminal lines. By default, a user starts at privilege level 1, but that can be changed to any level, including 15. In Example 2-7, the default privilege level for the console line is configured to be 15. After this, when a user connects to the console and authenticates successfully, she starts in privilege level 15 instead of 1.

    Example 2-7 Configuring the Default Privilege Level

    R1(config)#line con 0
    R1(config-line)#privilege level 15

Privilege Levels

After successful authentication using the line password, a user enters privilege level 1 by default. If the user needs to access a higher level, he needs to use the enable [level] command and enter the enable password associated with that level. This password is configured using the enable secret [level] command. If a level is not specified with either of the commands, level 15 is assumed. Example 2-8 shows how the secrets for different levels are configured. The first example does not specify a level; hence, it is assumed to be for level 15. Example 2-9 shows how the enable command is used to enter different levels. Note the use of the show privilege command to show the level that the user is in and the disable [level] command to go back to a previous level. The default level for the disable command is 1.

Example 2-8 Configuring enable secret

R1(config)#enable secret cisco123!
R1(config)#enable secret level 5 l3v3l5!
R1(config)#enable secret level 10 l3v3l10!

Example 2-9 Changing IOS Levels

R1>enable
Password:
R1#show privilege
Current privilege level is 15

R1#disable
R1>show privilege
Current privilege level is 1

R1>enable 5
Password:
R1#show privilege
Current privilege level is 5

R1#disable
R1>enable
Password:
R1#show privilege
Current privilege level is 15

R1#disable 10
R1#show privilege
Current privilege level is 10

All custom levels from 2 to 14 are no different from level 1 to start with. All configuration commands and most verification commands have a default level of 15. To populate the custom levels, you need to reduce the level of required commands from 15 to the desired level. This can be done with the privilege command, which has the following syntax:

privilege mode level level command-string

The mode string denotes the mode in which the command is available—such as configuration, interface, or exec. IOS has hundreds of modes. Usually the name of the mode is reflected in the command used to enter that mode.

The level string denotes the new level of the command. This is the custom level in which you want the command to be available.

The command-string option specifies the actual command that is subject to privilege level change.

As an example, if you want the show running-config command to be available at level 5, you need to reduce the privilege level of that command to 5, as shown in Example 2-10.

Example 2-10 Changing Privilege Levels of Commands

R1#show privilege
Current privilege level is 5

R1#show run?
% Unrecognized command

R1#enable
Password:
R1#config t
Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#privilege exec level 5 show running-config
R1(config)#exit
R1#disable 5
R1#show privilege
Current privilege level is 5

R1#show running-config
Building configuration…

Using custom privilege levels is an easy way to provide differentiated access based on job roles. This is particularly useful in allowing help-desk members to perform basic maintenance functions on a network device while preventing them from making changes to the overall configuration of the device. Example 2-11 shows how privilege level 10 is given the ability to shut down an interface or bring one up without allowing users in that level to make any other changes. Note the use of the mode names—exec, configure, and interface—with the privilege command. The mode name denotes the mode in which the subject command is available.

Example 2-11 Changing Privilege Levels of Configuration Commands

R1#show privilege
Current privilege level is 10
R1#configure terminal
             ^
% Invalid input detected at ‘^’ marker.

R1#enable
Password:
R1#config t
Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#privilege exec level 10 configure terminal
R1(config)#privilege configure level 10 interface
R1(config)#privilege interface level 10 shutdown
R1(config)#exit

R1#disable 10
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface Gi0/1
R1(config-if)#shut?
shutdown

While using local passwords and privilege levels on the device provides the required security, it can be cumbersome to manage these on each device, and inconsistent configuration across the network is very likely. To simplify device configuration and maintain consistency, it is recommended that you use an AAA server such as Cisco Identity Services Engine (ISE). The network devices can use the Terminal Access Controller Access Control System Plus (TACACS+) protocol to authenticate users and authorize commands. Since the authorization configuration is centralized on the AAA server, policies are applied consistently across all network devices. AAA servers and their use for securing CLI access are discussed in depth in Integrated Security Technologies and Solutions, Volume II.

Management Plane Protection

Earlier in this chapter, we discussed the use of an access list to limit the source addresses from which remote access sessions are accepted on vty lines. While the ACL limits the source addresses, recommended best practice is to limit remote management sessions to specific trusted interfaces only.

The Management Plane Protection (MPP) feature can be used to limit remote management sessions to specific trusted interfaces only. This is very useful when a router connects a trusted network to an untrusted network such as the Internet. MPP applies to all management protocols, such as SSH, HTTPS, and SNMP. This feature is configured using the management-interface command in the control pane. This command can be repeated to enable the same or a different set of protocols on other interfaces. One key restriction of this feature is that it cannot be applied to an out-of-band management interface (also called a dedicated management interface), if the device has one. Example 2-12 shows the usage of this command.

Example 2-12 Management Plane Protection

R1(config)#control-plane host
R1(config-cp-host)#management-interface Gi0/0 allow ssh snmp https

CPU and Memory Thresholding

When a network device is under a denial-of-service (DoS) attack, its resources such as CPU and memory start to deplete quickly. Hence, it is important to monitor the resources on your network devices. While regular polling of devices using SNMP helps, configuring a device to send an SNMP trap when certain CPU and memory utilization thresholds have been reached is better. The CPU and Memory Threshold notification features provide this functionality.

The CPU Thresholding Notification feature can alert when CPU utilization exceeds a configured level and when the utilization drops below a configured level. The former is called a rising notification, and the latter is called a falling notification.

The syntax for the command to enable CPU thresholding notification is as follows:

process cpu threshold type {total|process|interrupt} rising percentage interval
seconds [falling percentage interval seconds]

In addition to this command, SNMP traps for CPU threshold must be enabled. Example 2-13 shows the configuration required to enable CPU thresholding notification.

Example 2-13 CPU Thresholding Notification

R1(config)#snmp-server enable traps cpu threshold
R1(config)#snmp-server host 192.168.1.25 traps version 3 priv vuser cpu
R1(config)#process cpu threshold type process rising 85 interval 60 falling  60 interval 60

Similarly, memory thresholding notification can be configured to provide notification when available free memory drops below a certain level and when it rises higher than 5% of that level. In addition, you can configure the device to reserve some memory to send out critical notifications.

This is the syntax for the command to configure the notification:

memory free low-watermark {IO|processor} threshold

This is the syntax for the command to configure memory reservation:

memory reserve critical memory

In these commands, threshold and memory are specified in kilobytes. Example 2-14 shows the configuration required to enable memory threshold notification and critical memory reservation.

Example 2-14 Memory Threshold Notification

R1(config)#memory free low-watermark processor 25000
R1(config)#memory reserve critical 5000

Securing SNMP

SNMP is incredibly useful for monitoring network devices. It can also be used to make changes to devices remotely. This also brings with it risk of misuse and opens up an attack avenue. Hence, it is important to secure SNMP access on your network devices. There are multiple ways to do that, as discussed in the following sections, and Cisco recommends using all these methods together.

SNMP Authentication and Encryption

Three versions of SNMP can be configured on Cisco routers and switches: Versions 1, 2c, and 3. Versions 1 and 2c use simple community strings to provide read-only or read-write access. Community strings can be equated to passwords and are stored in the configuration in plaintext. Communications between the SNMP servers and clients are in plaintext and are prone to snooping.

On the other hand, SNMPv3 allows using usernames and a hash message authentication code (HMAC), and it can encrypt the traffic. SNMPv3 user details are not shown in configuration. SNMPv3 has three levels of operations:

  • noAuthNoPriv: Uses username for authentication with no HMAC or encryption. Very similar to how Version 1 and Version 2c work.

  • authNoPriv: Uses username with MD5 or SHA HMAC for authentication.

  • authPriv: Uses username with HMAC for authentication and provides encryption based on DES, 3DES, or AES.

Given the security benefits, SNMPv3 should be preferred over older versions. Where SNMPv3 is not available, the community strings should be changed from the defaults. One of the most common SNMP strings is “public,” and that is typically the first string used by an attacker.

Table 2-1 lists the differences between the various versions of SNMP.

Table 2-1 SNMP Versions and Their Security

SNMP Version and Level

Security

Credentials Visible in Configuration?

1

Community string

Yes

2c

Community string

Yes

3 (noAuthNoPriv)

Username

Yes

3 (authNoPriv)

HMAC

No

3 (authPriv)

HMAC with encryption

No

When configuring SNMPv3, users are tied to groups and SNMP traps. All SNMP server and trap configuration is then tied to the user. The commands to create groups and users are shown here:

snmp-server group group-name v3 {auth|noauth|priv}
snmp-server user username group-name v3 auth {md5|sha} password [priv {3des|aes 128|aes 192|aes 256|des} encryption-key]

Example 2-15 shows how SNMPv3 groups and users are created and then applied to host configuration.

Example 2-15 SNMPv3 Configuration

R1(config)#snmp-server group snmpl33t v3 priv
R1(config)#snmp-server user l33t snmpl33t v3 auth sha gu3$$myPa$$ priv aes 256 3ncryp1!
R1(config)#snmp-server host 192.168.1.25 traps version 3 priv l33t

SNMP with Access Lists

While authentication and encryption provide a high degree of security, SNMP access should be further restricted with an access list. Access lists can be applied to an SNMP group to limit the source address from which an SNMP read or write request will be received.

To apply an access list to a group, the previously discussed snmp-server group command is extended as shown here:

snmp-server group group-name v3 {auth|noauth|priv} access access-list

Example 2-16 shows how an access list is added to an SNMP group to allow SNMP queries from a known network management server only.

Example 2-16 Adding an Access List to an SNMP Group

R1(config)#access-list 1 permit 192.168.1.25
R1(config)#snmp-server group snmpl33t v3 priv access 1

SNMP Views

The SNMP server on Cisco devices allows access to the whole MIB tree by default. Using authentication, encryption, and IP-based access restriction provides good security, but it can be further enhanced by restricting the MIBs that can be accessed. SNMP views provide the ability to define what MIBs an SNMP group has access to. A view is a list of MIBs that are included or excluded. The following command creates a view:

snmp-server view view-name mib-name-or-oid {included|excluded}

After a view is created, you can apply it to the SNMP group by extending the previously discussed snmp-server group command as shown here:

snmp-server group group-name v3 {auth|noauth|priv} [read view-name]
[write view-name] [access access-list]

Example 2-17 shows how to configure a view and apply it to an SNMP group with an access list.

Example 2-17 Adding a View to an SNMP Group

R1(config)#access-list 1 permit 192.168.1.25
R1(config)#snmp-server view limited system included
R1(config)#snmp-server group snmpl33t v3 priv read limited write limited access 1
3. Securing the Control Plane | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020