Whitepaper IBM Systems and Technology Group

Recommended Security Practices on IBM

Switches & Routers

Author: Tuan Nguyen

IBM System Networking, Advanced Product Solutions

®

Page 2

Introduction Network security is a nebulous subject. The desired end result is a network that is safe from threats while it functions as it is intended in terms of accessibility, usability, reliability, and integrity. How does one go about achieving this end result? Unfortunately, there is no convenient overarching solution that will solve every security and performance concern. Instead, the task starts with the awareness of network security and understanding the consequences of deploying an unsecure network. With this knowledge, hopefully network planners and architects are motivated to seek methods to harden their network. While there are many tools and procedures that greatly aid in securing the network, the human factor is arguably the most difficult element to manage. Network security is greatly compromised if the human users do not utilize established procedures, or perhaps worse, improperly utilize them. The overall scope of Network Security is enormous. This paper will only focus on practices relevant to Ethernet switches and routers. Below are the basic presentations, the hardware (Fig. 1) and software (Fig. 2) pieces, of a switching/routing system.

Figure 1: Basic Switching/Router Hardware There are two fundamental layers to this type of system: The Control Layer and Data Path

The Control Layer This is the software-intensive portion of the device. The code executes in the unit’s CPU. High bandwidth data flows do not traverse the CPU control layer that is designed to support the following functions: • Protocol operations • Maintenance operations • Configuration • Management • Monitoring • Logging

Page 3

Accesses to the control layer within the switch/router machine can be accomplished through either a direct physical console connection or over-the-network via Telnet/SSH/SNMP/etc. Both methods represent the user communicating with and commanding the device CPU. Protocol, maintenance operations and configuration editing all require access to the autonomous functions the switch/router supports to maintain proper network integrity. These functions include physical link state monitoring, Spanning Tree convergence, OSPF route updates and VRRP failover. With regard to these functions, the CPU is tasked with handling asynchronous network events and taking real-time remedial action as necessary.

Figure 2: Software View of a Switch/Router

The Data Path All the heavy lifting is done by the switch/router at this layer. All packets the switch/router handles are received, inspected, modified as required and forwarded or dropped within the data path. To maintain high throughput and low latency, these operations are executed in hardware by a switching/routing ASIC. User commands for Layer 2/3 configurations, from simple to highly complex, are “programmed” into this data path ASIC hardware. Once properly configured, the

Page 4

vast majority of packets traversing the switch/router are transparently handled by the data path ASIC leaving the CPU from moment-to-moment traffic handling activities. In this paper a number of practices are suggested that should lead to a more secure and reliable network. The ideas presented herein are general in nature. As a collection of tools, they are intended to be utilized towards the goal of a more secure network. Before implementing any of these suggestions, the reader is advised to consult the specific documentation relevant to their IBM switch/router product for more details.

Securing the Control Layer

User Privilege Levels In the IBM System Networking operating system OS 7.7, three access privilege levels have been implemented to limit liabilities and enhance user accountability. In a diverse environment, this is a great tool which allows administrators to group users according to functionality and responsibility. It also helps to minimize potential misconfiguration leading to security risks. The access privilege levels are defined as follows: • User: At this level, interaction with the switch is completely passive. Nothing may be changed

on the switch/router. Users may display information that has no security or privacy implications, such as switch statistics and current operational state information.

• Operator: Operators may make temporary changes on the switch. These changes are lost when the switch/router is rebooted. Operators have access to the switch management features used for daily switch operations. although this privilege level cannot make permanent configuration changes to the device, the temporary changes can severely impact the current operational state of the switch/router and hence the network. Care should be exercised at all time with at this access level.

• Administrator: This is the highest access privilege that may be assigned to an account. Administrators may make permanent changes to the switch configuration. These include changes that are persistent across a reboot of the machine. Administrators can access all functions to configure and troubleshoot problems on the switch/router. It should be obvious this level of access should be granted only to qualified individuals with the appropriate level of personal responsibilities.

Relevant end user management commands from the IBM Networking OS 7.7: • To set the privilege level for a user:

access user <1-10> level {user|operator|administrator}

• To create the username for a user: access user <1-10> name <1-8 characters>

• To define the password for a user:

access user <1-10> password

• To enable a user for access: access user <1-10> enable

• To disable access for a user:

no access user <1-10> enable

Page 5

• To remove a user:

no access user <1-10>

• To display current system user configuration: show access user

Strong Passwords It is recommended that Strong Passwords are used for access to the switch/router. Strong Passwords enhance security because they make password guessing more difficult, and they are more resistant to password stealing via “shoulder surfing”. The following are Strong Passwords requirements: • Must be at least 8 characters in length, the maximum length is 64 characters. • Must contain at least one uppercase alphabet. • Must contain at least one lowercase alphabet. • Must contain at least one number. • Must contain at least one special character:

o Supported special characters: ! “ # % & ‘ ( ) ; < = >> ? [\] * + , - . / : ^ _ { | } ~ • Cannot be the same as the username. • No block of four consecutive characters can be the same as in the old password. An example of how to enable Strong Password in the IBM Networking OS 7.7: • Log-in with Administrator access level. • Type the following command to enable Strong Passwords:

access user strong-password enable

• To disable Strong Passwords: no access user strong-password enable

Once Strong Password is enabled, users can still access the machine using the old password but will be advised to change to a strong password during the log-in attempt. If, for some reason, Strong Password is not to be enabled; then the user should at least make attempts to avoid weak passwords. Some characteristics of weak passwords are: • Short character string containing fewer than 8 characters. • Can be found in a dictionary or other lists. • Personal and can be reasonably guessed by someone knowing the user. Some examples

are kids’ names, pets’ names, spouse’s name, birthdates, names of companies/organizations, etc.

Password Expiration Password expiration is automatic with Strong Password enablement. The default in IBM Networking OS 7.7 is 60 days and can be set to any value from 1 to 365 days. If the default of 60 days is undesirable, a new value should be chosen such that it minimizes annoyance to users while still maintaining reasonable periodic refreshment. • To configure password expiration time:

access user strong-password expiry <1-365>

Page 6

Account Lockout Account lockout is recommended as it prevents unauthorized users from guessing passwords; it also decreases the likelihood of a successful organized attack. Relevant commands from the IBM Networking OS 7.7: • To enable password lockout:

access user strong-password lockout

• To disable password lockout: no access user strong-password lockout

• To set the number of failed log-in attempts that would trigger the lockout: access user strong-password faillock <1-10>

The default value is 6. If the default is not desired, this value should be picked thoughtfully as to avoid nuisance for users who are authorized but are suffering from “fat-fingers” issues. Note: The maximum configurable number of failed attempts is 10, itself a reasonable value. • To clear the failed log-in count for user “Username”, or all users:

access user strong-password clear local user fail-attempts {Username | all} • To re-enable locked-out user “Username”, or all users:

access user strong-password clear local user lockout {Username | all}

TACACS+/RADIUS/LDAP Locally defined user account information for access to a network device is stored directly on that device. While this method is sufficient for a small environment, consider the following shortcomings: • The task of managing user accounts (creation, deletion, update, etc.) for an administrator

multiplies quickly as the number of network devices increases. • A user with access to multiple machines suffers the same burden each time an account

update is required (periodic password change for example). • A rogue administrator may make malicious changes to user accounts which may not be

discovered for some time. This is akin to having a stolen administrator password. • Coordinating, correlating, and interpreting the information logs scattered across multiple

machines is difficult at best. There exists in the industry a framework for controlling access to computing resources, enforcing policies, monitoring usage, and providing information towards service billing. This frameworks is known as Authentication, Authorization and Accounting (AAA): • Authentication provides the means to uniquely identify a user. At log-in, the user is required

to provide credentials to be compared against those stored in the authentication database; access is granted if they match, otherwise access is denied.

• Authorization restricts the user, with granted access, to activities that have been approved for him/her. An example is the user issuing a command, authorization will validate whether the user has the proper privilege to execute such command and blocks command execution if he/she does not have clearance. It is basically policy enforcement.

• Accounting measures the resources the user consumes during access; usually collected by logging session statistics and usage information. Such data can later be used for billing purposes, or collated for trend analysis, resource utilization, and capacity planning.

Page 7

The benefits and advantages of AAA are well understood and proven for large, complex, and diverse environment; in fact, at large scales, it is considered critically important for effective network management and security, and is required for compliance laws. TACACS+, RADIUS, and LDAP are protocols that define the interactions between switches/routers and the AAA server. With the release of the IBM Networking OS 7.7, all of these protocols are supported. Setting up for AAA operations is more involved than implementing simple local user account management. The infrastructure requirement for an external AAA server deployment dictates a high level of planning and commitment. It is beyond the scope of this paper to discuss an AAA deployment in details. However, the reader is encouraged to explore this technology, as it is mature and well known, and there is a wealth of relevant information available on the web. Pertinent configurations can be found in the documentation for each IBM switch/router.

Console Port The console port has the most direct access to the device operating system. Commands issued here are received via the low level serial driver and subsequently forwarded to the CPU for interpretation and execution by the OS. There is no intervening network between the console port and CPU, hence it may be deemed network secured. However, an operator leaving the port open and unintended while in the middle of a session presents a significant risk. Imagine someone accessing the terminal while the operator is absent, making virulent changes, saving those changes to system configuration flash memory and then walking away without being detected. This kind of insidious attack is difficult to anticipate, it may be a long time before the effect of the attack is realized and corrected. When it is finally detected, significant damage might have already been done. The user can easily squelch this scenario by simply terminating the current CLI session by entering the “exit” command. A proper exit status can be easily confirmed by verifying the log-in prompt displays on the screen. Operators should confirm complete system exit status before walking away from the switch/router. An additional back-up preventive measure to consider is to set the system idle timeout function. Tis function will terminate the session after a defined period of idle time. • The default is 10 minutes and it can be set to any value between 1 to 60 minutes:

system idle <0-60> Upon initial log-in to the device via the console, there exists a default administrator account with a well-known username and password (please consult your switch/router documentation for this information). Logging in with this account enables initial set-up of the unit for operations. This account information should be modified as soon as possible to avoid unintended accesses.

Telnet/SSH/SCP Telnet is a venerable text-based remote access (over the network) protocol. It is widely available and easy to use. It is also severely lacking in terms of security. Telnet transmits information across the network in clear text. Unfortunately, this means anyone sniffing the network can easily see and steal users’ names and passwords. The Telnet protocol also does not authenticate the source of the data. With this security weakness, someone can intercept the communication and then wreak havoc on both ends of the channel (man-in-the-middle attacks). Due to the security weaknesses associated with Telnet, today SSH has become one of the more popular protocols for remote access due to its superior security methodologies. SSH encrypts all data sent over the network so sniffed data will show up as unintelligible rubbish. SSH also authenticates both servers and clients to verify their identities. SCP is another useful security tool contained in the IBM Network OS. This communication protocol can be used to securely copy files (such as configuration files, boot image, and OS image) to/from the switch/router.

Page 8

Below are SSH/SCP commands from the IBM Networking OS 7.7: • Enable SSH:

ssh enable • Disable SSH:

no ssh enable • Enable SCP:

ssh scp-enable • Disable SCP:

no ssh scp-enable Once SSH has been enabled and verified working, it is recommended Telnet should be disabled from use. Use the console port to issue the command below: • Disable Telnet (available on the console port only):

no access telnet enable

BBI/HTTP/HTTPS The IBM switch/router provides a browser based Interface (BBI) for accessing the common configuration, management, and operation features through a web browser. The BBI can be accessed directly from an open web browser window. Enter the URL using the IP address of the switch interface (such as http://10.20.30.40). Similar to the Telnet/SSH case, the same security issues with HTTP apply. Rather than using HTTP, HTTPS should be the method used to avoid management traffic security issues, including users’ log-in credentials, from being sent via the web GUI in the clear. HTTPS communication is encrypted via SSL/TLS. • Enable HTTPS

access https enable • Set the TCP port number for HTTPS, the default is 443

access https port [<TCP port number>] • Accessing the BBI via HTTPS requires a certificate to be generated. It is used during the key

exchange. A default certificate is generated the first time HTTPS is enabled. However, the user can choose to generate his/her own certificate using the command:

access https generate-certificate The user will be asked to provide additional information, examples are shown below: • Country Name (2 letter code): CA • State or Province Name (full name): Ontario • Locality Name (for example, city): Ottawa • Organization Name (for example, company): IBM • Organizational Unit Name (for example, section): Operations • Common Name (for example, user’s name): Mr Smith • Email (for example, email address): info@ibm.com To avoid having to regenerate a certificate due to a system reboot, save it to flash memory:

access https save-certificate

Page 9

When the user connects to the device via a web browser, he/she will be asked to verify the fields of the certificate, ensure they match expectations, and accept. Once HTTPS is verified working, HTTP should be disabled from use, as follows: • Disable HTTP

no access http enable

SNMPv1/SNMPv2c/SNMPv3 SNMP (Simple Network Management Protocol) is a standard protocol for managing networked devices. It allows for monitoring and necessary configuration changes. On switches and routers, information can be fetched (read) and settings modified (write). The most commonly deployed versions are SNMPv1 and SNMPv2c. They employ a rather primitive method for access validation: Community strings. When a request is made to a switch/router, it is accompanied by a community string. If the community string matches the string configured on the switch/router, the request is accepted and processed. If the input string does not match the string on the switch/router it is discarded. SNMPv1/SNMPv2c communications are unencrypted, which means the community strings are transmitted in clear text. It should be obvious these versions of SNMP are rather unsecured. IBM switches and routers are shipped with the default restricted (read-only) community string of “public”, and the default unrestricted (read-write) community string of “private”. The user is urged to change these as soon as practical. Do not use real passwords as community strings as they could be pilfered. Below are the relevant commands for this purpose, from the IBM Networking OS 7.7: • Set restricted (read-only) community string, the default is “public”

snmp-server read-community <1-32 characters> • Set unrestricted (read-write) community string, the default is “private”

snmp-server write-community <1-32 characters> Note that additional restricted and unrestricted community strings may be supported and the user may opt to use these in deployment instead. However, do not neglect to make the changes above as they remove the industry’s well known default community strings from the system, and thus preventing them from being employed in unauthorized accesses. Below are commands for managing additional strings from the IBM Networking OS 7.7: • Add additional restricted (read-only) community string, up to 7 is supported

snmp-server read-community-additional <1-32 characters> • Remove additional restricted (read-only) community string

no snmp-server read-community-additional <1-32 characters> • Add additional unrestricted (read-write) community string, up to 7 is supported

snmp-server write-community-additional <1-32 characters> • Remove additional unrestricted (read-write) community string

no snmp-server write-community-additional <1-32 characters> SNMPv3 fixes the security weaknesses from the previous versions by introducing two new features: authentication and confidentiality. The three security models offered are: • No authentication and no confidentiality: This model offers no security, confidentiality, or

privacy at all. Not useful from a security stand point. • Authentication and no confidentiality: Access authentication is enforced, but no encryption on

communication. Somewhat useful only as communicated information can still be sniffed and stolen.

Page 10

• Authentication and confidentiality: Both access authentication and communication data encryption are enforced. This should be the de facto standard for SNMPv3 usage.

IBM switches and routers fully support the most secured SNMPv3 model. Authentication is achieved by either HMAC-MD5-96 or HMAC-SHA-96 authentication protocol. Confidentiality is done via CBC-DES Symmetric Encryption Protocol. Configuration starts with the User Security Model (USM) as shown below: • Define a user, the “name” is the log-in name to be used for access

snmp-server user <1-16> name <1-32 characters> • Select an authentication protocol (the option “none” should not be chosen here) and specify a

password snmp-server user <1-16> authentication-protocol {md5|sha|none} authentication-password <password value>

• Select an encryption protocol (the option “none” should not be chosen here) and specify a

password snmp-server user <1-16> privacy-protocol {des|none} privacy-password <password value>

• Delete a user

no snmp-server user <1-16> • Show a defined user configuration

show snmp-server v3 user <1-16> Once the USM has been defined, it can be used in the configurations of other functionalities such as View-based Access Control, Group configuration, and Target Parameter Configuration. • Select the security model for view-based access control, “usm” should be chosen

snmp-server access <1-32> security {usm|snmpv1|snmpv2} • Select the security level for view-based access control, “authPriv” should be chosen

snmp-server access <1-32> level {noAuthNoPriv|authNoPriv|authPriv} • Select the security model for the group, “usm” should be chosen

snmp-server group <1-16> security {usm|snmpv1|snmpv2} • Configure message processing model for generated SNMP messages, “snmpv3” should be

chosen snmp-server target-parameters <1-16> message {snmpv1|snmpv2c|snmpv3}

• Configure security model for generated SNMP messages, “usm” should be chosen

snmp-server target-parameters <1-16> security {usm|snmpv1|snmpv2} • Configure security level for generated SNMP messages, “authPriv” should be chosen

snmp-server target-parameters <1-16> level {noAuthNoPriv|authNoPriv|authPriv}

Logging Logging into an external syslog server should be enabled. An IBM switch/router has an internal log buffer that stores up to 2000 messages. However, it is local by nature. It would be difficult to meaningfully integrate distinct log information files from multiple machines across the network to develop a coherent network-wide perspective. Also, a network node suffering from a power outage may not be able to preserve the integrity of its log. A central syslog server with storage that is updated in real-time is much better suited for the task of network monitoring.

Page 11

The first step for proper event logging is to make sure the time and date on monitored devices are accurate. This of course can be done manually each node. However, this is an error prone methodology and is not scalable. Employing a centralized NTP server is a better method for synchronizing time/date information. The basic NTP configuration for the IBM Networking OS 7.7 is shown below: • Configure the primary NTP server for the switch/router time synchronization. The port

information specifies how the switch can reach the NTP server ntp primary-server <IP address>[data-port|extm-port|mgt-port]

o data-port: via the data port on the device o extm-port: via the external management port on the device o mgt-port: via the internal management port on the device

• Remove the primary NTP server

no ntp primary-server <IP address>[data-port|extm-port|mgt-port] • Configure the secondary NTP server for the switch/router time synchronization

ntp secondary-server <IP address>[data-port|extm-port|mgt-port] • Remove the secondary NTP server

no ntp secondary-server <IP address>[data-port|extm-port|mgt-port] • Set the device synchronization interval with the NTP server, in minutes, the default is 1440

ntp interval <5-44640> Please refer to the appropriate switch/router documentation for further advanced features such as NTP server authentication and IPv6. Syslog servers can be specified as following: • Configure the syslog server; up to 2 may be configured. The port information specifies how

the switch can reach the syslog server logging host <1-2> address <IP address> [data-port|extm-port|mgt-port]

o data-port: via the data port on the device o extm-port: via the external management port on the device o mgt-port: via the internal management port on the device

• Remove a syslog server

no logging host <1-2> address <IP address> [data-port|extm-port|mgt-port]

• Set the severity level for log messages sent to the syslog server. Only messages at the specified severity level and above (smaller in numerical value) are sent. The default is 7, which means all messages are sent.

logging host <1-2> severity <0-7> • Display the current syslog settings. Ignore the “severity” and “reverse” parameters, they are

only relevant to the locally buffered log messages to be displayed show logging [severity <severity level>] [reverse]

• The severity levels and their meanings are:

o 0 – EMERG: Indicates the system is unusable o 1 – ALERT: Indicates action should be taken immediately o 2 – CRIT: Indicates critical conditions o 3 – ERR: Indicates error conditions or invalid operations

Page 12

o 4 – WARNING: Indicates warning conditions o 5 – NOTICE: Indicates a normal but significant condition o 6 – INFO: Indicates an information message o 7 – DEBUG: Indicates a debug-level message

To enhance the legibility of the log content at the syslog server, the user is advised to set the logging source interface, which serves to identify the source from which the messages originated. This is very useful when multiple network nodes transmit log messages to the syslog server. The normal practice is to specify a local loopback interface for this purpose: • Specify the loopback interface number as the source interface

logging source-interface <1-5> By default, IBM switches and routers send log messages to the local and remote consoles (direct attached console, Telnet, and SSH) as well. This may not be desirable as it increases the local CPU processing load and network load for remote sessions. Console-directed log messages can be controlled by the following commands: • Enable log message delivery to the console, enabled by default

logging console • Disable log message delivery to the console

no logging console • Set the severity of log messages delivered to the console. Only messages at the specified

severity level and above (smaller in numerical value) are sent. logging console severity <0-7>

• Disable delivery of syslog messages to the console based on severity

no logging console severity

Securing the Data Path In terms of security, the control layer presents far more risks than the data path. It is therefore critical to harden the control layer. However, there are intrusion mechanisms that can be leveraged to take advantage of the data path, such as malicious meddling with the forwarding rules of switches/routers and overburdening the device CPU. The most common potential threats to the data path and ways to mitigate them are discussed below.

Source-Based Routing Source-based routing allows the originator of the packet to dictate the path to the destination. The path may be completely or partially specified (Strict or Loose Source Routing). The “record route” option logs the list of actual hops taken, providing the destination with the path back to the source. An attacker can use LSR to successfully spoof a source address and obtain responses. In general, source routing enables the possibility of routing traffic around network security controls and should be disabled. Source routing requires switches/routers to support the IP Option header. IBM switches and routers ignore the IP Option header and thus do not support source routing.

Page 13

Internet Control Message Protocol Redirect Routers use ICMP Redirect messages to inform hosts of a better path to the destination. It is typically generated when a router has to route a packet out of the same interface on which the packet was received. This operation can be adversely leveraged to cause the router to transmit a flood of ICMP Redirect messages, causing unnecessary network loads as well as possibly overloading the router CPU and the CPUs of the flood recipients. It is therefore recommended, when possible, to disable ICMP Redirect. ICMP Redirect commands from the IBM Networking OS 7.7 are shown below: • Enable ICM Redirect

ip routing no-icmp-redirect • Disable ICM Redirect

no ip routing no-icmp-redirect

IP Directed Broadcast IP Directed Broadcast enables the transmission of an IP broadcast packet to a remote subnet, at which point it is L2-broadcast to all nodes in the subnet. This method can be abused to flood stations on the remote network. Other more organized attacks have been based on the IP Directed Broadcast function. One example is a Denial-of-Service attack in which a victim’s address is spoofed and is used as the source address in an ICMP packet, the destination is an IP directed broadcast address. The recipients of the directed broadcast packets will all reply to the victim’s address, thus storming him/her out of service. It is recommended that IP Directed Broadcast be disabled. IP Directed Broadcast commands from the IBM Networking OS 7.7: • Enable IP Directed Broadcast

ip routing directed-broadcasts • Disable IP Directed Broadcast

no ip routing directed-broadcasts Disable IP directed broadcasts, supported by IBM NOS, see CLI CR Manual.

Default VLAN The default VLAN (usually VLAN 1, untagged) is intended as a catchall VLAN that may be conveniently used for management purposes or not-yet-fully-defined scenarios. It is normally used to quickly bring the basic infrastructure up and running so that further configuration and classification activities can make progress. Often, however, once a great amount of effort has been expended to set up and verify the network, the default VLAN is forgotten. Being forgotten does not mean it ceases to exist. In fact, as the default VLAN value of 1 is so commonly used in the industry, it would be of no surprise to find a massively sprawling default VLAN that spans the entire relevant network, including backbone, distribution and edge. This is a gaping security hole that must be avoided. The network planner/administrator should be conscious of the default VLAN and proactively prune it as the network evolves. Delaying this task will inevitably lead to a point in time where network configurations reach complex and unwieldy proportions and the fear of “breaking things that are working” will preempt remedy. It is good practice to start dealing with the default VLAN early. Keeping the Default VLAN secure is as important as any other VLAN in the network.

Page 14

Private VLAN A Private VLAN is a Layer 2 construct that limits connectivity between network nodes within a VLAN. In a normal VLAN, all devices within it can communicate freely. A Private VLAN partitions the normal VLAN into sub-domains as follows: • Primary VLAN:

o Nodes in the primary VLAN can communicate with each other as well as nodes in all other secondary VLANs.

• Secondary VLANs: There are two types of secondary VLANs o Isolated VLAN:

§ Nodes in an Isolated VLAN may only communicate with nodes in the Primary VLAN.

§ Nodes in an Isolated VLAN are not allowed to communicate with each other. § Nodes in an Isolated VLAN are not allowed to communicate with nodes in

Community VLANs. § A Private VLAN can contain only one Isolated VLAN.

o Community VLAN § Nodes in a Community VLAN may communicate with nodes in the Primary

VLAN. § Nodes in a Community VLAN may communicate with each other. § Nodes in a Community VLAN are not allowed to communicate with nodes in

other Community VLANs. § Nodes in a Community VLAN are not allowed to communicate with nodes in the

Isolated VLANs. § A Private VLAN can contain multiple Community VLANs.

Figure 3 below illustrates the inter-relationships between the components of a Private VLAN. The green arrows show allowed communication flows, the red arrows show communications flows that are illegal and blocked.

Figure 3: Illustration of Private VLANs

Page 15

The inherent nature of Private VLANs to segregate traffic makes them well suited as a security tool. A few possible use cases are: • Locating publicly accessible servers in an Isolated VLAN to minimize infection spread. By

definition, a compromised server in an Isolated VLAN cannot communicate with its neighbors, thus limiting the scope of the attack.

• For the scenario where publicly accessible servers require intercommunication for their operations (for example, for redundancy and/or distributed purposes). To enhance security, these servers could be placed in a Community VLAN. In case of a successful attack, the scope of the damage would be limited to that community.

• A network for guest access can be overlaid on an Isolated VLAN to achieve the functionalities of a completely untrusted network.

• For a dual network environment, workstations have a primary network where the users do all their work, and a secondary network where administrative tasks such as back-ups, monitoring, and management take place. In these configurations, it is common for most security measures to be deployed on the primary network with little effort extended to the secondary network as they tend to be “owned” by the IT department. This oversight could lead to a flat pervasive network that is primed for virus spread and security threats. A Private VLAN could be deployed here to increase security. One approach to contain threats would be to place the administrative servers in the Primary VLAN and the workstations in Isolated/Community VLANs.

• In a Virtual Desktop Infrastructure (VDI) environment, the virtual desktops can freely communicate with each other (the same as if they are all in the same VLAN). Such an arrangement is conducive to virus propagation and security risks. One possible control measure would be to deposit the virtual desktops in Isolated/Community VLANs and the commonly shared services (storage, database, etc.) in a Primary VLAN.

The following are commands relevant to Private VLAN configurations in the IBM Networking OS 7.7: • Set the VLAN as a Primary VLAN

private-vlan type primary • Remove the VLAN from the Primary VLAN status

no private-vlan type primary • Set the VLAN as a Community VLAN

private-vlan type community • Remove the VLAN from the Community VLAN status

no private-vlan type community • Set the VLAN as an Isolated VLAN

private-vlan type isolated • Remove the VLAN from the Isolated VLAN status

no private-vlan type isolated • Clear the Private VLAN type

no private-vlan type • Map a Secondary VLAN to a Primary VLAN. Go into the VLAN sub-menu of the Primary

VLAN and issue this command vlan <VLAN number> private-vlan map [add|remove] <secondary VLAN list>

Page 16

• Remove the Secondary VLAN to Primary VLAN mapping no private-vlan map [add|remove] <secondary VLAN list>

• Enable the Private VLAN

private-vlan enable • Disable the Private VLAN

no private-vlan enable • Display the Private VLAN configuration

show private-vlan [<2-4094>]

ACLs In networking, Access Control Lists are methods to classify and impose control measures on traffic. An ACL consists of two components: • The Qualifier: The classification is established based on L2/L3/L4 fields in the packet header.

Below are some examples of packet header fields that may be used: o Ethernet header (L2)

§ Source MAC address § Destination MAC address § VLAN ID § Ethernet Type § Ethernet Priority

o IP header (L3) § Source IP address § Destination IP address § Type of Service § IP Protocol number

o TCP/UDP header (L4) § Source socket number § Destination socket number § Flags

• The Action: Once classified, the packet is subjected to certain treatment. The most basic is

simply to drop it or allow it to pass. More advanced action may include packet modification, traffic engineering, and redirection.

ACLs represent one of the most powerful traffic control tools available to the network administrator. Once a traffic class has been categorized it may be denied network access, prioritized, metered, and its packets may be marked/modified. With the right combination of ACLs, the network manager is armed with the power to enforce a vast array of access policies. However, ACLs are less common and somewhat complicated. A lack of understanding in the way ACLs work can quickly lead to security gaps. The general characteristics of ACLs in IBM switches and routers are discussed in the subsequent paragraphs. • There are different types of ACLs, such as IPv4 ACLs and IPv6 ACLs. For each type, there

are a limited number of ACLs.

o An IPv4 ACL access-control list <1-640> ipv4 source-ip-address <IP address> <IP mask>

o An IPv6 ACL

access-control list6 <1-128> ipv6 source-address <IPv6 address> <prefix length (1-128)>

Page 17

• When an ACL is initially defined, the user is expected to enter an ACL number. This number

is selected from the pool of available ACLs.

o An ACL number in the range <1-640> must be specified access-control list <1-640>

• There is an implicit order of precedence among ACLs of the same type. The smaller ACL

number has higher precedence. • An ACL must have at least one qualifier. The command below shows the setting for VLAN

IDs.

o Specify the VLAN ID match for an ACL access-control list <1-640> ethernet vlan <VLAN ID> <VLAN mask>

• An ACL must have an action.

o Specify the action for an ACL access-control vmap <1-128> action {permit|deny|set-priority <0-7>}

• It is possible to enable an available counter for tracking the number of times an ACL has

been accessed. It is a very useful tool for debugging purposes.

o Enable statistics collection for an ACL access-control list <1-640> statistics

• Multiple defined ACLs may be grouped together. Why is it desirable to group ACLs together?

It serves as a convenient method to deal with multiple ACLs, especially when the number of ACLs is large. For example, if 50 ACLs are to be assigned to each of 10 ports, it would be quite unwieldy to enter the 50 ACLs 10 times, once for each port. The much more friendly method would be to place the 50 ACLs into one group, then assign the ACL group to each of the 10 ports.

o Add an ACL to a group. The number required following “group” is the group ID, the

number following “list” is the ACL number. access-control group <1-640> list <1-640>

• Defined ACLs or ACL groups must be assigned to one or more physical ports where actual

packets flow. A fully defined ACL or ACL group that is not assigned to a port provides no value.

o Add an ACL to a port. An ACL may be added to multiple ports; likewise, multiple

ACLs may be added to the same port interface port <port number or alias> access-control list <ACL number>

o Add an ACL group to a port. An ACL group may be added to multiple ports.

Likewise, multiple ACL groups may be added to the same port interface port <port number or alias> access-control group <ACL group number>

Page 18

• On each port, ACLs are strictly processed according to precedence. The individual ACL

number, the time and order with which the ACLs or ACL groups are added to the port are irrelevant. Once a match is made and an action is taken, no other ACL on the port is processed. This may be a source of confusion and warrant some clarification. Assume the following provision:

o ACL group #5 has the following ACLs: ACL number 22, ACL number 48, and ACL number 98.

o ACL group #32 has the following ACLs: ACL number 41, ACL number 77, and ACL number 88.

o ACL group #19 has the following ACLs: ACL number 17, ACL number 51, and ACL number 64.

o The above 3 groups are assigned to port number 8. In addition, ACL numbers 111, 71, and 6 are also assigned to that port.

o The resultant list of ACLs that exists on port 8 is, in high to low order of precedence: § ACL number 6 § ACL number 17 § ACL number 22 § ACL number 41 § ACL number 48 § ACL number 51 § ACL number 64 § ACL number 71 § ACL number 77 § ACL number 88 § ACL number 98 § ACL number 111

o Let’s say a packet arrives at port 8 that would match ACL numbers 22 and 71. The processing sequence would be: § ACL number 6 is inspected, no match is found § ACL number 17 is inspected, no match is found § ACL number 22 is inspected, match is found and the action associated with ACL

number 22 is executed. § ACL processing then terminates.

o Note that all packets matching ACL numbers 22 and 71 will never hit ACL number 71.

o Packets that do not hit any ACL installed on a port are treated normally by the L2/L3 data forwarding engine.

o ACLs are supported by the ASIC hardware engines in IBM switches and routers. The ACLs installed on a port are applied consistently to every single ingress packet on that port, at line-rate.

Exercise caution when dealing with ACLs, especially when the system configuration is large and complex. Be wary of ACL idiosyncrasies such as order of precedence, grouping, and catch-all. Be sure to test out a new configuration on a small damage-limited scale to ensure things work as expected.

Page 19

Physical Security Though not often thought of, the physical security of network devices cannot be overemphasized. Control layer and data path security measures have little value if anyone can walk up to deployed switches and routers and perform password resets. If permissible, that person now has complete control of the device and can bring down the network with ease. To limit this type of security breach and enhance product reliability, some common sense suggestions follow: • Administratively shut off ports that are known to be not in use. This prevents a casual

passerby from walking up to a switch/router and fish for connectivity. Keep in mind that even un-provisioned ports belong to a VLAN, the default VLAN. If this VLAN has not been treated, it is likely to pose security risks.

• Network equipment should be located in an enclosed facility with all access protected by measures such as keys or security card readers. Personnel access should be properly managed.

• If it is not possible to place a switch/router in a secured room, then at least consider secured racks and cages to limit access. And of course keep them locked at all times.

• Video surveillance is a superb security tool. Costs have gone down significantly in recent years. Aside from the tangible benefits provided, a camera mounted on the ceiling reminds everyone they are being watched. This is a valuable psychological deterrent.

• Keep equipment properly cooled. Heat, even within acceptable range, reduces the life span of electronic components. In a system with literally thousands of electronic components, the probability of failed components impacting system performance should be addressed. Pay attention to scenarios arising from inevitable daily activities, such as objects blocking intake vents and overcrowding cables. Also, be aware of thermal loops. These may develop when two devices of opposite native airflow are installed adjacent to each other. This is a negligent practice and should be avoided at all times.

• Electrical power is the lifeblood of electrical equipment. Ensure network devices are fed with quality power. Understand that the rated voltage specifies the energy potential at which the equipment operates and its amperage requirements. A high quality power source will be able to consistently maintain the rated output voltage throughout the current amperage draw range. If there are multiple network devices on the same power circuit, it is possible to develop an observable voltage drop due to copper loss. The device furthest away from the power source is subject to the highest voltage drop. To combat this, make sure the power circuits are built with sufficiently heavy copper gauge bus bars.

• Disorganized copper cables, optical cables and harnesses lead to confusion and potential accidents. While rarely spoken of when discussing network reliability, it is of fundamental importance for the L1 or Physical layer as this is where all the packets are actually moving back and forth as electrical or optical signals. Link flapping, loss of link, wiring plugged into the wrong port, etc. are akin to malfunctioning traffic lights, collapsed freeways, and broken bridges to cars and humans. A L1 dysfunction and/or instability can quickly lead to a significant network reliability issues. Power cables are another area requiring care. An inadvertently dislodged power cable may instantly remove the device from service. If a network element features redundant power supplies, which network equipment tend to do nowadays, make sure all power inlets are connected. If possible, connect the power inputs to different electrical distribution sources. For those necessary public installations, secure all cables, signal and power alike.

Page 20

The Human Factor The human factor is the one area that could defeat all security processes, procedures, and policies. An attacker befriending and gleaning personal information from an employee of an organization can quickly become a serious threat. • Password security has to be the most worrisome topic for security personnel. The root of it is

human memory. Strong passwords are simply hard to remember. On top of that, employees are often faced with multiple secured accesses, which lead to multiple passwords to remember. An organization cognizant of this difficulty could mitigate problem by implementing technologies such as Single Sign-On (SSO). Regardless, the following practices could help humans keep their passwords more secured:

o Try not to write down passwords, commit them to memory instead. If that cannot be avoided, then make every effort to keep the list private. Writing your password on a sticky note affixed somewhere in your cubicle is definitely not secured.

o Be creative, use passwords that are easy to remember but is hard to guess. o Don’t reveal a password to anyone, even security personnel. o Don’t talk about a password in the presence of others. o Don’t hint at the format of a password (such as “my daughter’s name”). o Don’t share a password with family members.

• Phishing is the act of attempting to acquire personal information (usernames, passwords, bank account number, etc.) by masquerading as a trusted entity. An example is someone supposedly from the IT Department calling to say there has been some issue with your account and he/she needs your log-in information to correct it. Though this form of information stealing is well known today, it can still be easily implemented on unsuspecting victims. Note the operative word “unsuspecting” here. Be vigilant, if sensitive information is being requested, it should be denied by default until further verification can be made. The idiom “err on the side of caution” suites this scenario perfectly.

• Careless task assignment increases risk. In the heat of emergencies and customer escalations, managers and planners tend to toss the next person in view on the job. Everyone has different backgrounds and skill set. Pairing tasks to personnel with mismatch expertise may lead to issues. People may become creative when they are ill-prepared, which may lead to mistakes that could have long lasting consequences.

• Network managers should have a detailed knowledge of their networks. Information such as the physical topology, ports not in use, and equipment roles (main distribution switch, core router, engineering hub, finance hub, etc.) should be clearly kept and faithfully updated every time changes are made. Just as important, the most updated information should be made available, or easily accessible, to pertinent personnel. If not easily available to approved IT personnel, a threat of human creativity may be inadvertently introduced. When people don’t know the answer, they will tend to make “educated guesses”, and that is often not good for network reliability.

• Resist the “while I am at it …” tendency. Changes to a working deployment ought to be taken with thoughtful and careful planning. In a network environment, changes often need to be made on multiple devices across the network to keep things consistent. Making a small impulsive change “while you are at it” will likely lead to trouble.

• Regularly back up switch/router configurations. How does this affect security? When a configuration is found corrupted and there is no back up, the task of reconfiguring the device, to bring it back up to where it was before, itself is a risky proposition.

• Once measures have been deployed, don’t let ignorance defeat them: o Lock down console terminals, don’t leave them unguarded when there is no one

around. o Don’t leave security racks/cages unlocked. o Don’t prop secured access doors open. o Be disciplined and follow established security guidelines at all time.

Page 21

Conclusion Security is not a one-day activity where an action is taken and then the task declared successful. Rather it is an awareness and recognition of ongoing and evolving threats. Realize that the “attackers” may be ex-industry professionals, who have intimate knowledge of network security mechanics. Individuals of this disposition are constantly seeking ways to circumvent these measures. An organization and its people need to be smart and disciplined to stay ahead of the threats they pose. This paper has presented a small set of basic tools and methods that can be leveraged to harden networks against security threats. Hopefully, it has increased the reader’s awareness to security practices and encourages him/her to research further into this area. Education, perseverance, and discipline have to be at the center of any security strategy.

References • IBM ISCLI – Industry Standard CLI Command Reference for Networking OS 7.7 • IBM Application Guide for Networking OS 7.7 • IBM EN4093 and EN4093R User Guides

For more information To learn more about IBM SDN solutions, please visit: ibm.com or contact your IBM representative.

For More Information IBM System Networking http://www.ibm.com/systems/networking/

Legal Information © IBM Corporation 2013 IBM Systems and Technology Group Dept. U2SA 3039 Cornwallis Road Research Triangle Park, NC 27709

Produced in the USA September 2013

For a copy of applicable product warranties, write to: Warranty Information, P.O. Box 12195, RTP, NC 27709, Attn: Dept. JDJA/B203. IBM makes no representation or warranty regarding third-party products or services including those designated as ServerProven® or ClusterProven®. Telephone support may be subject to additional charges. For onsite labor, IBM will attempt to diagnose and resolve the problem remotely before sending a technician.

IBM, the IBM logo and ibm.com are trademarks of IBM Corporation in the United States and/or other countries. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. For a list of additional IBM trademarks, please see www.ibm.com/legal/copytrade.shtml.

Other company, product, and service names may be trademarks or service marks of others.

IBM reserves the right to change specifications or other product information without notice. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. IBM PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you.

This publication may contain links to third party sites that are not under the control of or maintained by IBM. Access to any such third party site is at the user's own risk and IBM is not responsible for the accuracy or reliability of any information, data, opinions, advice or statements made on these sites. IBM provides these links merely as a convenience and the inclusion of such links does not imply an endorsement.

Information in this publication concerning non-IBM products was obtained from the suppliers of these products, published announcement material or other publicly available sources. IBM has not tested these products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

QCW03037-USEN-00