aruba security design best practices

7/21/2019 Aruba Security Design Best Practices

http://slidepdf.com/reader/full/aruba-security-design-best-practices 1/34



Table of ContentsSecurity Design................................................................................................................... 3

How to use this Guide..................................................................................................... 3

Authentication................................................................................................................. 4

Getting Started ............................................................................................................ 4Open Network............................................................................................................. 4

Captive Portal.............................................................................................................. 5

Choosing between VPN and 802.1x ........................................................................... 6VPN............................................................................................................................. 9

802.1x........................................................................................................................ 13

MAC Address Authentication................................................................................... 16Authentication Recommendations ............................................................................ 16

Encryption..................................................................................................................... 17

Getting Started .......................................................................................................... 17Open System ............................................................................................................. 17

WEP .......................................................................................................................... 18

WPA.......................................................................................................................... 19WPA2........................................................................................................................ 19WPA-PSK................................................................................................................. 20

Encryption Recommendations .................................................................................. 20

User Segmentation ........................................................................................................ 20Getting Started .......................................................................................................... 20

Firewall Segmentation .............................................................................................. 21

Physical Port Segmentation ...................................................................................... 22VLAN Segmentation ................................................................................................ 23

User Segmentation Recommendations ..................................................................... 24

User Roles and Firewall Policies .................................................................................. 25

Getting Started .......................................................................................................... 25Determining Roles .................................................................................................... 25

Firewall Basics.......................................................................................................... 26

Guest Firewall Policies ............................................................................................. 27Employee and Contractor Policies............................................................................ 29

Device Policies.......................................................................................................... 31

Roles and Firewall Policies Recommendations........................................................ 32Guest Access................................................................................................................. 32

Getting Started .......................................................................................................... 32

Low Security (Open Network).................................................................................. 32Medium Security (Guest Registration without Validation) ...................................... 33

High Security (Guest Login with Validation)........................................................... 34Guest Access Recommendations .............................................................................. 34



Security DesignA primary concern in wireless deployment is that of security. Security can broadly be

classified into three areas: privacy, integrity, and availability. Availability is generallyaddressed by including high availability and redundancy features in the network design,

and through enterprise IT policy such as change management and maintenancescheduling. Privacy and integrity, on the other hand, are directly addressed through

design of a wireless security policy.

How to use this Guide

This chapter provides an overview of planning and design guidelines for a wireless

security policy. Discussions are divided into the following general topics:

• Authentication

• Encryption

• User Segmentation

• User Roles and Firewall Policies

• Guest Access

Within each topic is a “Getting Started” section, a full discussion of the topic, and a set ofrecommendations. Read the “Getting Started” section if you are unfamiliar with the

technology or problem to be solved and need guidance in what questions to ask. The

bulk of each section is a full discussion of possible design choices, with the tradeoffs

between each highlighted. Finally, read the “Recommendation” section for a quick“cookie-cutter” solution to each problem. The cookie-cutter approach is designed to get a

network up and running quickly, and may prove useful for evaluations, trials, and pilots

where a full design and analysis is not practical.

IN ALL CASES, IT IS IMPERATIVE THAT THE CUSTOMER

EVALUATE WIRELESS SECURITY IN THE CONTEXT OF ANOVERALL ENTERPRISE SECURITY POLICY. RECOMMENDATIONS

MADE IN THIS GUIDE MAY NOT NECESSARILY MEET THE NEEDS

OF A PARTICULAR INSTALLATION. ARUBA WIRELESS

NETWORKS MAKES NO WARRANTY OR REPRESENTATION AS TO

THE SUITABILITY OF A PARTICULAR DESIGN OR PRODUCT OR

ITS FITNESS FOR ANY PARTICULAR PURPOSE OR USE.



AuthenticationOne of the first decisions that must be made when designing a wireless security strategyis if and how to authenticate users on the network. Some networks will be completely

open, others will use no authentication but will use encryption, and some will use both.

This section will explain how to select an authentication scheme, the tradeoffs involved

in each, and the dependencies on external systems. The following topics are addressed:

Getting Started

To begin, consider the following questions. Answers to these questions form the basis of

the decision criteria that will be used to select an authentication scheme. After answeringeach question, please see the appropriate section indicated in the table below. While

these questions are not comprehensive, they help serve as a starting point. A complete

discussion of each authentication method follows.

Decision Criteria Yes No

Do users and devices on thewireless network need to beexplicitly and uniquely identified

(authenticated) by the wireless

network?

See Open Network

Do internal or external policiesmandate the use of IPSEC (i.e.

FIPS 140-2, HIPAA)?

See VPN

Do you control and managesoftware installed on all wireless

clients?

See Captive Portal

Do you require strong encryptionwith automatic distribution of

encryption keys?

See Choosing between VPN and

802.1x

See Captive Portal

Do you have an existing VPN-

based remote access infrastructurethat you prefer to make use of for

wireless?

See VPN

Do you have “dumb” devices thatdo not support secure forms of

authentication?

See MAC AddressAuthentication

Open NetworkAn open network is one that does not perform per-user or per-device authentication. Anopen network does not necessarily imply that no encryption is used. The following are

all examples of open networks:

• Unencrypted network providing free public Internet access

• Network using static WEP encryption. Anyone who knows the WEP key hasaccess to the wireless network.



• Network using WPA-PSK (Wi-Fi Protected Access with Pre-Shared Key)encryption. Anyone who knows the pre-shared key has access to the wireless

network.

The key characteristic of an open network is that no identifying information is required

from the client before access to the network is granted. In the examples where encryptionis used, possession of the correct encryption key is sufficient evidence that the user is

authorized. Open networks should not be considered where even medium security is

required, for the following reasons:

• Lack of per-user or per-device authentication means that a compromised device

cannot be locked out of the network quickly.

• No per-user tracking is available, making it difficult to troubleshoot problems.

• Use of static encryption keys does not scale to large networks, since the keys must be updated on each device in the event of a re-key.

• Finally, use of static WEP is discouraged when used alone, as the encryptionalgorithm is widely known to be flawed.

In general, open networks should be used for providing public guest access or in smaller

low-risk networks where ten or fewer devices access the wireless network.

An open network is configured on a per-ESSID basis. It is possible to have one ESSID

make use of strong encryption and authentication, while another ESSID is set up as an

open network for the purpose of guest access. To configure an ESSID as open, use a rolederivation rule. A role derivation rule maps a particular parameter about the user – in this

case the ESSID the user associates to – with a user role in the system (see User Roles and

Firewall Policies). The role should be set up to allow appropriate access privileges to

users of the open network.

Captive Portal

Captive Portal authentication is familiar to anyone regularly utilizing public accesswireless hotspots or hotel in-room Internet access. After a user associates to the wireless

network, their device is assigned an IP address. The user must bring up a web browser

and pass an authentication check before access to the network will be granted. Portal- based authentication is the simplest form to use and requires no software installation or

configuration on the client. The username/password exchange is encrypted using

standard SSL encryption, preventing eavesdroppers from learning authenticationcredentials. A sample portal login screen is shown below.



Portal-based authentication is ideal for enabling guest authentication (see Guest Access.)

However, portal authentication does not inherently provide any form of encryption beyond the authentication process itself. In order to ensure privacy of user data, some

form of link-layer encryption such as WEP or WPA-PSK should be used when sensitive

data will be sent over the wireless network.

Choosing between VPN and 802.1x

In a wireless network where both encryption and authentication are needed, both can be

accomplished in multiple ways. The most common standards-based methods utilizeeither 802.1x with one of multiple encryption types, or Virtual Private Network (VPN)

technologies utilizing either IPSEC or PPTP. While some users choose to utilize both

methods at the same time, this is an uncommon scenario. Because the implementation ofan authentication protocol often involves configuration of the client devices,

understanding and choosing the authentication method up front is a critical planning step.

802.1x

802.1x is an IEEE standard used for authenticating client devices on any IEEE 802

network. It is an open authentication framework, allowing multiple authentication protocols to operate within the framework. 802.1x operates as a Layer-2 protocol.

Successful authentication must complete before any higher-layer communication with thenetwork is allowed, such as a DHCP exchange to assign an IP address. 802.1x is alsokey-generating, meaning that the output of the 802.1x process can be used to assign

dynamic per-user encryption keys (see Encryption for more details.) These encryption

protocols also operate at Layer-2, meaning that all data beyond the MAC header will beencrypted.



802.1x is ideally suited for wireless deployments, both because of the tie-in with dynamic

L2 encryption protocols and because of the native support in many operating systems.Use of 802.1x also blocks all communication with the network until authentication has

succeeded, allowing for greater perimeter security. 802.1x authentication tends to be less

intrusive to the user, allowing a single entry of username/password (single sign-on) to

authenticate them to the local computer, the wireless network, and server resources.However, 802.1x requires work – at times, significant work – to install or upgrade the

back-end authentication infrastructure and configure the client devices. Many users opt

to use VPN technology instead, because they can leverage existing remote accessinfrastructure already in place.

VPN

VPN technology has been in use for Internet-based remote access for a number of years.

Client and server components are available from many manufacturers, including Check

Point, Cisco, Nortel, Microsoft, and Netscreen. In general, the VPN client is installed on

mobile devices and is used to provide secure communication with the corporate network

across a non-secure network such as the Internet. Some users view a wireless network asany other non-secure network and choose to utilize the same VPN technology to secure

wireless access as well. VPN technology operates at Layer 3, meaning that an IP addressis required on the end device before the VPN client can operate. From an encryption

standpoint, the MAC and “outer” IP headers are transmitted cleartext, while the “inner”

IP header and data are encrypted. Because the IP layer is unprotected while using VPNtechnology, some form of L2 encryption such as WEP should always be used on a

wireless network.

VPN is normally chosen as an authentication method when users wish to utilize an

existing remote access infrastructure to provide wireless access. In many cases, clientdevices already have VPN software installed, and this software can be used un-modified

to provide wireless access. In addition, existing authentication servers can be used, and

in some cases, the existing VPN hardware can also be used. A further discussion of thesedesign principles can be found in the VPN section below. The downside of using VPNtechnology to secure the wireless network is that it is more intrusive to the user –

typically a VPN client must be launched and authentication credentials supplied before

the user can get access to the network. This complicates (but does not preclude) “singlesign-on”, since ideally a network connection needs to exist before Network Operating

System (NOS) authentication can take place. Still, VPN is popular in wireless networks

because of the perceived time-proven safety of the protocol, as well as the ability toinstall quickly without excessive modification of either the client or the authentication

back-end.

Comparison Table

To aid in the decision between the two technologies, the following table provides a

comparison between 802.1x and VPN as applied to an Aruba wireless deployment.

Feature 802.1x VPN

Client OS Support • Windows 98, 2000, XP • Windows 95, 98, 2000,



• PocketPC 2003

• MacOS

• Linux/FreeBSD/OpenBSD

• 3rd

-party software forWindows 98, 2000, ME,

XP, CE, PocketPC 2002,PocketPC 2003

• Novell

ME, XP

• PocketPC 2002, 2003

• MacOS

• PalmOS

• Linux/FreeBSD/OpenBSD

• Solaris, other commercialUnix

Authentication Backend • RADIUS server is

required.

• RADIUS server must haveexplicit support for

802.1x, including thespecific EAP type.

• Many commercial and

open-source RADIUSservers available

• To use ActiveDirectory orother databases, aRADIUS server must

provide the interface

• Can make use of many

types of authenticationservers, including

RADIUS, LDAP, Unix

password, Windows NT,ActiveDirectory,

TACACS, etc. Protocol

does not define a specific

back-end technology

• Aruba controller contains built-in user database that

can also be used for VPNauthentication

Authentication Pass-

through

Aruba controller does not

provide

authentication/encryption, but passes traffic through

to another device

• Not supported. Standardrequires that 802.1x

exchange be done betweenclient MAC address and

AP MAC address

• Supported

Single Sign-On

A user need only enterauthentication credentials

once for access to the

local computer, wirelessnetwork, and network

resources

• Supported, client-specific

• Windows has built-in

support, other clients vary

• Supported, client-specific

• In general, more difficult

to implement than for802.1x

Encryption • Chosen EAP type

provides encryption for

exchange of authenticationcredentials

• Generates key material to

support WEP, TKIP,AES-CCM for user data

encryption

• VPN protocol contains

built-in encryption support

•

DES, 3DES, MPPE, AES-CBC, others are available

– client-dependent

• Aruba controller supports

DES, 3DES, MPPE, AES-CBC

Authentication

Credentials• Password

• RSA token cards (not yet

• Password

• RSA token cards



How a user proves his or

her identity to the

network

widely supported)

• Digital certificates

• Digital certificates

Client Performance

Impact

Performance impact tothe client of using the

technology. Can be

important when older orlower-powered devices

are used.

• Low. Authentication can be demanding because of

public-key cryptography, but user data encryption isdone hardware

• Moderate to high. Allencryption typically done

in software – performancedepends on power ofclient device

Government Approval

Suitability for use wheregovernment agencies

require standards such as

FIPS or Common Criteria

• As of this writing,encryption based on WEP,TKIP, or AES-CCMP

(802.11i) is not approved

for use where FIPS 140-2

or CC is required• Approval process for

AES-CCMP is underway.

Uncertain outcome at this

time.

• 3DES and AES-CBC can be used, when equipmentis appropriately certified,

where FIPS 140-2 or CC

is required

Future Applicability • 802.1x required for WPA

and upcoming 802.11istandards

• 802.1x will likely seegrowing usage in wired

networks for port-based

authentication• Built-in client OS support

is growing

• Ties in with other security

technology, such as client

remediation

• Some use today in public

wireless hotspots, but

uncertain future in that

market

• Will continue to be used

for providing Internet- based remote access

VPN

VPN technology has been in use for Internet-based remote access for a number of years.Client and server components are available from many manufacturers, including Check

Point, Cisco, Nortel, Microsoft, and Netscreen. In general, the VPN client is installed on

mobile devices and is used to provide secure communication with the corporate networkacross a non-secure network such as the Internet. Some users view a wireless network as



any other non-secure network and choose to utilize the same VPN technology to secure

wireless access as well. VPN technology operates at Layer 3, meaning that an IP addressis required on the end device before the VPN client can operate. From an encryption

standpoint, the MAC and “outer” IP headers are transmitted cleartext, while the “inner”

IP header and data are encrypted. Because the IP layer is unprotected while using VPN

technology, some form of L2 encryption such as WEP should always be used on awireless network.

Discussion of VPN design is broken up into the following categories:

• Tunnel Termination

• Selection of VPN Protocol

• Client Selection

• Selection of Authentication Credentials

Tunnel Termination

In an Aruba network, VPN technology can be deployed in one of two ways. In the firstmethod, the Aruba controller acts as the VPN concentrator, terminating VPN sessions

from client devices. In the second method, the Aruba controller acts as a pass-throughdevice, allowing VPN traffic to reach another VPN concentrator located somewhere

inside the network. The Aruba controller will be set up in this case to allow only VPN

traffic through – all other traffic will be dropped by the Aruba firewall. Either methodachieves the goal of authenticating users and encrypting data, though in general

terminating the sessions on the Aruba controller leads to better security by pushing the

VPN concentrator to the edge of the network and providing for the performance needs of

a large wireless network. The two approaches are shown in the figure below.

When an existing VPN concentrator is already in use for remote access, often the choice

is made to continue using this for wireless. However, the best security, performance, and



management integration is achieved when using the Aruba controller for VPN

termination. The following table summarizes the tradeoffs between each approach.

Feature External VPN

Concentrator

Aruba Controller VPN

Termination

Security • User data protectedfrom eavesdroppers

• Users authenticated

• Small vulnerability

exists that could allowan attacker to send

unauthorized data to

portions of the internalnetwork between the

Aruba controller and

VPN concentrator.

Can be counteracted by using L2 encryption

such as WEP

• L2 encryption such asWEP should be used

to prevent attacks such

as DHCP spoofing

• User data protected fromeavesdroppers

• Users authenticated

• Any attack limited to the

wireless network only. No leakage of

unauthorized traffic to

the internal network.

• L2 encryption such asWEP should be used to

prevent attacks such as

DHCP spoofing

User Management • Split between Arubacontroller and VPN

concentrator

• Aruba controller has

no visibility into user

identity. Usersidentified in the

wireless network only

by MAC/IP address

• Username visibilityonly at VPN

concentrator

• Integrated in Arubacontroller. Wireless

association state tied to

user identity and security

state.• Aruba firewall can be

used to enforce per-user

policies

Performance • Limited by VPNconcentrator. Varies

by make and model

• Limited by Arubacontroller. Aruba 5000

rated up to 2Gbps ofencrypted throughput

Troubleshooting • Split between Arubacontroller and VPN

concentrator

• Integrated in Arubacontroller. Single

location for all wireless-related troubleshooting

and management.

Interoperability • Best. Typically VPN • Good. Aruba can



clients are made by the

same manufacturer as

the VPN concentrator

• Proprietary value-addfeatures may be

available

emulate many types of

VPN concentrators,

including Cisco and Nortel.

• Proprietary features most

likely not availableInstallation • If VPN clients are

already installed, best-

case scenario is that noinstallation or

configuration isrequired

• Aruba provides VPN

front-end “dialer” for

Windows 2000/XPclients. This automates

deployment when theVPN client embedded

with the OS is used.

This dialer can alsooperate alongside many

popular commercial

clients without causinginterference.

Selection of VPN Protocol

Three protocols may be used for VPN termination:

• L2TP over IPSEC – This protocol is used by the Microsoft Windows 2000/XP

embedded VPN client. If the Aruba VPN dialer is used on a Windows device,

this is the protocol that will be used. It is a combination of L2TP for tunnelingand IPSEC for encryption and transport.

• IPSEC/Xauth - This protocol is used by many 3rd

-party VPN clients such as

Nortel and Cisco. Xauth provides for group-based authentication keys.• PPTP – Point to Point Tunneling Protocol (RFC 2637) is supported by a number

of vendors, including Microsoft and Apple. There are also open-sourceimplementations. PPTP is encrypted using MPPE (Microsoft Point-to-Point

Encryption) and operates over UDP. PPTP is generally considered weaker than

IPSEC from a security standpoint, but is sometimes the only available optiondepending on the client device in use.

While the client device in use will generally determine which protocol is used,

L2TP/IPSEC or IPSEC/Xauth are the recommended protocols. IPSEC and PPTP can besupported simultaneously, if desired.

Client Selection

The choice to use VPN in the first place is often guided by the fact that a VPN client

installation already exists. In this case, the choice of a VPN client is already made. If

there is no existing VPN installation, or if the existing installation is not usable forwireless, the Microsoft Windows 2000/XP built-in VPN client is recommended, in

conjunction with the Aruba VPN Dialer application. Platforms other than Windows

2000/XP must be evaluated on a case-by-case basis.



Selection of Authentication Credentials

The selection of authentication credentials in a wireless VPN deployment is identical to

the selection in a standard Internet VPN deployment – both the wireless network and theInternet-connected VPN concentrator are exposed to untrusted networks.

When using PPTP, the only authentication credentials available are username and password. When using IPSEC, however, a number of different choices are available. For

IKE, both pre-shared key and certificate-based authentication are available. Certificate-

based authentication is unpopular because it requires a PKI deployment and requires eachclient to enroll a certificate. Pre-shared key authentication, however, could expose a

network to vulnerability in the event that an employee was to leave the company and still

possess the shared key. Note that this does not mean that an ex-employee would be able

to authenticate to the wireless network, only that the ex-employee would be able toestablish an IPSEC tunnel.

Once an IPSEC tunnel is established, typically a higher-layer authentication takes place

involving a username and password. A common and secure method of implementing password-based authentication is the use of token cards such as RSA SecurID. Aruba

supports a SecurID token caching feature that enhances such deployments by making it possible for a user to authenticate once per day. Subsequent authentications within a

defined time period will not require accessing the token card again.

802.1x

802.1x is an IEEE standard used for authenticating client devices on any IEEE 802

network. It is an open authentication framework, allowing multiple authentication

protocols to operate within the framework. 802.1x operates as a link-layer protocol.

Successful authentication must complete before any higher-layer communication with thenetwork is allowed, such as a DHCP exchange to assign an IP address. 802.1x is also

key-generating, meaning that the output of the 802.1x process can be used to assigndynamic per-user encryption keys (see Encryption for more details.) These encryption

protocols also operate at the link-layer, meaning that all data beyond the MAC header

will be encrypted. One encryption choice with 802.1x is Dynamic WEP. A better choiceis WPA.

There are three components to any 802.1x network:

• Supplicant – The 802.1x supplicant is the client portion of the authentication

system. An 802.1x supplicant communicates with the rest of the network usingthe EAPOL (Extensible Authentication Protocol over LAN) protocol.Authentication is carried out using one of a variety of EAP types.

• Authenticator – An 802.1x authenticator is a “gate-keeper”, preventingunauthenticated devices from accessing the network while allowing authenticated

traffic through. The authenticator relays link-layer EAPOL messages on one sideof the network to RADIUS messages traveling across an IP network on the other

side. In an Aruba wireless network, the Aruba controller acts as the authenticator.



• Authentication Server – In an 802.1x network, the authentication server mustuse the RADIUS protocol. RADIUS servers have been used for many years to

provide authentication services for dialup and other remote access networks.802.1x communication involves encrypted communication between the supplicant

and the authentication server using a particular EAP type. For this reason, both

the supplicant and the authentication server must support the same EAP type.

High-level 802.1x operation is shown in the figure below.

Selection of an EAP Type

Multiple EAP types are available inside of the 802.1x protocol. The following tablecompares features of each one. A full discussion of each protocol follows.

Feature PEAP EAP-TLS TTLS

Native support by Microsoft X X

Add-on support forWindows by 3

rd -party

software

X X X

Mutual authentication X X X

Username protected from

eavesdropping

X

Server-side digitalcertificate required

X X X

Client-side digital certificate

required

X

Client-side digital certificateavailable X X X

Supports SecurID token

cards

X X

• PEAP – Protected EAP is a proposed standard put forth by Microsoft and Cisco.It is widely deployed, mainly due to native support in Windows 2000 (SP3 or

later) and Windows XP. On the server side, Microsoft IAS, Cisco ACS, Funk



Odyssey/SBR, and many other RADIUS servers support the protocol. PEAP

typically uses a username and password for client authentication. At the time ofthis writing, there are slight differences between the Microsoft version of the

protocol and the Cisco version of the protocol. The Cisco version of PEAP

allows SecurID token cards to be used for password authentication, while the

Microsoft version of PEAP does not. It is expected that these differences will beresolved in the future.

• EAP-TLS – EAP with Tunneled Layer Security is supported by all major 802.1xsupplicants and authentication servers. It is ideal for device level authentication

or authentication using removable “smart cards”. Using EAP-TLS, clientauthentication is accomplished using a digital certificate installed on each client

device. If a PKI (Public Key Infrastructure) is already implemented in the

network (i.e. for VPN remote access), EAP-TLS may be a good choice. For newdeployments, the overhead involved with setting up a PKI usually precludes its

use. EAP-TLS is specified in RFC 2716.

• TTLS – Tunneled Transport Layer Security is a proposed standard primarily

backed by Funk Software. PEAP and TTLS are very similar, but differ slightly inthat the username need not be sent clear-text in a TTLS network. This provides a

security advantage over PEAP. However, at the time of this writing, TTLS is

only available as commercial software from Funk Software. While Funkdeployments are highly recommended, there is a monetary cost involved.

Selection of a RADIUS Server

The choice of an EAP type as well as the currently installed base of servers often

determines the choice of a RADIUS server. All servers have their relative merits, and

respective manufacturers should be consulted for assistance. The following table presents a non-exhaustive list of the more popular RADIUS servers available, along with

EAP types supported.

For pilots or trials, Microsoft IAS is a good choice, as it is included in Windows Server

2000 and Windows Server 2003. For large deployments, Funk Odyssey is the

recommended choice as it provides enhanced troubleshooting and diagnostic capabilities.

RADIUS Server PEAP EAP-TLS TTLS

Microsoft IAS X X

Funk Steel-Belted RADIUS X X X

Funk Odyssey X X X

Cisco ACS X X

FreeRADIUS X X

Selection of an 802.1x Client (Supplicant)

The choice of an EAP type as well as the currently installed base of clients often

determines the choice of an 802.1x supplicant. In general, there are three classes of802.1x supplicants:



• Supplicants built into the operating system – Many operating systems, such asMicrosoft Windows XP, Microsoft PocketPC 2003, MacOS, and others include

an 802.1x supplicant as a part of the operating system. These make a good choice because of their integrated nature and lack of additional monetary cost. However,

at times they do not have as much flexibility as may be available in add-on

software.• Supplicants built into the wireless NIC utility – Many wireless interface cards

include a client utility that acts as a radio manager and optionally as an 802.1xsupplicant. These are not recommended for large-scale deployments. The

primary focus of a client utility is on radio and driver management – most are

lacking advanced features or troubleshooting capabilities of other supplicants.

• Purpose-built add-on supplicants – These include software packages such asFunk Odyssey or Meetinghouse. These clients will optionally function as radio

managers as well, but their primary focus is on 802.1x supplicant functionality.

These often make the best choice for large enterprise deployments, but advantages

should be weighed against monetary cost and the support costs of adding

additional software to client devices.

MAC Address Authentication

MAC address authentication refers to the practice of examining the MAC address of anassociating device, comparing it to an internal or RADIUS database, and changing the

user role to an authenticated state. MAC address authentication is not a secure form of

authentication, as it is a simple process on most devices to change a NIC’s MAC addressin software.

MAC address authentication is useful for “dumb” devices that cannot support a moresecure form of authentication. Examples of such devices may include barcode scanners,

voice handsets, some types of printers or print servers, and many types of manufacturinginstrumentation sensors. User roles mapped using MAC address authentication should be

linked to extremely restrictive firewall policies to permit only the minimum requiredcommunication. Wherever possible, WEP encryption should also be employed to

prevent unauthorized devices from joining the network.

Authent ication Recommendations

The following recommendations are listed in order of the amount of labor required.

1. To quickly get a network up and running, use captive portal authentication

combined with static WEP encryption. For the back-end database, use theAruba controller internal database, populated with usernames and passwords. For a longer-term solution, use an external RADIUS or LDAP

server for the authentication back-end.

2. Where stronger encryption and authentication is needed, use VPN with

Windows clients. Captive portal authentication is initially used todistribute the Aruba VPN dialer to clients in a secure manner. Following

dialer installation, VPN access is used for all wireless activity.



3. Use 802.1x for deployments where little end-user intervention is desired.

Up-front installation and support requirements will be higher than withother methods, but long-term requirements will be lower. Where possible,

implement WPA.

EncryptionAuthentication ensures that only authorized users are able to access the network;

encryption ensures that unauthorized users are not able to intercept or make use out ofintercepted data. Encryption is a critical component of privacy on a wireless network,

since radio waves can and do travel outside of building walls.

Getting StartedThe choice of encryption method often follows naturally from the choice of

authentication method. To begin, consider the following questions. Answers to thesequestions form the basis of the decision criteria that will be used to select an encryption

scheme. After answering each question, please see the appropriate section indicated inthe table below. While these questions are not comprehensive, they help serve as a

starting point. A complete discussion of each encryption method follows.


Will the network be open to the

public or to outside visitors?

(open network)

See Open System

Have you selected VPN

authentication?

See Static WEP or

WPA-PSK . Lesssecure: see OpenSystem

Have you selected captive portal

authentication?

See Static WEP or

WPA-PSK

Have you selected 802.1xauthentication?

See Dynamic WEP,WPA, or WPA2.

Open System

In an open system, no link-layer encryption is used. This does not necessarily mean that

no encryption is used at all – VPN can be used on top of open systems, though this is notrecommended (see Static WEP for more details on why.) An open system is used whenthe IT staff has no control over the client – for example, public-access hotspots or visitor

networks. Open systems are also used when client devices are incapable of encryption –

for example, manufacturing facility instrumentation sensors.



Be aware that in an open system, anyone with some basic equipment (a laptop and

wireless card, for example) can eavesdrop on all communication over the wirelessnetwork.

WEP

WEP (Wired Equivalency Privacy) is an encryption protocol that was part of the original802.11 specification. WEP is considered a flawed standard with weak security protection,

and should not be used in an enterprise network unless absolutely required. Despite the

flaws of WEP, it is still widely deployed because of ubiquitous availability. WEP is

available in two forms – static WEP and dynamic WEP. Of the two, static WEP isconsidered the worst from a security standpoint, while dynamic WEP is considered

slightly more safe.

A recent demonstration by the FBI showed that WEP can be broken in less then five

minutes.

Static WEP

In a static WEP deployment, every client and every AP share the same encryption key.There are a number of problems with this model in a large enterprise deployment. First,

once the WEP key has been distributed, every user has the key. If one user leaves the

company, he or she might keep this key, configure a new device with that key, and use itto obtain unauthorized access to the network. To prevent this problem, the IT staff may

choose to re-key the network by setting up a new WEP key on every device. This brings

up the second problem with static WEP – key distribution and re-keying is virtually

unmanageable in a large network, as it involves touching each device. The third problemis a privacy concern – as long as one device has the WEP key, it can intercept data for

any other device on the network. Although all users will in theory be authorized users,not all users within an enterprise network should have access to all data. Confidentialdata such as human resources records should obviously not be available to unauthorized

people.

Despite these problems, there is one common use for static WEP – providing link-layer

encryption for a VPN deployment. VPN deployments rely on IPSEC or other network-

layer protocols for encryption and authentication. However, using VPN alone allows

potential attackers to obtain access to the Layer 2 network, along with valid clients. Thiscould enable an attacker to hijack DHCP or launch worm or virus attacks againstenterprise clients. Although ArubaOS provides mechanisms to prevent client-to-client

communication, use of static WEP or WPA-PSK is recommended for a greater degree of protection.

Static WEP can be used in a captive portal deployment, but should be restricted only to

smaller networks with few devices. WPA-PSK is a better alternative when available.

When no other alternatives are available, use of static WEP is highly preferable to using

no encryption at all.



Dynamic WEP

Dynamic WEP still uses the same encryption algorithm as static WEP. However, key

distribution is automated, with each device getting a different encryption key. Thismakes dynamic WEP more suitable for a large enterprise deployment. Dynamic WEP

still suffers from protocol deficiencies relating to the weak encryption implementation,

but many of the deployment issues relating to static WEP are solved. Whenever possible,WPA should be used instead of dynamic WEP.

Dynamic WEP requires 802.1x authentication in order to operate, as the key generationand distribution mechanisms of 802.1x are used. Most clients that support 802.1x also

support dynamic WEP. They should be configured by enabling WEP encryption, then

selecting an option similar to “Encryption keys are provided automatically.” Note that

there is no standard specifying how dynamic WEP operates – compatibility is primarily by general industry consensus. Thus interoperability issues do occur at times. Dynamic

WEP implementations should be tested before deployment. As a stronger alternative to

dynamic WEP, consider WPA or WPA2. WPA accomplishes the same purpose as

dynamic WEP, but is standardized and utilizes a stronger encryption protocol that solvesmany issues of WEP.

WPA

WPA (Wi-Fi Protected Access) is an interoperability standard put forth by the Wi-Fi

Alliance to solve immediate security needs of enterprise networks. It is an early snapshot

of the IEEE 802.11i specification and is designed to be forward compatible with thatstandard. WPA consists of two components:

• 802.1x authentication, as described in the previous section. Any EAP type isavailable, and has no ultimate bearing on use of WPA. RADIUS servers must

have support for 802.1x and the specific EAP type in use.

• TKIP encryption. TKIP (Temporal Key Integrity Protocol) is a new encryptionstandard designed as a replacement for WEP. TKIP is based on the same

encryption algorithm used by WEP (RC4) but utilizes a different implementation.

TKIP is supported on many available wireless interface cards. Because TKIP is based on the same underlying algorithm as WEP, older wireless interface cards

can be upgraded through software to support TKIP. TKIP involves a complex

hierarchy of encryption keys, but key distribution is automatic through 802.1x sothey are never entered directly by a user.

WPA requires support from the client operating system, as well as a driver update from

the NIC manufacturer. In some cases, a new firmware update to the NIC is also required.

Windows XP Service Pack 2 currently supports WPA, as do a number of other operating

systems and wireless clients.

WPA2

WPA2 (Wi-Fi Protected Access version 2) is an interoperability standard from the Wi-Fi

Alliance that establishes sections of the final ratified 802.11i standard required for

interoperability. WPA2 is very similar to WPA, and consists of the followingcomponents:



• 802.1x authentication, as described in the previous section. Any EAP type isavailable, and has no ultimate bearing on use of WPA2. RADIUS servers must

have support for 802.1x and the specific EAP type in use.

• AES-CCM (Advanced Encryption Standard – Counter with CBC MAC)

encryption. AES-CCM is a new protocol with no concessions to WEP.

WPA2, like WPA, requires support from the client operating system as well as adriver and NIC that is capable of running AES-CCM. As of this writing, WPA2 is

supported by a Windows XP Service Pack 2 hotfix, by Funk Odyssey Client 4.0, and by several popular NIC manufacturers.

WPA-PSK

WPA-PSK (Wi-Fi Protected Access with Pre-Shared Keys) is also known as “WPA

Personal”. It is best thought of as a replacement for static WEP, using TKIP instead of

WEP for encryption. The same key distribution issues inherent with static WEP apply to

WPA-PSK, though the standard goes one step further by encrypting each user’s data with

different derived keys. WPA-PSK is best suited for a small office or home officedeployment with a small number of devices attached. In an enterprise setting, WPA-PSK

may be useful as link-layer protection for VPN.

WPA2-PSK is also available. WPA2-PSK is equivalent to WPA-PSK, except that AESreplaces TKIP as the encryption algorithm. If WPA2-PSK is available, it is preferred

over WPA-PSK.

Encryption Recommendations

1. For ease and speed of deployment, use WPA-PSK or WPA2-PSK.

Combine it with a supplemental encryption mechanism such as VPN.Understand the key distribution issues with pre-shared keys when using

them in an enterprise environment.2. If 802.1x can be used for authentication, wherever possible utilize WPA or

WPA2.3. Avoid use of WEP unless absolutely required. WEP is not safe for

enterprise deployments.

User Segmentation

Getting StartedMany enterprise wireless LANs provide access to multiple classes of users. Most often,this includes employee access and guest access, and may optionally include multiple

classes of employee access (see Determining Roles). Aruba AirOS provides two main

approaches to separating user traffic, one based on an internal firewall and the other based on logical link-layer (Layer 2) separation. To a large extent, how this is done

depends on how the overall network is built and addressed. Examine the table below to

determine which method, if any, applies.




Will the network provide serviceto multiple classes of users whose

traffic needs to remain separated?

Skip this sectionand move to User

Roles and Firewall

PoliciesWill different classes of traffic

need to be directed to physically

different pieces of equipment?

See Physical Port

Segmentation

Will the uplink equipment acceptVLAN tags, and will the client

devices be assigned to different IP

subnets based on the class ofuser?

See VLANSegmentation

Does the uplink network lack the

ability to separate user traffic?

See Firewall

Segmentation

Firewall Segmentation

When using the Aruba embedded firewall, network traffic belonging to different user

classes will be forwarded across the same IP network to the same uplink device. Theuplink device does not provide separation of traffic, and typically has no knowledge that

different user classes exist. This is typical in smaller networks, such as in branch offices,

where only a single IP subnet is assigned to the entire network and the network is flat.

When firewall segmentation is used, different classes of users are assigned to different

roles. Each role has an associated firewall policy that determines which destination hosts,networks, and services the clients in that role may access. Firewall policies can be

specified by source address, destination address or network, IP protocol, and TCP or

UDP port numbers. The figure below shows all traffic belonging to employees being

permitted, while traffic belonging to guests is restricted to Internet traffic only. Anytraffic coming from a guest user destined to a restricted destination will be dropped and

optionally logged.



Physical Port Segmentation

When physical port separation is used, different classes of users will be separated into

different port-based VLANs inside the Aruba controller. These VLANs are internal to

the Aruba controller and have no bearing on 802.1q VLANs outside the controller. Two

or more uplink ports will be connected to the Aruba controller, one in each VLAN. Alltraffic from clients in one class will be directed to their respective uplink. For guest

traffic, the uplink often directs traffic to the DMZ outside the firewall. This is depicted in

the figure below.



It is important to note that when using port-based segregation, the following caveatsapply:

1. Clients in different classes must be assigned IP addresses from differentsubnets.

2. The optimal authentication scheme for this type of deployment is 802.1x,since authentication completes before the client is assigned an IP address.

3. If clients in different user classes also use different authentication and

encryption schemes, the clients should associate to different ESSIDs. Ifthis is not done, it is possible that broadcast traffic from a “private”

network could be flooded to a “public” network and inadvertently leaked.

VLAN Segmentation

When VLAN segmentation is used, traffic from different user classes will be forwardedto a single uplink device but will have different 802.1q VLAN tags prepended. In thismanner, logical link-layer separation of traffic is maintained, but multiple dedicated

physical connections are not required. Functionality is equivalent to physical port

segmentation, but this method achieves logical separation rather than physical. Often,

this type of segregation will have guest traffic placed on a dedicated VLAN whose exit point is a port on the firewall. VLAN segmentation is shown in the figure below.



It is important to note that when using VLAN-based segmentation, the following caveats

apply:

1. Clients in different classes must be assigned IP addresses from different

subnets.2. The optimal authentication scheme for this type of deployment is 802.1x,

since authentication completes before the client is assigned an IP address.3. If clients in different user classes also use different authentication and

encryption schemes, the clients should associate to different ESSIDs. If

this is not done, it is possible that broadcast traffic from a “private”network could be flooded to a “public” network and inadvertently leaked.

User Segmentation Recommendations

The following general recommendations apply:

1. Firewall-based segregation of users is more flexible, scales better, andmakes no assumptions about underlying authentication schemes. If no

VLAN tagging is used as part of the network design, use firewall-basedsegmentation.

2. Link-layer segregation of users is less prone to error, but also is less

scalable in a large network – particularly where multiple controllers exist.Use link-layer segregation if local security policy requires it or if VLAN

tagging is already being performed for network design reasons. Physical



port segmentation and VLAN segmentation provide equivalent

functionality.

User Roles and Firewall PoliciesGetting StartedIn the earlier days of wireless LAN deployment, many enterprises took all wireless traffic

back outside the corporate firewall, where users had to come back in just as though they

were coming from the Internet. This was a good approach security-wise, but led to sub-optimal network design and poor performance as WAN-grade firewalls were suddenly

forced to support multiple air-speed access points. This technique also suffered from a

“one size fits all” approach to access control, giving all wireless users the same rights on

the network. Typically a wireless user would get full access to the entire network in thismodel, as traditional corporate firewalls were built to protect networks from other

networks, rather than identify individual users.

Today, a better alternative is available. Aruba Networks has built a stateful application-aware firewall into every mobility controller, with different firewall policies available for

each wireless user. This firewall is implemented in hardware, giving it the performanceto support enterprise wireless speeds. The firewall is compliant with ICSA corporate

firewall certification standard 4.0, giving security administrators the confidence needed to

deploy it in critical locations such as a wireless entry point to the network.

Why are firewalls important? Aruba believes that even after strong encryption has been

used and authentication has been successful, wireless users should still be fundamentally

less trusted than wired users. Wired users have a physical location that can be easilytraced, since they sit at the end of a cable. There is no such principle in a wireless

network – a user could be in the parking lot, using a stolen laptop with a stolen password.In such a network, there is no reason to treat all users the same – a sales employee doesnot have the same access needs as a finance employee, who does not have the same

access needs as someone working in the mail room. Firewalls are an effective layer of

protection and should be a mandatory part of a multi-layer security strategy.

Determining Roles

All firewall policies depend on the role of the user. A role can be “employee” versus

“guest”, or more granular such as “sales user, marketing user, finance user, IT staff”.Ultimately, the role of a user determines all access privileges in the wireless network, so

some thought should be given to how best to provision these policies.

One framework for designing roles is to use the “employee, contractor, guest” model.This is the simplest security model, and can allow roles to be determined without any

reliance on an external authentication server. Typically, an employee is given access

(either full or restricted) to the entire network, a guest is given limited Internet accessonly, and a contractor has varying privileges depending on their requirements. The

simplest method of splitting up access by role is to use default role settings in thecontroller. A different default role is configured for each authentication method, and in



the absence of role information from an external authentication server, a user

authenticating through a given authentication mechanism will be assigned thecorresponding role. For a basic configuration, use captive portal authentication for both

guests and contractors, and a more secure authentication scheme such as 802.1x or VPN

for employees. The role for a guest login through captive portal will automatically be

“guest”, the default role for an authenticated captive portal user will be configured as“contractor”, and the default role for any 802.1x or VPN user will be configured as

“employee”. In some cases, a separate contractor role may not be needed, simplifying

the design even further.

The above approach is a good starting point, but still suffers from the “one size fits all”

problem discussed in the introduction. A better approach is to segment users by their rolein the enterprise, through use of role or group membership features already built into

many authentication servers. A typical enterprise using Windows may run a domain

controller that performs authentication for Windows users based on an Active Directory

server. The Active Directory server allows users to be segmented into groups, typically

for controlling access to network storage and applications. If this infrastructure alreadyexists, it makes sense to re-use the group identity to provide role information to the

wireless network. This is accomplished through a feature known as role derivation. Rolederivation allows group membership or role information to be determined for a user,

either through a local parameter such as ESSID or AP location or, as described here, from

an authentication server.

Another use for roles is in restricting network activity of devices that cannot perform

more secure authentication, such as VoIP handsets or barcode scanners. These devicestypically have no ability to authenticate, and at best, can support static WEP. These

devices can be allowed on the network using MAC address authentication, and can begiven a role with extremely restricted firewall policies. For example, a VoIP handset can

be allowed to communicate using SIP only to the VoIP gateway.

Once a role framework has been established, corresponding firewall policies can be

created.

Firewall Basics

Firewall policies are often confused with access control lists (ACLs), but the two have

some major differences.

• Firewalls are stateful, meaning they understand flows in a network and keep trackof the state of sessions. If a policy is enabled to allow telnet outbound from a

client, a firewall will understand that inbound traffic associated with that sessionshould be allowed. ACLs have no memory of what came before – at best, ACLscan look at the “SYN” flag in a TCP packet, treating the session as new if the flag

is set and treating the session as “established” if it is not. This works for

“normal” traffic but is ineffective against many types of attacks.

• Firewalls in an Aruba mobility controller are dynamic, meaning that addressinformation in the rules can change as the policies are applied to users. For

example, a firewall policy containing the alias “user ” can be created. After the



policy is applied to a particular user, thisalias is automatically changed to match

the IP address assigned to the user. An ACL is typically a static packet filter, withIP addresses hard coded into the rule.

• Firewalls are bi-directional. While ACLs are normally applied either to trafficinbound to an interface or outbound from an interface, firewalls automatically

work in both directions. Firewall configuration can be simpler than ACLconfiguration for this reason, since the administrator does not need to worry about

building consistent input and output ACLs.

At a basic level, a firewall rule is defined using the following format:

<source> <destination> <service> <action(s)>

Field definitions are as follows:

• Source- this field represents an IP source address – either a single address or arange of addresses

•

Destination – this field represents an IP destination address – either a singleaddress or a range of addresses

• Service – this field represents the type of traffic being carried. It could represent

an IP protocol type (TCP, UDP, ESP, ICMP, etc) or a TCP/UDP port number. Inthe case of TCP or UDP port numbers, the service field can represent a single port

number or a range of port numbers.

• Action – this field tells the firewall what to do with packets that match the rule.Examples can be simple, permit or deny for example, or can contain more

complex actions such as setting QoS fields, logging the packet to a logfile, or

performing a NAT operation.

Guest Firewall Polic iesOne of the most compelling uses of wireless technology is to enable guest access to the

Internet. Visitors to a company often appreciate being able to check email, show a

demonstration, or pull down a critical file from a server. Using wireless, employees inthe same room can also have access to their own resources, all while security and

network administrators remain comfortable that visitors are not plugging into a wired

Ethernet port and getting access to internal networks. Strategies for deploying guestaccess are discussed in more depth in the Guest Access section.

There are two main ways to segment guest access. One is through the use of Layer 2VLANs or physical ports. In this model, guest traffic is forwarded over a special guest

VLAN, or out a physical port attached directly to the corporate DMZ. Guest traffic nevertouches the internal network in this model. Firewall policies are used in this model only

to restrict the types of traffic visitors are able to send – for example, restricting SMTPaccess so that the enterprise network is not used as a launch point for spam.

The VLAN method of guest segmentation is a secure one, but in some cases can lead tomore complex network configuration, particularly when multiple mobility controllers are

deployed. The need to string cables or configure VLANs can be reduced or eliminated



by allowing the firewall to perform guest segmentation. In this model, guest data

traverses the same network as employee data, but is restricted by firewall policies.

For a basic guest firewall policy, first define a netdestination containing all IP subnets

that make up the corporate internal network, as shown in the figure below. This example

assumes that the internal network is made up of 10.0.0.0/8 and 172.16.0.0/16.

Internal Network Definition

Next, build the firewall policy. This policy will perform the following actions:

1. Allow DHCP traffic between the guest user and two DHCP servers at 10.1.1.13and 10.1.2.13. The initial DHCP address will be assigned through a control

firewall policy, and this rule allows DHCP renewal messages to pass.

2. Allow DNS traffic between the guest user and two DNS servers at 10.1.1.14 and10.1.2.14. This enables DNS lookups to work properly.

3. Allow HTTPS traffic from the user to the Aruba controller. This allows captive portal functionality to work properly.

4. Block all other traffic to the internal network

5. Allow HTTP and HTTPS traffic to and from the Internet

6. Allow POP3 and POP3S traffic to and from the Internet7. Allow VPN tunnels to be established

8. Block all other traffic.

This policy provides what most visitors need – Web access along with the ability toestablish a VPN tunnel back to their corporate location. Notably absent from the list is

SMTP. Opening SMTP access to visitors could allow the network to become a launch

point for spam – a headache that can easily be avoided. Most corporate users do not sendemail directly through SMTP, or if they do, they send it through their own mail server

located behind their corporate VPN concentrator.

A sample firewall policy is shown in the figure below.



Guest Firewall Configuration

Finally, apply the firewall policy to the guest role. The only policy applied to the guest

role should be the one just created. By default, guests also have the “control” and

“cplogout” policy applied to them – be sure to remove these. The components of these policies necessary for guest access have been incorporated into the policy above. The

order of policy application is important, as policies are executed from top to bottom.

Employee and Contractor Policies

The same general configuration principles described above for guest access can also be

applied to employees and contractors. A basic employee firewall policy may be as

simple as “any any any permit”. However, in many ways such a policy defeats the purpose of using a firewall in the first place. It is a much better practice to determine

which protocols, applications, and destinations users need to access while using wireless

connections, and permit only what is necessary. In some cases, wireless users may be provided less access to the network than wired users, depending on the overall risk level.

Some enterprises in fact choose to permit only email and Internet access over wireless,

preferring not to provide access to financial systems or network storage at all. Whilesuch a policy is extremely restrictive and will be unpopular with users, overall security

risks must be balanced with business needs for the wireless network.



As discussed above, an employee or contractor firewall policy can be applied universally

to all employees or segmented based on role. Using role-based access policies is a betterchoice from a security standpoint, but may not make sense in the overall environment.

Each of the sample approaches below may be deployed in either a “universal access”

manner, or in a “role-based access” manner.

Protocols Restricted, Destinations Unrestricted

Using this approach, wireless users are given the ability to use only specific protocols –such as HTTP, HTTPS, Exchange, DNS, and others required for common applications to

function. A mail room employee may not need access to SAP, while a finance employee

would. Using this approach with role-based access, a mail room employee could still

contact the SAP server, but only using HTTP, DNS, or some other permitted protocol –in theory, this would not allow access to sensitive information since the SAP server

would not respond on those ports.

• This approach is simple because the “destination” field in all firewall rules will be

set to “any”.• It does not require the firewall policy to be updated when a server is moved or a

new server is added.

• This approach works well at restricting certain applications that the administrator

has deemed “undesirable” or too bandwidth-hungry for the wireless network, such

as FTP or streaming video.

• Finally, the approach can help contain the spread of some viruses and worms,since it may block ports the worm or virus needs to spread.

The protocol-restriction approach does not provide the highest degree of security, eitherin a universal access configuration or in a role-based configuration, since destinations for

traffic are not restricted. However, it provides a good balance between security andadministrative requirements.

Destinations Restricted, Protocols Unrestricted

This approach is the exact opposite of the previous one. Using this approach, wireless

users are permitted access to specific destinations (networks, servers, etc.) using any

protocol. This approach could be used in a universal access design, but makes muchmore sense in a role-based design.

• Using this approach, mail room employees would be denied access to the finance

SAP server entirely, while finance employees would be denied access to serverscollecting barcode scanning data from the mail room.

• The wireless firewall must be updated each time a server is added, removed, orchanged. If such changes happen often, this requirement could be a large

administrative overhead compared to the previous approach without necessarily providing a corresponding gain in security. If departmental servers are segmented

by subnet, the use of address ranges can ease this burden.



• This approach is not as effective as the previous one at protecting against wormsand viruses.

Destinations and Protocols Restricted

This approach, combined with the use of role-base access control, provides the greatestlevel of security.

• Continuing the previous example, finance employees would be able to access the

finance SAP server only on ports used by SAP. Mail room employees would be

able to access only the server collecting barcode scanning data on its required ports. The two groups would not be able to access each other’s servers.

• The greatest protection against viruses and worms is provided by this approach,

since communication is restricted to specific servers and specific protocols.

• The wireless firewall must be updated each time a server is added, removed, or

changed. If departmental servers are segmented by subnet, the use of address

ranges can ease this burden. However, the gain in security provided by thisapproach may offset the administrative overhead.

Mixed Approach

Depending on the security needs of the enterprise, it may make sense to use a mixedapproach to firewall policies. Users who travel frequently, such as sales employees, may

need highly restrictive policies to counteract the risk associated with their laptops being

subject to theft or hacking. IT staff may have a completely open firewall policy, whilefinance employees may have a lightly restrictive policy. Mixed use policies are best

addressed in the context of an overall enterprise security policy.

Device Polic ies

When devices such as barcode scanners do not support secure authentication, MAC

address authentication may be used along with static WEP. It is important to rememberthat MAC addresses can be easily spoofed, so MAC address authentication should never

be considered a secure form of access control. When MAC address authentication is

used, devices should be placed into a role with very limited firewall policies. This

ensures that even if the WEP key is cracked and a MAC address is spoofed, the potentialfor damage will be limited. In addition, “Weak WEP Detection” should be enabled to

ensure that devices are not using a poor implementation of WEP. This will help

minimize exposure to WEP cracking.

To construct a firewall policy for these devices, determine the bare minimum protocols

and destination addresses required for the devices to function. Construct a policy thatallows only these protocols and destinations. In addition, set the final rule in the policy

to:any any any deny l og



By setting this policy to log firewall violations, administrators will be notified if an attack

is underway, and can then change the WEP key if required.

Roles and Firewall Policies Recommendations

4. As a quick-start method, set up one role called “employee”, and apply the“allowall” firewall policy. Have all authenticated users map to this role.

5. Add additional roles, such as a guest role, as necessary.

Guest AccessOne of the primary benefits of having a wireless network is the ability to provide Internetor limited Intranet access for authorized visitors to a corporate location. This can be done

without need for extensive conference room cabling or designated “visitor-only” wall

jacks, and without regard to the number of people needing access. Because guest accessinvolves outside persons utilizing enterprise network resources, it is important to design

how guest access will be provided

Getting StartedAll guest access should be restricted using firewall policies (see Guest Firewall Policies

for more information) to prevent unnecessary use of resources. Firewall policies may beaugmented with time-based restrictions such that guest access only functions during

normal business hours. In addition, guest access may be rate-limited using bandwidth

contracts to prevent a visitor from over-utilizing wireless bandwidth.

There are three general approaches to guest networking. A summary of the three

methods, in increasing order of security, follows:

• Low Security – This network provides open access to anyone associating to thenetwork. No form of authentication or registration is required.

• Medium Security – This network provides access to users who register for access

using a portal website. Registration is not validated.

• High Security – This network provides access only to validated guest users.

Low Security (Open Network)

The open network is the simplest type to set up, because no authentication of any type is

needed. The following recommendations apply for an open guest network:

1. Set up a separate ESSID for guest access. Map all users on the guestESSID into the guest role as described in Open Network .

2. Apply a guest firewall policy to the guest role. Configure the firewall policy to be extremely restrictive – for example, only allowing HTTP,

HTTPS, and VPN traffic (see Guest Firewall Policies).

3. Ensure that appropriate user segmentation is in place, either through thefirewall or through link-layer segmentation, to prevent mixing of guest

and employee traffic.



4. Configure a rate-limiting bandwidth contract and apply it to the guest role.

A good starting value is 1Mbps.5. Consider configuring the guest firewall policy with time ranges so that it is

active only during business hours.

6. Consider configuring the guest ESSID so that it is only active on APs near

conference rooms or other areas where visitors will be. Consider alsodeploying dedicated APs in each conference room and setting transmit

power to the lowest level on those APs. While this is not a foolproof

solution, it will minimize access outside the building.7. Be prepared for the fact that “war drivers” will likely find the network,

map it, and at times use it for free Internet access.

Medium Security (Guest Registration without Validation)

In the medium security guest network, guests will need to register for access through a

captive portal web page. Registration consists of providing their email address. Theemail address is not verified or validated by the system, but can be stored and manually

validated, if desired. For example, the email address registered by each guest could beautomatically emailed to a front desk receptionist. If the receptionist does not recognizethe email address as valid, he or she could disconnect the user through a web form. From

a security standpoint, however, the medium-security model is not significantly better than

the open network, since any email address can be entered.

The following recommendations apply for the medium-security guest network:

1. Set up a separate ESSID for guest access. Do not use a role-derivation

rule to automatically map users to the guest role. Instead, enable captive

portal along with the captive portal “allow guest logon” option.

2. Apply a guest firewall policy to the guest role. Configure the firewall policy to be extremely restrictive – for example, only allowing HTTP,

HTTPS, and VPN traffic (see Guest Firewall Policies).

3. Ensure that appropriate user segmentation is in place, either through thefirewall or through link-layer segmentation, to prevent mixing of guest

and employee traffic.4. Configure a rate-limiting bandwidth contract and apply it to the guest role.

A good starting value is 1Mbps.

5. Consider configuring the guest firewall policy with time ranges so that it isactive only during business hours.




solution, it will minimize access outside the building.

7. Be prepared for the fact that “war drivers” will likely find the network,map it, and at times use it for free Internet access.



High Security (Guest Login with Validation)

In the high-security model, guests must provide a valid username and password throughthe captive portal web page before obtaining access to the network. The username and

password may be obtained in a number of different ways:

• A guest login and password may be set up with access information posted in

conference rooms and other areas where guests may be present. Usernames and passwords may change on a daily or weekly basis.

• A guest login and password may be set up with access information provided by afront-desk receptionist. The receptionist may hand out different login information

to each visitor, thus keeping a record of which person used which login. Access

information may change on a daily or weekly basis.

• With a small amount of software development, a visitor sign-in computer in alobby area could print visitor badges that would contain, among other things, a

wireless network username and password. This username and password could be

taken from a pool, or could be automatically provisioned in a RADIUS server atthe time of registration.

• Frequent visitors or contractors could be given a permanent username and password for the guest network.

The following recommendations apply for the high-security guest network:

1. Set up a separate ESSID for guest access. Do not use a role-derivation

rule to automatically map users to the guest role. Instead, enable captive portal. Do not enable the captive portal “allow guest logon” option.

2. Apply a guest firewall policy to the guest role. Configure the firewall

policy to be extremely restrictive – for example, only allowing HTTP,HTTPS, and VPN traffic (see Guest Firewall Policies).

3. Ensure that appropriate user segmentation is in place, either through thefirewall or through link-layer segmentation, to prevent mixing of guestand employee traffic.

4. Configure a rate-limiting bandwidth contract and apply it to the guest role.

A good starting value is 1Mbps.5. Consider configuring the guest firewall policy with time ranges so that it is

active only during business hours.




solution, it will minimize access outside the building.

Guest Access Recommendations

1. For the easiest and fastest method of setting up guest access, implementthe medium-security model using captive portal.

aruba security design best practices

Documents