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 units 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, spouses 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, users 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 industrys 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 victims
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
victims 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 Lets 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 Dont reveal a password to anyone, even security personnel.
o Dont talk about a password in the presence of others.
o Dont hint at the format of a password (such as my daughters name).
o Dont 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 dont
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, dont let ignorance defeat them:
o Lock down console terminals, dont leave them unguarded when there is no one
around.
o Dont leave security racks/cages unlocked.
o Dont 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 readers
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