Note: For answers to all learning checks, refer to the Appendix.

2

Deploy Trusted Certificates to Aruba Solutions

EXAM OBJECTIVES

✓ Describe PKI dependencies.

✓ Set up appropriate certificates and trusted root CAs on CPPM.

Assumed knowledge

Basic understanding of asymmetric encryption

Basics of managing Aruba network infrastructure products

Digital certificates and PKI

To protect their valuable resources and implement a Zero Trust Security network, companies must secure wireless access. Best practices dictate securing WLANs with certificate-based authentication. However, many companies avoid certificates because they do not understand them or believe that they are too hard to manage.

In the following section, you will review and expand on your knowledge of digital certificates and public key infrastructure (PKI).

Digital certificate

You will now review certificates and how they exist within a PKI. You will also review ways that devices can obtain and use certificates.

A digital certificate enables the certificate owner to tie its identity to a public key. As shown in Figure 2-1, this public key is also tied to a private key, held by the owner. The entity can then use the private key for various purposes such as “signing” data and authenticating itself.

Figure 2-1: Digital certificate

In addition to the owner’s identity, public key, and authorized usages for that key, the certificate includes the name of the entity that issued the certificate and that issuer’s signature. The issuer name and signature essentially provide other entities a reason to trust that the identity within the certificate is real. Think of a certificate like a governmental ID. Anyone can print out a page with a picture of their face and a name. You only trust that the name is legitimate if a trusted government issued the ID.

Finally, a certificate also has a validity period associated with it. Like a passport or other ID, the ID is not good forever; it must be renewed.

The following sections will go into more details on many of the important components of a certificate.

How does a device authenticate itself with a digital certificate? Typically, the device that needs to authenticate hashes a conversation with the peer that wants to authenticate it. The device then encrypts that hash with its private key. The peer decrypts the hash with the public key in the certificate and validates that the result matches its own hash of the conversation. This proves that the

original device truly owns the certificate—and is the identity within the certificate.

Public/Private (asymmetric) encryption algorithms for digital certificates

The public/private keypair within the certificate uses asymmetric encryption. Most certificate keypairs use one of two algorithms, shown in Figure 2-2: Rivest Shamir Adleman (RSA) and Elliptic Curve Digital Signature Algorithm (EC-DSA).

Figure 2-2: Public/Private (asymmetric) encryption algorithms for digital certificates

RSA was the original asymmetric encryption algorithm. It involves the use of large prime numbers and an operation called modulus. RSA remains secure, but requires long keys to provide adequate security. NIST recommends RSA keys of at least 3072 bits to resist brute force attacks.

A more modern asymmetric encryption algorithm, ECDSA involves calculating positions across an elliptic curve (EC). The EC approach has the advantage of providing relatively higher security with much shorter keys. Shorter keys lead to faster encryption and decryption and better performance. (However, devices rarely use asymmetric encryption to encrypt large amounts of data in transit.) A 256-bit ECDSA key provides roughly the same security as a 3072-bit RSA key. A 384-bit ECDSA key delivers the same security as a 7680-bit RSA key, which is much longer than RSA keys used in the real world.

What is the digital certificate for?

Certificates also often have extended key usages (EKUs), sometimes called enhanced key usages (EKUs). An EKU specifies a particular purpose for the certificate, building on the underlying key usages.

Of most interest to you in this study guide are the client authentication and server authentication EKUs. These EKUs permit the certificate owner to use the certificate to prove its identity. Most authentication frameworks define a client and server. The client needs a certificate with the

client authentication EKU while the server needs a certificate with the server authentication EKU.

Figure 2-3: What is the digital certificate for?

These EKUs rely on the digitalSignature key usage. The certificate owner submits the certificate to prove its identity. But, because anyone can intercept a certificate and try to claim it as their own,

the owner further offers proof that it truly owns the certificate. As shown in Figure 2-3, the certificate owner signs some data, such as a hash of the preceding conversation, with the private key. The authenticating device can then use the certificate’s public key to validate the signature.

In common usage, people often simply say that a device submits its certificate to authenticate. Keep in mind, though, submitting the certificate also includes signing data and proving certificate ownership.

Validating that a certificate is trusted

You now have a sense of how users and devices can use their certificates.

First, the certificate has to have a valid usage, as shown in Figure 2-4. In other words, if the certificate owner is using the certificate to authenticate as a client, the certificate must have the clientAuth EKU specified within it.

Figure 2-4: Validating that a certificate is trusted

The certificate must also be within its validity period. In addition, the certificate must be issued by a trusted source, must not be revoked by that source, and must have an identifier that checks out with the party with which the receiver believes itself to be communicating.

Trusted issuer

Every certificate has an “issuer,” which is the entity that vouches for the identity specified in the certificate. It also has a signature, which proves that the issuer truly issued the certificate.

The issuer forms a crucial component of the certificate’s trustworthiness. Anyone can create a certificate with any identity that they want. However, other devices only “trust” certificates that are issued by authorities that they trust.

PKI

Certificates exist within a public key infrastructure (PKI) hierarchy, as shown in Figure 2-5, which enables devices to determine which certificates they should trust.

Figure 2-5: Trusted issuer: PKI

Root Certification Authorities (CAs) are at the top of the hierarchy. A root CA signs its own certificates, called root CA certificates. Root CAs are well-known entities that are widely believed to be trustworthy. For example, DigiCert and Comodo are well-known CAs. A company can also set up its own internal or private root CA, which is believed to be trustworthy within the company.

As the ultimate source of trust, root CAs must be rigorously secured. The root CA issues just a few certificates itself, issuing and signing certificates for intermediate CAs. This ensures minimal contact between the root CA and other entities. In fact, the root CA is typically kept offline for security purposes.

The intermediate CAs, sometimes also called subordinate or signing CAs, are responsible for issuing and signing certificates for end entities such as Web servers, network infrastructure devices, and users. The end entity certificates are sometimes called server certificates, user certificates, or client certificates, depending on the type of entity to which they are assigned. They are also sometimes called “leaf” certificates because they are at the other side of the PKI “tree” from the root.

A PKI could also have multiple tiers of intermediate CAs.

Chain of trust

When a device attempts to validate a certificate, it follows a chain of trust through the PKI until it reaches the root CA.

An example of how a client can use a chain of trust to validate a Web server’s certificate is shown in Figure 2-6. The chain of trust has two links: intermediate CA and root CA.

Figure 2-6: Trusted issuer: Chain of trust

The server sends its own certificate and the certificate for the intermediate CA that signed that certificate. The server does not send the root CA certificate above the intermediate CA, though.

The client receives these certificates and validates that it can link the Web server’s certificate back to a root CA that it trusts. First, the client looks for the issuer of the server’s certificate—in this case, the Intermediate CA. Then the client looks in the Intermediate CA’s certificate for the public key, and it uses that key to check the signature in the server’s certificate.

The client continues to follow the chain of trust by checking the issuer of the Intermediate CA certificate. In a three-tier PKI, this is the root CA certificate.

As mentioned earlier, the Web server does not send this certificate. Instead the root CA certificate must be pre-installed as a trusted root CA on the client. The client can then use the public key in that pre-installed certificate to check the Intermediate CA certificate’s signature. Assuming that the signature checks out, the client has completed the chain of trust and can validate the server’s certificate as legitimate.

It is important for the client to have the root CA certificate pre-installed, rather than the Web server send that certificate. This is because users should not be prompted to trust root CA certificates on the fly; they will often make insecure choices. Instead security experts should install the root CA certificates in advance. OS typically come with trusted root CA stores populated with well-known trusted root CA certificates.

Types of CAs

You now understand how certificates exist and are validated within a PKI. Next you will consider how devices obtain their certificates. As shown in Figure 2-7, you can have your users and devices obtain certificates from public CAs, your organization’s own private CA, or both. Hybrid options are now available as well.

Figure 2-7: Trusted issuer: Types of CAs

Public CAs are recognized and trusted by virtually all devices. Windows, Apple, Android, and other vendors pre-install these CAs’ root certificates in their devices’ operating systems. Examples of prominent public CAs include Comodo, DigiCert, and GoDaddy, but many other public CAs exist. You typically install CA-signed certificates on public-facing services so that you know that any devices that interact with those services will trust the certificates automatically. However, you must pay a fee to a public CA to obtain the certificate, which is why organizations are selective in which services use these certificates. In addition, public CAs now only issue certificates with 13-month validity periods.

Companies can set up their own private CAs that are specific to their own organization. They often use the Windows Certification Authority (CA) because it is domain aware. However, open-source options such as OpenSSL also exist. A private CA can be a cost-effective choice for issuing certificates to many end-users and endpoints. In addition, the company can maintain more control over exactly which users and devices receive certificates, which can establish greater security for internal communications. With a private CA, the company has control over the PKI and can create the intermediate CAs that it requires. In addition, network infrastructure devices and non-public-facing services often use private IP addresses and fully qualified domain names (FQDNs). A public CA cannot issue

certificates with a private IP address in the subject name or subject alternative name (SAN), based on RFC 1918. Similarly, public CAs do not issue certificates with subject names or SANs that specify private domain names, such as mydevice.example.local. Therefore, a company must use a private CA to obtain certificates for devices and services with private IP addresses or FQDNs. Companies might also use a private CA to issue certificates with longer validity periods.

A company that does not want to manage its own PKI could also obtain a managed private CA; for example, Globalsign offers such an option. In this way, the company can obtain the benefits of a private CA without needing the expertise to establish a CA in-house. Some public CAs such as DigiCert also offer a dedicated intermediate CA option. The public CA creates an intermediate CA, which it dedicates to the organization and operates for it. The organization can then obtain all the certificates that it needs from that intermediate CA. Because the certificates are ultimately backed by the public CA, they will be trusted by nearly all devices inside and outside the organization.

Not expired: Ways to avoid issues

Every certificate has a start date and end date, and the receiver will only trust the certificate if the current date falls between those two dates. This requirement is fairly straight-forward, but it creates some considerations. First you need to ensure that all of the devices in the network, from clients to servers to network infrastructure devices, agree on the time. Otherwise, one device might reject another’s certificate. As shown in Figure 2-8, setting up Network Time Protocol (NTP) is the best way to meet this requirement on your network infrastructure devices.

Figure 2-8: Not expired: Ways to avoid issues

Second, you need to be aware of when each certificate that you have installed will expire so that you can obtain and install a new certificate before that occurs. While updating one certificate is fairly simple, updating many certificates can be time-consuming and complex. And if admins miss even one certificate and fail to update it, the functions based on that certificate fail too. For this reason, companies often seek to automate this process. You will look at a few options for automation throughout this study guide.

Not Revoked

Why revocation is important

An important part of maintaining a trusted PKI is revoking certificates that are no longer valid.

Say, for example, that a user has installed a certificate on a laptop. Then the user loses the laptop, or someone steals the laptop. Hopefully the certificate was installed with a measure of security, including a password to protect the private key. However, you cannot rely on that security alone. The certificate on the laptop is now compromised, and the CA that issued it should revoke it.

Companies might also retire devices before the certificates on those devices expire. It is best practice to revoke the retired device’s certificates so that they can no longer be used.

Devices typically renew their certificates before they expire. The old certificate should be revoked so that a single valid certificate remains in use.

A certificate owner might also fail to properly secure the private key. If certificate owners have reason to believe that their private keys have been compromised, they can ask the CA to revoke any certificates using those keys.

Occasionally a hacker might manage to obtain a certificate for an identity that the hacker does not own. If the CA later discovers this issue, the CA can revoke the certificate.

Certificate Revocation Lists (CRLs)

The CA then needs to inform other devices about the revoked certificates.

Certificate Revocation Lists (CRLs) offer one method for doing so. CAs (typically intermediate CAs) can publish a CRL, which lists any certificates that it has revoked by serial number, as shown in Figure 2-9. Devices with access to the CRL then know that they should not trust those certificates, even though the CA signature and chain of trust checks out. The CRL is signed by the intermediate CA that issues it to prevent tampering.

Figure 2-9: Not Revoked: Certificate Revocation Lists (CRLs)

Admins can install CRLs on devices manually. However, it is most useful for devices to be able to obtain the latest CRL dynamically to prevent the CRL from becoming out of date.

The CA publishes its CRL at a CRL Distribution Point (CDP), which is a location on an LDAP server or Web server. Intermediate CAs often include the CDP within their certificates, so a device that trusts an intermediate CA can find the location where that CA publishes its CRL. CRLs have

a validity period, and the CA periodically updates and republishes the CRL at the CDP, typically on a weekly basis.

When a device needs to validate a certificate signed by a CA, it also checks whether it has a currently valid CRL associated with that CA in its cache. If it does not, it contacts the CDP and downloads a new CRL. It then looks for the certificate’s serial number in that list. If it finds a match, the device rejects the certificate. Otherwise, the certificate passes the “not revoked” check.

CRLs do have some drawbacks. If the validity period is too long, a device might miss an update to the CRL and trust a certificate that has been revoked. In addition, a device has to download and check the entire CRL to find out whether a particular certificate has been revoked. Because CRLs can become long, this process can cause latency.

Online Certificate Status Protocol (OCSP)

Online Certificate Status Protocol (OCSP) is designed to address the shortcomings of CRLs. OCSP enables a device to check on-demand the revocation status of just the certificate in which it is

currently interested.

OCSP uses a client-server framework, and it uses HTTPS for the transport. When a client needs to validate a certificate, it sends a query that contains the certificate’s serial number to an OCSP server, or OCSP responder, as shown in Figure 2-10. The OCSP responder is maintained by the CA. When it receives a query, it checks the certificate’s status in the CA database, which is stored securely. The OCSP responder then sends a signed reply, indicating whether the certificate is still valid or not. Another advantage of OCSP versus CRL is that OCSP provides positive validation that the certificate is valid. A CRL, on the other hand, only gives negative information; it shows whether a CA has actually revoked the certificate or not, but the CA does not attest as to whether that specific certificate is valid.

Figure 2-10: Not Revoked: Online Certificate Status Protocol (OCSP)

To use OCSP to check a certificate’s status, the client or application running the check must support OCSP, of course. (Many browsers support OCSP, for example.) The CA that issued the certificate in question must also support OCSP. Much as with CRLs, the intermediate CA certificate can advertise the URL for the OCSP responder. The “Authority Information Access” field includes this URL in a name or alternative name under the OCSP access method.

Matched identifier

Making the match

As part of validating the certificate, the validator also checks the subject name.

Figure 2-11: Matched identifier: Making the match

In the example shown in Figure 2-11, the client makes an HTTPS request to www.example.com. The server responds with its certificate as part of setting up the HTTPS session. The client validates that the subject name in the certificate matches the hostname with which the client believes it is communicating. If the certificate includes a different subject name from the one expected, this could indicate a man-in-the-middle (MitM) attack in which a hacker is attempting to insert itself and its own certificate in between the client and legitimate server.

Sometimes certificates are exchanged as part of a Layer 2 process such as 802.1X. In this case, the device validating the certificate cannot specifically match the subject name to the owner’s FQDN or IP address. But it can check it against a list of trusted names; you will learn more about this process later.

Subject names and subject alternative names (SANs)

Now look at that subject name in more detail, as shown in Figure 2-12. It uses ASN.1 format. The subject name always includes a common name (CN), but might or might not include additional components in the ASN.1 hierarchy. As for what the common name specifies, X.509 makes no requirements. It could be a user name, an FQDN, an IP address, an email address, or any string.

Figure 2-12: Matched identifier: Subject names and subject alternative names (SANs)

Subject alternative names (SANs) offer a more precise way for identifying the certificate owner. The SAN specifies a particular type, such as “DNS” for an FQDN or “IP” for an IP address. SANs also make it possible for a certificate to include multiple identities. For example, a single certificate could include two DNS SANs and be used by servers with different hostnames. A certificate could also have SANs of various types such as DNS and email.

Even though SANs are technically optional, some applications will only validate a certificate if it has a valid SAN. For example, Chrome and Mozilla require Web servers to present certificates with valid DNS-type SANs.

Wildcards

A subject name or DNS SAN can also include a wildcard. The wildcard is an asterisk, which matches any value for one level of an FQDN. For example, *.example.com matches www.example.com, mail.example.com, and server.example.com, as shown in Figure 2-13. However, it does not match my.server.example.com.

Many companies like to use wildcards in certificates because they enable the company to reuse the same certificate for multiple web servers and URLs, which can be easier for the company to manage. Wildcard certificates might be cost-effective for the company, as they can install the same certificate on multiple servers. However, public CAs also charge more for wildcard certificates, off-setting these advantages.

Figure 2-13: Matched identifier: Wildcards

Certificates that use wildcards can also be less secure. Distributing the same certificate and associated private key across multiple servers inherently increases the vulnerability surface for that certificate and key. If one server is compromised, the security for communications on all servers is compromised. Some security audits will flag wildcard certificates. And some clients do not trust wildcard certificates for some purposes such as for a RADIUS/EAP server authenticating itself.

Ways to create certificate signing requests (CSRs)

Now that you have reviewed how certificates are used and validated, review how you can obtain a certificate for a device. You need to generate a certificate signing request (CSR) and a public/private keypair. You must also get the CSR signed by a valid CA for your purposes.

You often have two choices for how you can create the public/private keypair and CSR, as shown in Figure 2-14: online, on the device that will own the certificate, or offline using another application such as OpenSSL.

Figure 2-14: Ways to create certificate signing requests (CSRs)

When you create the keypair and CSR online, the private key remains on the device—perhaps permanently depending on the device. This can be good for security, but might interfere with certain applications. For example, the company might want to back up the private key so that admins can install the same certificate on new hardware if the original device fails. Or the company might want to deploy the same certificate across multiple devices in a cluster, which requires installing the private key on all of the devices so that the devices can use the certificate.

When you create the CSR offline, though, remember that you are creating the private key offline too, which makes it more likely to be compromised. You must take appropriate measures to secure the private key. This could mean encrypting the private key, storing it in a physically secure location, or both.

Using OpenSSL to generate offline CSRs

You will now look at using OpenSSL to generate offline CSRs, as shown in Figure 2-15.

OpenSSL is an open-source toolkit for generating certificates and the associated keys. OpenSSL has distributions for Windows, Linux, and macOS. With it you can perform tasks such as generating public/private key pairs, generating CSRs, and exporting certificates in a new file. You can even set up your own CA with OpenSSL and use it to sign certificates and create CRLs.

Figure 2-15: Using OpenSSL to generate offline CSRs

This study guide will focus on just a few common tasks that you can complete with OpenSSL.

The openssl req -new command generates a CSR. Indicate the file to which you want to save the CSR with this option: -out .

A CSR requires a public/private keypair associated with it.

You can reference an existing key in PEM format by adding this option to the command: -keyin .

You can alternatively create a new keypair along with the CSR by adding this option: -newkey rsa:bits –keyout . When you use RSA for the algorithm, you specify bits after the colon. (You can also specify another algorithm such as ec for elliptic curve, but in that case you must specify an algorithm parameter file in advance to define the parameters. See Openssl documentation for more information.)

The key and CSR are both saved in PEM format, which is sometimes called base64.

Figure 2-16: Using OpenSSL to generate offline CSRs: Setting passphrase and subject name

When you run this command, you will be prompted to set a passphrase, which encrypts the private key. Now no one can read or use the private key file without first entering this passphrase.

You will also be prompted to enter fields for creating the ASN.1 subject name, as shown in Figure 2-16. Using the CN is the most important part of this name.

Using OpenSSL to create a CSR with additional options

The basic openssl req –new command gives you prompts for inputting the ASN.1 DN, and it generates the CSR based on some default settings in the openssl.conf file. However, you often want to customize the CSR settings. For example, you might want to include one or more SANs or EKUs.

Figure 2-17: Using OpenSSL to create a CSR with additional options

To add these custom settings, edit the openssl.conf file, as shown in Figure 2-17. Create a section with a name within brackets such as [myDevice]. Under that heading you can add your desired options. Add a SAN with this format:

subjectAltName = Type : value. For example: subjectAltName = DNS:clearpass.example.com.

To specify extended key usages, use this format: extendedKeyUsage = usage1, usage2.

For example: extendedKeyUsage = serverAuth

After you have created the section, save and close the openssl.conf file. You can then reference the section and config file when you run the openssl req -new command with these options: -reqexts -config openssl.conf.

The example command also illustrates that you can reference an existing key file when you generate the CSR. This option is useful when you want to create a new certificate for a device, but using an existing public/private keypair, which other hosts already trust.

If you need to specify multiple SANs of the same type, you can use this format: subjectAltName = Type.# : value, Type.# : value.

For example: subjectAltName = DNS.1:cppm1.example.com,DNS.2:cppm2.example.com

Some ways to submit CSRs

If you need to get your CSR signed by a public CA, you will need to review that specific CA’s procedures for submitting CSRs. The CA will tell you the correct format for the request. OpenSSL outputs CSRs in base 64 PEM, by default, but you can also use OpenSSL to convert CSRs to another format if necessary. Keep in mind that some CAs do not accept SANs within CSRs for security purposes. Instead you must submit the SANs in another form along with the CSR. The CA then vets the SANs and adds them to the certificate during the signing procedure. Also keep in mind that public CAs might charge different prices for certificates with various numbers of SANs, as well as for wildcard certificates.

Figure 2-18: Some ways to submit CSRs

There are many ways to submit CSRs to a private Windows CA. The CA might maintain a Web Enrollment server, as shown in Figure 2-18. If so, you can log into this server with your domain credentials and submit the CSR as an advanced certificate request. Open up the PEM certificate with a text editor and paste the complete text into the request window. You will also have a chance to choose the certificate template. Certificate templates control factors such as key usages, EKUs, how the subject name is generated, and validity period. The certificate templates available for you depend on your group memberships.

If you are on a domain computer, you can also use certreq commands to submit a certificate request to the domain CA. This example command submits a file named mycsr.req, requests the Web server template, and outputs the signed certificate to a file named mycert.cer:

certreq -submit -attrib “CertificateTemplate:WebServer” mycsr.req mycert.cer

Aruba ClearPass certificates

Next, you will learn how to deploy certificates on Aruba ClearPass Policy Manager (CPPM).

Types of ClearPass server certificates

When you install a certificate on ClearPass, you can choose the usage. You can also choose an existing certificate and assign additional usages to it. In this way, you can ensure that ClearPass has a certificate signed by the correct CA for each use case. ClearPass uses server certificates for four purposes, as shown in Figure 2-19. Note that if you are using a Windows CA for any of the certificates, the WebServer template is recommended.

Figure 2-19: Types of ClearPass server certificates

RADIUS/EAP

CPPM uses this certificate during the 802.1X process to authenticate itself to 802.1X supplicants (users and clients). This certificate must not use a wildcard for its CN, as some clients will reject RADIUS/EAP certificates with wildcards. The certificate should have a DNS SAN that matches the CN. The CN and SAN should not specify IP addresses to avoid exposing the IP address to users, as well as to permit the certificate to remain valid if the IP address changes. The supplicants must trust this certificate. Generally, you should obtain the certificate from a private CA. 802.1X authentication typically applies to corporate devices, which are either managed or onboarded, so the organization can ensure that the clients trust the private CA. Using a private CA gives the organization more control over the certificate. Public CAs typically only issue certificates that are valid for 13 months, but a company can issue its own certificates with longer validity periods, making them easier to maintain.

You can install multiple RADIUS/EAP certificates on CPPM and associate a specific RADIUS/EAP certificate with a specific service. This feature is useful if CPPM is authenticating users from multiple organizations, and clients in different organizations trust different CAs. You simply install certificates signed by different CAs on CPPM and then match the correct certificate with the service used by each domain.

RadSec

Because RADIUS itself does not provide rigorous security, CPPM (a RADIUS server) and network devices (RADIUS clients such as APs, gateways, or switches) can use RADIUS Secure (RadSec). RadSec carries RADIUS messages inside a secure TLS session and is useful for cases in which CPPM and the network devices are separated by an untrusted network. CPPM uses the RadSec certificate to authenticate itself to network devices that use RadSec. The network access devices (NADs) must be manually configured by admins to trust the root CA associated with this certificate.

Often a private CA works well for issuing the RadSec certificate. The company has control over its own devices and can ensure they trust the CA. However, some companies have particular requirements that call for public CA-signed certificates, and those work for RadSec as well.

HTTPS

ClearPass uses this certificate to authenticate itself to clients that access its web interfaces, including its management interface, Guest portal, and Onboard. Any clients that might need to access these interfaces must trust this certificate. If you are providing guest authentication services for users outside of the corporation, those users’ devices will not trust the corporate CA. Therefore, the HTTPS certificate should typically be signed by a well-known public CA.

This certificate should also follow other best practices for HTTPS certificates. It is allowed to have a wildcard for the CN, but you may not necessarily have one, as wildcards can be less secure. The certificate must have a SAN with a DNS name that matches the CN; it can also have additional DNS names in the SAN. The CN and SAN should not specify IP addresses to avoid exposing the IP address to users, as well as to permit the certificate to remain valid if the IP address changes.

Database

ClearPass uses the database certificate to authenticate to clients that access its Insight Database. When you deploy a cluster, the database certificates of cluster members must have a DNS type SAN, but with the server’s IP address as the value. Because public CAs might not issue a certificate that meets these criteria, you will often obtain the database certificate from a private CA.

Installing certificates on CPPM

You have two choices for installing certificates on CPPM, as shown in Figure 2-20. You can create the private key and CSR online using the Web UI. You can then copy the Base-64 CSR into a file and submit that file to the proper CA for signing. When you receive the signed certificate, you upload that certificate on CPPM.

Or you can create the private key and CSR offline using a tool like OpenSSL. Some admins prefer this method so that they can script the generation of many CSRs. You then submit the CSR to the proper CA for signing. When you receive the signed certificate, you combine it with the private key into a PKCS12 file using a tool like OpenSSL. You can then upload the PKCS12 file on CPPM. Or you can even upload the private key and signed certificate as separate files.

Figure 2-20: Installing certificates on CPPM

Note that you can export both the certificate and the associated private key, whether you created the CSR online on CPPM or offline. You simply need to specify a password to encrypt that key when you export the certificate. This capability makes it more feasible for you to use the online CSR capabilities. You can still export the certificate and private key and archive them or install them on another server in a cluster.

Types of trusted CAs on ClearPass

CPPM sometimes needs to validate certificates submitted to it. Just like any other device, CPPM uses root CA certificates for this purpose. You can add CA certificates to CPPM’s trusted list for several usages. Note that CPPM also supports several other types of CA certificates not listed in Figure 2-21, which are less relevant for this study guide.

You can upload multiple trusted CA certificates. Each certificate can have one or more usages. You set the usage when you upload the certificate, and you can also add usages at a later point.

Figure 2-21: Types of trusted CAs on ClearPass

Multiple trusted CAs can also be permitted for the same usage. For example, different endpoint context servers might have certificates issued by different CAs, and ClearPass can have multiple trusted CA certificates with the Endpoint context server usage.

AD/LDAP

CPPM can integrate with AD or another LDAP server to authenticate clients. CPPM and the AD/LDAP server can secure their communications with a protocol such as Start TLS or LDAP over SSL. In this case, AD or the LDAP server authenticates itself to CPPM with a certificate. CPPM verifies that certificate using the root CA certificate that you assign the AD/LDAP usage.

Database

This is the root CA certificate for the CA that issues the ClearPass server’s Database certificate. If acting in a cluster, a server also uses CA certificates with the database usage to validate database certificates on other members of the cluster.

EAP

CPPM uses the certificate with the EAP usage type to validate certificates submitted by supplicants during an 802.1X EAP authentication process. CPPM must also have an EAP-type root CA certificate for the CA that signs CPPM’s own RADIUS/EAP certificate. (In practice, CPPM and supplicants might have the same root CA for certificates that they use during RADIUS/EAP.)

Endpoint Context Servers

CPPM can integrate with endpoint context servers, such as a Palo Alto firewall or mobile device management (MDM), to exchange contextual information with those servers. To secure these communications, the servers can authenticate to CPPM with certificates. CPPM uses this type of CA certificate to validate these servers’ certificates.

RadSec

RadSec also requires NADs to submit certificates to authenticate themselves. CPPM uses the RadSec-type CA certificate to validate those certificates. CPPM must also have a RadSec-type root CA certificate for the CA that signs CPPM’s own RadSec certificate.

Other

You should upload the root CA certificate for the CA that signs CPPM’s HTTPS certificate and assign it the Other usage.

Starting with Policy Manager 6.9.1, the Comodo RSA Certification Authority root CA is included by default in the certificate trust list. This CA is enabled by default and is used by ClearPass Device Insight integrations to connect to Aruba Central. Policy Manager 6.9.2 also introduces a new SHA-2 root certificate authority CA USERTrust RSA Certification Authority. This certificate is disabled by default.

The trust list might also include Department of Defense (DoD) certificates: A DoD certificate allows a browser to trust web sites whose secure communications are authenticated by a DoD agency. These certificates are disabled by default. It might also include an Alcatel root certificate, which allows Alcatel Lucent IP phones to authenticate using EAP-TLS. These certificates are disabled by default.

Certificate requirements for forming a ClearPass cluster

Many enterprises choose to deploy ClearPass clusters to provide better redundancy and scale out services. A ClearPass cluster consists of a Publisher and multiple Subscribers; one Subscriber can also act as a standby Publisher. The Publisher acts as the central point for configuration and maintains a central database to which Subscribers synchronize. In a production cluster, the Publisher is typically dedicated to managing and controlling the cluster while Subscribers respond to service requests and apply policies.

Figure 2-22: Certificate requirements for forming a ClearPass cluster

Every ClearPass server starts as a Publisher. To join the future Subscribers to the cluster, you convert them to Subscribers and point them to the Publisher, as shown in Figure 2-22.

There are many considerations for cluster design, but this study guide focuses on the certificate requirements. To join the cluster, Subscribers must trust the HTTPS certificate on the Publisher. The best way to meet this requirement is to obtain a certificate signed by a well-known public CA on the Publisher. Then check that the Subscribers trust the complete chain for that certificate, including the root CA and one or more intermediate CAs. The certificates might be pre-installed in the server trust list if they are well-known. In this case, enable the certificates and set the Others usage. If the certificates are not already present, add them to the trust list and set the Others usage.

The Publisher must also have a database certificate that has its own IP address listed as the DNS SAN. Similarly, each Subscriber must have its own database certificate with its own IP address listed as the DNS SAN. Typically, you obtain these certificates from a private CA. On each server, add the private CA root certificate and any intermediate certificates to the trust list with the Database usage. Obtain a certificate signed by a CA that meets the requirements shown in Figure 2-22 and install that as the server’s Database certificate.

The certificates are then ready, and you can convert each server to a Subscriber and connect it to the Publisher.

Note that these are the requirements for ClearPass 6.9. In 6.10, admins receive a prompt to trust the Publisher certificate when they add the Subscriber.

Other certificate considerations for ClearPass clusters

Each member of a ClearPass cluster continues to have its own certificates installed on it. However, you can choose to install the same certificate for the same function across multiple members, as shown in Figure 2-23. In that case, the certificate’s subject name or SAN must be valid for all of the members using it. For example, if you install the same HTTPS certificate on multiple members of a cluster, the certificate needs a SAN for the hostname of each member. Or it could have a wildcard name.

Figure 2-23: Other certificate considerations for ClearPass clusters

Alternatively, clusters can use virtual IP groups, in which one member takes responsibility for the virtual IP address while the standby member takes over the virtual IP address if the first member fails. It is generally best practice to use virtual IP addresses to simplify failover when the company has not deployed a load balancer for the CPPM cluster. If you are using the virtual IP approach, the members can effectively share the hostname to which the virtual IP address resolves. You must define that hostname as a DNS SAN in the certificate. You might also assign the devices’ individual hostnames as extra SANs in case admins want to sometimes contact the ClearPass servers on their individual IP addresses.

Clients only check the name in the RADIUS/EAP certificate, so multiple members can share it without an issue, whether or not the members are using a virtual IP.

Aruba infrastructure certificates

Finally, you will learn how to deploy certificates on Aruba network infrastructure devices.

Aruba network infrastructure certificate options

Like ClearPass, Aruba infrastructure devices can use certificates for many usages, depending on the device type and its role in the architecture.

Self-signed certificates

The Aruba devices come with self-signed certificates, which let admins obtain initial access to the web UI using HTTPS. As shown in Figure 2-24, self-signed certificates are not considered secure, and should not be used in production.

Figure 2-24: Aruba network infrastructure certificate options: Self-signed certificates

Device (TPM) certificates

Current models of Aruba APs, mobility controllers (MCs), gateways, and Aruba CX switches also come with factory-installed device certificates, as shown in Figure 2-25. This certificate is issued by an Aruba or HPE CA, and it is installed at the factory in a tamper-proof hardware Trusted Platform Module (TPM), making its private key highly secure. Admins find the certificates convenient to use as they are pre-installed and have a long validity period, eliminating the need for renewals. Because the certificate is issued by a secure Aruba or HPE CA, rather than self-signed, it can be used in production.

Figure 2-25: Aruba network infrastructure certificate options: Device (TPM) certificates

Device certificates are trusted by many Aruba products, so they can be useful for setting up secure communications between Aruba devices. In an ArubaOS 8 architecture, APs can discover MCs and set up CPsec tunnels (as long as the MC is configured to auto-accept them or has an allow list). In an Edge Services Platform (ESP) architecture based on Aruba Central, devices can establish secure connectivity with Central. Central typically learns the serial numbers, included in the device certificates, from Activate.

You do not need to set anything up to let Aruba devices use these certificates in these ways; they do so out of the box.

As you will learn later, you can also set up Aruba APs to use their TPM certificates when they act as 802.1X supplicants.

CA-signed certificates

You can also obtain a CA-signed certificate and install it in your devices when the devices need to establish trusted communications with non-Aruba devices.

Figure 2-26: Aruba network infrastructure certificate options: CA-signed certificates

The Web UI is one example of this use case. While admins might be used to skipping most certificate errors to reach devices’ web interfaces, it is more secure to install a trusted certificate on devices. Doing so minimizes the chances of a MitM attack, in which hackers insert their own devices between an admin and the managed device. You can use a private CA to issue these certificates to lower costs. However, if you are managing devices through Central, this step might be less important to you.

As shown in Figure 2-26, the Aruba device also requires a public CA-signed certificate if it forms part of a captive portal solution, even if the captive portal is hosted on an external server such as ClearPass Guest. The Aruba device redirects HTTPS traffic, and it needs a certificate that clients trust to do so successfully. Note that Central comes with a public CA-signed certificate, which it can push to devices that it manages, eliminating the need for you to acquire a certificate for this purpose.

Aruba recommends using ClearPass to provide RADIUS server and captive portal capabilities in most cases. However, sometimes a company will want to host these services on their Aruba mobility devices. In this case, the device should use a CA-signed certificate for these functions. The RADIUS/EAP certificate can be signed by a private CA. But the devices will need public CA-signed certificates for the captive portal so that guests who access the portal do not see errors.

Note that all of these functions require ServerAuth for the EKU.

You can also use CA-signed certificates for APs’ 802.1X supplicant feature.

Installing trusted CA certificates on Aruba devices (in Central)

The process of installing a trusted CA certificate on Aruba APs and other devices managed by Central is shown in Figure 2-27.

Figure 2-27: Installing trusted CA certificates on Aruba devices (in Central)

On Central you upload all certificates globally at the Organization > Certificates page. You simply add a certificate, choose the file, and set the type to CA Certificate.

Aruba APs, including ones managed by Central, do not provide an online mechanism for generating the CSR from the UI. You can use a tool like OpenSSL to generate a CSR and private key and submit the certificate to a CA for signing.

Figure 2-28: Installing trusted CA certificates on Aruba devices (in Central): Upload certificate

You should combine the certificate and its private key in the same PEM-format file, as shown in Figure 2-28. When the certificate was signed by an intermediate CA, which is typical, you should also place the intermediate CA certificate within that file.

You can then install the signed certificate on the Central from the same location where you install CA certificates. You give the certificate a name, set the type to Server Certificate, and choose the format. Set the passphrase to the phrase that encrypted the private key. Choose your file and add the certificate.

Referencing certificate usages in Central

To actually deploy the CA and server certificates on APs and other devices managed by Central, you must select usages for those certificates in the devices’ group.

An example for APs is shown in Figure 2-29. Go to the group and select Devices > Access Points and click the Config icon. You set usages in the Security > Certificate Usage settings.

Figure 2-29: Referencing certificate usages in Central

On APs, you reference a trusted CA certificate for the AP’s general CA. (The AP uses that CA certificate to validate client certificates when the AP acts as RADIUS server, for example). You can also reference a specific CA certificate for RadSec and for ClearPass (validating CPPM’s HTTPS certificate for downloading roles).

You can choose a CA-signed certificate for functions such as the Web UI, captive portal, and RadSec.

While the interface looks different for Aruba MCs, the concept is the same. You upload a certificate file and specify its type (such as Trusted CA or Server). You then set the usages for the certificate.

ArubaOS-CX trust anchor (TA) profiles

You will now learn how to manage certificates on ArubaOS-CX switches. Installing a trusted root CA serves two purposes, as shown in Figure 2-30. It enables you to install a certificate signed by that CA on the switch. It also enables the switch to trust certificates that were issued by that CA or an intermediate CA below it. For example, to implement downloadable user roles (DURs), about which you will learn more later, ArubaOS-CX switches must trust CPPM’s HTTPS certificate. So they need the root CA for CPPM’s HTTPS certificate installed in a TA profile. If you want to use RadSec, you must also ensure that the ArubaOS-CX switches have a TA profile for the root CA for CPPM’s RadSec certificate.

Figure 2-30: ArubaOS-CX trust anchor (TA) profiles

You need one TA profile for each CA that you want the switch to trust. Aruba switches come with several pre-installed TA profiles, and you can add your own for the CAs that your company uses.

Copying the root CA certificate into the TA profile activates the profile. You can issue a command and copy a Base64 formatted certificate directly into the CLI, or you can use SFTP.

Enabling OCSP on an ArubaOS-CX TA profile

As you learned, OCSP enables a device to dynamically check whether a certificate is still valid or has been revoked. If it supports OCSP, the CA maintains a database.

Figure 2-31: Enabling OCSP on an ArubaOS-CX TA profile

To enable OCSP on an ArubaOS-CX switch TA profile, enter this command: revocation-check ocsp.

You must also use the ocsp command and specify the OCSP responder’s URL, as shown in Figure 2-31. You can ask your CA about what URL to use. Or you can look in the intermediate CA certificate. In the certificate details, find the “Authority Info Access” field and look for URL under the OCSP access method.

You can regulate a few more settings for OCSP.

Use this command to set a secondary URL in case the primary one is inaccessible:

ocsp url secondary

Use this command to specify how strictly the switch uses OCSP to validate the certificate:

ocsp enforcement-level

The strict option means that the switch will only validate a certificate if it passes all checks; in other words, the switch must receive a valid response from the OCSP responder, indicating that the certificate is valid. The optional option means that the switch will still validate the certificate if it cannot reach the OCSP responder. However, even with the optional option, the switch will reject the certificate if the OCSP responder actually sends a response that the certificate is invalid, or if the OCSP response has an invalid signature or nonce.

The default option is strict.

Use this command to disable inclusion of a nonce:

ocsp disable-nonce

The switch includes a nonce (a random value) in the query; it then expects the responder to include the same response in replies. This mechanism helps to protect against replay attacks. However, some CAs’ OCSP responders do not support using nonces, so you would need to turn off the feature if this is the case with your CA.

Uploading a CA-signed certificate on an AOS-CX switch

Now you will look at installing CA-signed certificates on ArubaOS-CX switches. You start the configuration by creating a named certificate profile with this command: certificate , as shown in Figure 2-32.

If you have created the certificate offline, you import the file through the terminal. First make sure that the certificate file is formatted properly in PEM (Base64) format. The file needs to include the certificate, the intermediate certificate that signed it, and the encrypted key. Copy the full contents.

Figure 2-32: Uploading a CA-signed certificate on an AOS-CX switch

Enter this command in the switch certificate profile context: import terminal ta-profile password . The key password is the password used to encrypt the private key file. Paste the contents of the PEM file into the command line. Press [Ctrl+D] to accept the certificate.

You can alternatively create a CSR directly on the AOS-CX switch and submit that to the CA. Refer to the switch documentation if you want to use that option.

Some Aruba methods to scale certificate installations

You can easily use the processes about which you just learned to install a certificate on one network infrastructure device. However, many customers need to install certificates across many devices. And they need to repeat that process to install new certificates before the old ones expire. Aruba offers several ways to simplify the deployment of certificates at scale.

Central

If you are using Central to manage your devices, you upload any certificates that you want to use in the global settings, as shown in Figure 2-33. If you use features like wildcards, you can upload the same certificate for multiple devices. You can then specify how you want to use each certificate in the device configuration settings at group level or individual device level.

Figure 2-33: Some Aruba methods to scale certificate installations: Central

NetEdit

NetEdit provides centralized management for AOS-CX switches, as shown in Figure 2-34. You can easily discover the AOS-CX switches within NetEdit. You can then create CLI-based configuration templates and apply them to your switches. In this way, you can install certificates on multiple switches at once. NetEdit also supports features such as configuration validation and compliance checks.

Figure 2-34: Some Aruba methods to scale certificate installations: NetEdit

EST in Aruba products: Auto-enrollment and renewal

You can also use Enrollment over Secure Transport (EST) to manage certificates on Aruba devices more automatically. Aruba devices that support ESP include:

Aruba gateways and MCs

Aruba APs (for Instant APs, in Instant 8.7 and later)

AOS-CX switches (AOS-CX 10.06 and later)

Figure 2-35: EST in Aruba products: Auto-enrollment and renewal

The device is the EST client. It creates an HTTPS session with an EST server, as shown in Figure 2-35, authenticating the EST server by its HTTPS certificate. The EST server also authenticates the client (it might not require authentication for all functions, but does for enrolling for certificates). If the device passes authentication, the EST server helps it to enroll or re-enroll for certificates with a CA. The EST client appends specific paths to the EST URL to make requests. For example, it uses /cacerts to download the CA chain for the PKI in which it is enrolling. It uses /simpleenroll to enroll for a certificate. In this message, the client sends its CSR, as well as proof that it owns the private key associated with the CSR public key. The EST server passes the CSR to the issuing CA and also passes the signed certificate back to the client.

When the client needs to renew its certificate, it follows much the same process, but uses the /simplereenroll process.

All of these functions occur transparently after you have configured the network infrastructure device with the proper EST profile for contacting an EST server.

This option is preferred for wider scalability because it simplifies the deployment of certificates. Automatic re-enrollment before a certificate expires also decreases the risks that admins will forget to renew a device’s certificate, which would cause functions that use that certificate to fail. Using EST does require the deployment of an EST server, which can communicate with the issuing CA.

ClearPass Onboard can act as the EST server for the company’s private CA.

Tips for using Onboard EST

If the company wants to use EST to automate the deployment of private CA-signed certificates, you can set up Aruba Onboard as the EST server.

First you create the CA on Onboard. As you will learn in more detail later in this study guide, Onboard can act as a root CA or an intermediate CA. You should choose the root CA option if you want Onboard to act as an EST server for certificates that it issues itself. These certificates will only be valid for use within the ClearPass cluster. You should choose the intermediate CA option if you want Onboard to act as an EST server for a PKI that the company has already established.

Figure 2-36: Tips for using Onboard EST

After you create the CA, you can edit the settings and enable EST, as shown in Figure 2-36. The EST Auth Method can be Shared Secret or HTTP Basic or Digest Authentication. If you choose the HTTP Basic or Digest Authentication option, you must set up ClearPass guest accounts for the devices that will act as EST clients.

You can control which devices can access the EST services by adding subnets to the Allowed Access and Denied Access settings.

The EST Key Type and EST Digest Algorithm settings dictate the settings that EST clients must use in the private keys and CSRs that they generate. Make sure to select SHA-384 for the EST Digest Algorithm because Aruba APs do not support longer SHA digests.

EST prerequisites on Aruba devices

All Aruba devices have similar prerequisites for using EST.

You must install the CA certificate that signed the EST server’s HTTPS certificate as a trusted CA certificate. Also ensure that the Aruba device and the EST have synchronized time by setting up NTP on the device. Typically, you need to specify the EST server by FQDN because the name that you specify must match the subject name and DNS SAN within the EST server’s HTTPS certificate. Therefore, you must specify a DNS server on the device so that the device can resolve the FQDN.

Figure 2-37: EST prerequisites on Aruba devices

If a firewall lies between the Aruba device and the EST server, make sure that it permits communications on the correct port, as shown in Figure 2-37. Typically, the communications use TCP port 443, but check with the EST server admins to make sure.

EST profile configuration on Aruba devices

You can then configure the EST profile.

Figure 2-38: EST profile configuration on Aruba devices

AOS devices

You must specify the server-host, which is the FQDN at which the device reaches the EST server. Note that the device automatically appends this standard path after the specified FQDN: /.wellknown/est. You must also specify the server-port, at which the device reaches the EST server.

The arbitrary-label helps the EST server select the correct CA and settings for this device. The device appends the arbitrary-label at the end of the URL. For example, this device will contact the following URL: clearpassxxb.training.example.com/.wellknown/est/ca:3.

You must also specify the credentials that the device uses to log in. If the EST server uses HTTP basic or digest authentication, you must specify a username and password. If the EST server uses a shared secret, you must specify a challenge password. You must also tie the EST profile to the trusted root CA certificate for the EST server’s HTTPS certificate.

You can then activate the EST profile. The AOS device then contacts the EST server, downloads the root CA certificate, and enrolls for its own certificate signed by a CA within that PKI.

Note that MCs support Web UI configuration for the EST profile. Follow the same guidelines for determining the correct settings.

AOS-CX switches

The EST profile settings on AOS-CX switches are similar to those on AOS devices. Note, however, that you specify the EST server by URL. You must include the "https://" and "/.wellknown/est" portions of the URL in the command, as well as the port. Note that, even though the display does not fit on one line in the example shown in Figure 2-38, this is one command: url https://clearpassxxb.example.com:443/.wellknown/est.

AOS-CX switches only support HTTP basic or digest authentication, not shared secrets. You specify the username and password in one command: username password plaintext .

You can also use the reenrollment-lead-time command within the EST profile to configure how long before the certificate expires the switch attempts to reenroll.

To activate the EST profile, you create a certificate profile on the switch with this command: crypto pki certificate . Set the key algorithm and key size (or curve size for ECDSA), making sure to specify settings that match with the EST server requirements. Also set the subject name for the CSR. The example shown in Figure 2-38 is just a common name for the subject name, but you can add additional fields. You can then activate the enrollment; enter this command: enroll est-profile .

CA-signed certificates for RadSec

If you want to implement RadSec between Aruba devices and CPPM, you need to use a CA-signed certificate.

You must obtain certificates from your choice of CA. To minimize costs, you should usually use a private CA to issue these certificates. This option also lets you choose longer validity periods or wildcards for CNs or SANs.

You then install the certificates on the Aruba devices, such as APs or switches, and select the RadSec usage for the certificates. If you have IAPs, you can install a single certificate for the entire cluster. If you are using Central, you might use the same certificate across a group of APs or other devices.

Figure 2-39: CA-signed certificates for RadSec

On CPPM, you must complete two steps to ensure that CPPM trusts the certificate. You must add the CA that signed the devices’ certificates to CPPM’s trust list with the RadSec usage. You must also create one or more network device entries that match your devices’ IP addresses. You then use the RadSec Settings tab to specify which certificates CPPM trusts. You have three choices:

No Authorization Checks—CPPM only checks that the certificate is signed by a trusted CA, not expired, and not revoked. Aruba generally recommends against using this option as it is less secure.

Validate With CN or SAN—You must specify the common name or SAN within the certificate or certificates on your devices. You can use regular expressions to match multiple subject names or SANs. In the example shown in Figure 2-39, .*.aps.example.com matches any CN that ends with aps.example.com. This option lets you use a single network device entry that matches the CNs or SANs for multiple valid certificates.

RFC Compliant (Serial + Issuer)—You must specify the Issuer’s DN from a drop-down menu which includes the DNs for all RadSec usage trusted CAs on CPPM. You must also specify the serial number for that certificate. You can also put in a regular expression for the certificate’s CN or SAN. Some companies’ security policies require this option. When you use this option, each network device entry can match only one certificate. However, you might be able to install the same certificate on multiple devices.

Summary

Congratulations! You have completed Chapter 2. You should now be able to explain how certificates exist within a PKI. You understand how devices validate certificates and what issues might cause validations to fail. And you can use OpenSSL to create CSRs and perform other tasks.

You also know how to apply these principles and set up certificates properly on your Aruba solutions, including Aruba CPPM, Aruba APs, Aruba controllers and gateways, and ArubaOS-CX switches.

Learning checks

What is required for a client to trust a web server’s certificate? (Select two.) The client has the certificate’s public key installed on it in advance.

The certificate was issued within the previous six months.

The client can trace the certificate back to a trusted root.

The certificate DNS SAN matches the hostname accessed by the client.

What is one requirement for joining a Subscriber to a ClearPass cluster? The Subscriber trusts the entire chain for the Publisher’s RADIUS/EAP certificate.

The Subscriber trusts the entire chain for the Publisher’s HTTPS certificate.

The Subscriber has an HTTPS certificate with its IP address listed as a DNS SAN.

The Publisher has an HTTPS certificate with its IP address listed as a DNS SAN.

What correctly describes the Device Certificate on Aruba APs? It is signed by an Aruba CA and installed in a TPM.

It is a self-signed certificate, which should be replaced in production.

It uses the AP’s default IP address as its CN in the subject name.

It is signed by a CA of the company’s choice and must be installed manually.

Note: For answers to all learning checks, refer to the Appendix.

3

Implement Certificate-Based 802.1X

EXAM OBJECTIVES

✓ Deploy Authentication, Authorization, and Accounting (AAA) for WLANs with ClearPass Policy Manager (CPPM).

✓ Deploy certificate-based authentication for users and devices.

ASSUMED KNOWLEDGE

Authentication, Authorization, and Accounting (AAA) framework and basics of protocols such as RADIUS and TACACS+

Forms of Layer 2 authentication such as 802.1X, including common EAP methods such as PEAP and EAP-TLS

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

EAP-TLS in a Windows domain

Aruba recommends that companies use certificates to authenticate all users and clients, as far as is possible. In this chapter, you will review the Extensible Authentication Protocol (EAP) methods that support certificate-based authentication, as well as the benefits of certificate-based authentication.

Certificates within a Windows domain

You will begin this chapter focusing on a particular certificate use case that you will often encounter in the real world, shown in Figure 3-1. The company has a Windows domain. Employees are Domain Users. They connect to the network on desktops and laptops that are also joined to the domain.

Figure 3-1: Certificates within a Windows domain

The company has a Windows certificate authority (CA) service, which consists of a root CA and several intermediate CAs.

The company uses its CAs to issue certificates to internally-facing servers and network infrastructure devices. The company now wants to deploy certificates to domain computers and users so that they can authenticate. The next few sections take you through how this process could work.

Windows certificate stores

First it can be helpful to review how Windows operating systems store certificates. Each Windows OS has two main certificate stores, as shown in Figure 3-2.

Figure 3-2: Windows certificate stores

The Local Machine store includes certificates that belong to the computer itself, as well as CA root certificates that are trusted by the computer. The computer can always use certificates within the Local Machine store.

The Current User store includes certificates that belong to the user who is currently logged into the computer, as well as CA root certificates trusted by that user. This store only becomes available for the computer to use after the user has logged in.

Windows domain certificate auto-enrollment

When a computer is first joined to the domain, the computer always receives the Windows CA certificates and installs them as trusted.

However, it can be more complicated for computers, and the users logged in on them, to receive their own personal certificates. As you learned in the previous chapter, admins, or even more experienced users, can obtain certificates from a Windows domain in several ways. They can manually create CSRs and submit them using the certreq tools. They can also use a wizard available in the MMC certificate snap-in. Or, if the Windows CA has a Web Enrollment server, they can log into those web pages and obtain certificates in that way. However, these methods can be complex for users, and, if admins need to install all certificates, the process is not scalable.

Figure 3-3: Windows domain certificate auto-enrollment

Auto-enrollment provides the simplest and most scalable ways for computers and users to receive certificates from a Windows CA, as shown in Figure 3-3. With auto-enrollment, Windows CA admins create certificate templates that support auto-enrollment for computer and user certificates. Domain admins also create group policy objects (GPOs) to enable auto-enrollment for Domain Computers and for user groups.

With these policies in place, computers and users receive certificates automatically. Computers joining the domain or powering up check for domain computer GPOs. When the computer applies the auto-enrollment GPO, it creates a private key and CSR. It submits the CSR to the Windows signing CA, which signs the certificate and returns it to the computer. The computer then installs the signed certificate in the Local Machine store. This process completes automatically.

When a user first logs in on a computer, the user group GPO manages a similar process. The computer creates a private key and CSR for the user certificate. It submits the CSR to the signing CA. And, when it receives the signed certificate, the computer installs it in the Current User store.

Certificates in a Microsoft Azure AD domain

Some companies are now using Azure Active Directory (AD), a cloud-based version of AD. Like on-prem AD, Azure AD enables companies to manage their users and devices, organizing them into groups with different privileges. However, unlike a traditional Windows domain, Azure AD can manage mobile devices, as well as Windows PCs and servers, as shown in Figure 3-4. It does so by integrating with Microsoft Intune, a Mobility Device Management (MDM) solution.

Figure 3-4: Certificates in a Microsoft Azure AD domain

To support 802.1X with EAP-TLS in an Azure AD environment, Intune should deploy certificates to all the devices within the domain. Intune can work with a Windows CA to obtain the certificates, and it supports Simple Certificate Enrollment Protocol (SCEP) and Public Key Cryptography Standards (PKCS) for deploying the certificates.

How Windows domain computers authenticate the RADIUS/EAP server

Secure EAP methods impose mutual authentication: the 802.1X supplicant authenticates to the RADIUS/EAP server, and the RADIUS/EAP server authenticates to the supplicant.

Next you will review how a Windows 10 native 802.1X supplicant enforces this authentication.

Default settings

At default settings in Windows 10, the supplicant attempts to validate the RADIUS/EAP server’s certificate. It has a list of potential trusted root CAs for validating the RADIUS/EAP server certificate, which comes from the Current User and Local Machine trusted root CA store. As you learned earlier, this store includes many well-known public CAs. If the machine is a part of a domain, and the domain has a private CA, the store also includes the domain CA certificate.

Figure 3-5: How Windows domain computers authenticate the RADIUS/EAP server: Default settings

When the Windows supplicant using default settings tries to connect to a network that enforces 802.1X, it checks the RADIUS/EAP server certificate and prompts the user to trust the root CA that signed the RADIUS/EAP server certificate, as shown in Figure 3-5. The behavior is the same for a root CA certificate that exists in the machine’s trusted root CA stores and for a root CA certificate that does not. If the user chooses to trust the certificate, the associated root CA will then be trusted for future authentications on this network. However, if the supplicant later receives a RADIUS/EAP server certificate with a chain of trust back to a different root CA, the supplicant will again be prompted to trust that root CA.

This default behavior can introduce security vulnerabilities. You should avoid training users that it is normal to trust a new root CA in response to a prompt, and it is best practice to avoid situations in which users are ever prompted to do so. Often users do not have the information or expertise that they need to make the correct decisions. Some might call IT and report a problem when no problem truly exists. But, even worse, many will simply trust any certificate. They might end up trusting certificates submitted by hackers in a man-in-the-middle attack.

Secure settings

To close the vulnerability, the supplicants must be configured to trust specific certificates. Recommended settings, shown in Figure 3-6, are:

Leaving the check box to validate the server certificate—This ensures that the supplicants continue to validate the RADIUS/EAP server certificate.

Selecting Don’t prompt user to authorize new servers or trusted certification authorities—This prevents users from being prompted to trust new certificates and potentially trusting a hacker’s certificate.

Selecting a particular root CA—When you lock down the supplicant and prevent users from trusting new certificates, you must give the supplicant information about the certificate that should be trusted. Otherwise, it will not be able to connect at all. You can select any root CA in the trusted root CA store. This can be a private CA or public CA, based on what type of CA you have sign CPPM’s RADIUS/EAP certificate. If you are using a private CA, you need to make sure that the supplicants have this root CA in their trusted root CA store. As you learned earlier, computers that are joined to a Windows domain typically have this certificate automatically installed on them.

Adding a valid server name or names—When you select this setting, the supplicant will check the CN in the RADIUS/EAP certificate and only validate certificates that have the correct CN or SAN. Note that the supplicant cannot validate anything beyond the CN. With HTTPS, the client can further check that the CN or SAN matches with the website the client is accessing, but 802.1X operates at Layer 2, so the supplicant has no awareness of CPPM’s IP address or FQDN.

Figure 3-6: How Windows domain computers authenticate the RADIUS/EAP server: Secure settings

Therefore, the security of this setting comes in conjunction with the specification of the trusted root CA. In other words, a hacker could theoretically create a self-signed certificate or even a CA-signed certificate with the valid server CN. So the supplicant should check both that the certificate has the correct CN and comes from the correct CA. Similarly, a hacker could theoretically obtain a valid certificate from the correct CA, but not with the correct CN. By specifying both the server name and the trusted root CA, you ensure greater security than by specifying either one of the settings alone.

Configuring secure settings

You can configure the recommended settings manually. However, doing so for all devices would impose a large burden on IT staff. The best approach for automating the deployment of these settings depends on the type of device. For the domain joined devices that you have been examining in this section, domain admins can use GPOs to push the 802.1X configuration settings to devices, much as they use GPOs to auto-enroll the devices for their certificates.

High-level view of EAP-TLS for Windows domain users/computers

Now you will consider the other side of the authentication: how CPPM authenticates the Windows native 802.1X supplicant using EAP-TLS and AD as the authentication source.

Figure 3-7: High-level view of EAP-TLS for Windows domain users/computers

As shown in Figure 3-7, the Windows supplicant looks for a personal certificate that it can use for EAP-TLS authentication. If no user is logged in, it uses the computer certificate from the Local Machine store. However, as long as a user is logged in, the supplicant looks for a personal certificate in the Current User store.

When CPPM uses EAP-TLS as the authentication method, it can actually run two checks. First, it authenticates the client by validating the client’s certificate. It makes sure that it can trace the root of trust for the certificate to its EAP root CA certificate. In this example, because the domain uses a Windows CA, you should upload the Windows root CA certificate and set it to the EAP type. This step validates that the user has the identity that they are claiming.

CPPM performs the next check if the EAP-TLS method has the Authorization Required check box selected. The default [EAP-TLS] method uses this setting. CPPM checks the authentication/authorization source defined in the service, in this example an AD server, for an account that matches the certificate’s subject name. This step validates that the user is truly authorized to access the network.

CPPM also collects authorization attributes from the authentication source, as you learned in an earlier chapter. It then returns an Access-Reject or Access-Accept plus vendor specific attributes (VSAs) to the authenticator, based on the results of the enforcement policy.

Ensuring the authorization check succeeds

When a user or computer receives a certificate from a Windows CA, the CN within the certificate typically derives from the account’s userPrincipalName. This name includes the domain name. By default, when CPPM checks for an account in an AD authentication source, it checks only the sAMAccountName. The sAMAccountName does not include the domain name. Therefore, unless you take additional steps, the authorization check will fail. You can take one of two approaches to prevent such failures.

Figure 3-8: Ensuring the authorization check succeeds

Fix A: Strip the username

At the service Authentication tab, you can configure rules for stripping the user name. This rule works for most user certificates: user:@. This rule tells CPPM that it should use the characters in front of @ as the username.

The CN in computer certificates generally uses this format: host\computer_name. This rule tells CPPM to find the name after the slash: \:user.

Separate the rules with a comma (,) as shown in Figure 3-8.

Fix B: Add userPrincipalName to the Filter Query

Rather than creating stripping rules, which might not work in all scenarios, you can configure CPPM to query AD for both sAMAccountNames and userPrincipalNames. You configure this setting within the authentication source for this AD instance. Within the Configuration > Authentication > Sources page, edit the authentication source. Then go to the Attributes tab and edit the authentication attributes. Change the Filter Query to:

(|(&(objectClass=user)(sAMAccountName=%{Authentication:Username}))(&(objectClass=user)(userPrincipalName=%{Authentication:Username})))

Ensuring OCSP check works against Windows CA

When CPPM sends an OCSP request, it includes the nonce extension. In other words, CPPM includes a pseudo-randomly selected value, a nonce. The OCSP responder must include the same nonce in its response, as shown in Figure 3-9. The nonce extension helps to prevent replay attacks, in which hackers capture and replay a valid OCSP response to trick the OCSP requester into accepting a revoked certificate.

Figure 3-9: Ensuring OCSP check works against Windows CA

By default, the Windows OCSP responder for the Windows CA does not support the nonce extension. This fact can cause issues when you configure CPPM’s EAP-TLS method to use OCSP and CPPM is validating certificates signed by a Windows CA. At the default Windows settings CPPM will reject all OCSP responses, and it will consider all users’ certificates as invalid. To prevent this issue, ask the Windows CA admins to enable the nonce extension on the OCSP responder.

Alternatively, you can configure the CPPM server not to require the nonce. You configure that setting in the individual server configuration (click the server in Administration > Server Manager > Server Configuration). In the Service Parameters tab, select RADIUS server. Set Reject if OCSP response does not have Nonce to False. You might also need to configure CPPM to not send the nonce at all in those same settings.

For your reference, you enable the nonce extension as follows:

On the OCSP server, open the Online Responder Management console.

Right-click Revocation Configuration and select Edit Properties.

Click the Signing tab.

Select the Enable NONCE extension support check box.

Click OK.

Custom Attribute to collect AD Account Status

As you saw, when the EAP-TLS method enables authorization, CPPM checks that an account with the certificate subject name exists on AD. However, by default, CPPM does not distinguish between enabled and disabled accounts. For true security, you need to ensure that CPPM only authorizes a user or machine for access if its account is enabled.

Figure 3-10: Custom Attribute to collect AD Account Status

First you must ensure that CPPM collects the account status as an authorization attribute from AD. You must edit the authentication source to add it. In the CPPM UI, go to Configuration > Authentication > Sources. Find your Active Directory source and click it to edit it. Then go to the Attributes tab and edit the authentication attributes. There you can add the attribute. As shown in Figure 3-10, the correct Name is userAccountControl. For Alias Name, you can use any intuitive name such as AccountStatus. You reference the Alias Name when you create conditions. The attribute data type is String. Select the Attribute check box to indicate that this is an authorization attribute that CPPM should collect from AD.

Using the Custom Attributes in CPPM policies

AD returns the attribute value as a string. The string is a number based on flags that are enabled or disabled on the account. The strings typically most relevant to CPPM are:

For enabled machine accounts:

4096

For disabled machine accounts:

4098

For enabled user accounts:

512 (enabled)

544 (enabled, password not required)

66048 (enabled, password never expires)

262656 (enabled, smart card logon required)

262688 (enabled, smart card logon required, password not required)

328192 (enabled, smart card logon required, password never expires)

328224 (enabled, smart card logon required, password never expires, password not required)

For disabled user accounts:

514 (disabled)

546 (disabled, password not required)

66050 (disabled, password never expires)

262658 (disabled, smart card logon required)

262690 (disabled, smart card logon required, password not required)

328194 (disabled, smart card logon required, password never expires)

328226 (disabled, smart card logon required, password never expires, password not required)

You can then specify these attributes and values within role mapping policies or enforcement policies. In Figure 3-11 you see an example with two new CPPM roles:

“AD-user-enabled-cppm” for users whose accounts are enabled

“AD-machine-enabled-cppm” for computers with enabled accounts

Figure 3-11: Using the Custom Attributes in CPPM policies

The role mapping policy has rules to assign those roles. You should be careful when creating those rules to include the correct statuses based on the company’s domain and requirements. Some companies will want to permit access to any enabled user account, regardless of other flags. The role mapping rule shown in Figure 3-11 does just that by including multiple conditions separated by “OR” in the rule that assigns the “AD-user-enabled-cppm” role. You then avoid locking users out of the network if domain admins enable or disable a particular, unrelated setting on their account. Other companies only set the password to never expire for special accounts such as the accounts that solutions like CPPM use to bind to the domain. Those companies might want to deny access to users with a 66048 or 66050 account status to prevent unauthorized users from connecting with those accounts. In that case, you might create an additional CPPM role with a name like “AD-user-password-never-expires” and deny access to that role. Communicate with domain admins and the security team to formulate rules that work for your company.

You can then reference roles within the enforcement policy. In Figure 3-11 you see a very simplified example in which clients with the “AD-user-enabled-cppm” role receive full access and clients with the “AD-machine-enabled-cppm” role receive compute access. This policy does not have rules for clients with disabled accounts, so they will be denied access. However, it can still be useful to assign those roles so that you can see in Access Tracker if a user attempts to authenticate with a disabled account.

ClearPass Onboard for BYOD

If a company needs to support a Bring Your Own Device (BYOD) environment with unmanaged devices, you need to onboard these devices to install certificates and configure the proper authentication methods on them. You will learn how to use ClearPass Onboard and other Aruba solutions to support this use case.

Why ClearPass Onboard?

You have learned how to support certificate-based authentication for users on devices that are joined to a Windows domain. Those are managed devices, and it is generally easier to implement certificate-based authentication for managed devices. Admins have the tools that they need to provision the devices with the proper certificates.

However, sometimes companies want to support Bring Your Own Device (BYOD). BYOD might be a convenience for employees, who want to connect their smartphones to the corporate LAN and check their email, for example. Or the company might have a mix of employees and contractors; the contractors bring their own laptops, rather than using company-issued devices.

Supporting BYOD should not require the company to compromise on security. However, it can be a challenge to install certificates on unmanaged devices, as well as set up the devices with the proper settings to trust the RADIUS server certificate. The company might also struggle to provision BYOD clients with software that the company requires.

ClearPass Onboard helps companies overcome these challenges by making it easy for users to self-provision their BYOD devices with all the required certificates, settings, and applications. Onboard can provision Windows, Android, iOS, and MacOS clients.

Onboarding vs Guest Access

Before you begin learning about the onboard process, you need to make sure that you understand the difference between users who require onboarding and guests. In both cases, you might have users bringing smart devices and trying to get access to the network.

Figure 3-12: Onboarding vs Guest Access

However, in onboarding, the typical users are people known to the organization, like company employees or university staff and faculty members, as shown in Figure 3-12. These individuals are bringing their personal devices to use on the secure network. Guests are typically users who are unknown to the organization and who do not exist in a corporate identity store, like Active Directory. For example, guest users include guests who check in and out of hotels, customers visiting a company’s office, or visitors at a hospital. These users may bring their own personal devices.

Another difference is that in onboarding, you are trying to get employee mobile devices connected to a secure network like an 802.1X network; you want to control what devices they can use on this network. A guest network typically uses an open SSID, and anyone can connect to the network.

One to one control of clients with Onboard

Now that you understand the difference between onboarding and guest access, take a look at Onboard in more detail.

Remember that clients are really a combination of the user identity and the device connecting to the network. In a conventional network that authenticates users with usernames and passwords, the same user owns all of the clients and completes the authentication.

Figure 3-13: One to one control of clients with Onboard

Conventional network access says if the user is good, then all the user’s devices are good. What about a situation when the user loses one of their devices? If the client credentials are only the user account, then the only control you have is to block the user, but this will block all of the user’s devices. This solution is not very functional.

Onboard establishes a unique identity for each client. As shown in Figure 3-13, the client will be issued a certificate that references the user plus the hardware. If the need arises, individual certificates can be revoked, and only one device is blocked from the network. Of course, because the certificate references back to the owner’s user account, if the account gets disabled, then ClearPass will block all the devices.

Overview of a typical onboarding process

You will now look at how a typical onboarding process works. In the example shown in Figures 3-14 and 3-15, the company is using two SSIDs to manage the process. Users who need to provision their devices connect to an Onboard SSID, which uses PSK. If the company provides guest access, you might also use the same SSID for guests and for onboarding devices. Users who already have certificates on their devices connect to a secure corporate SSID.

Figure 3-14: Overview of a typical onboarding process (Connect to Onboard)

When a user needs to onboard a new device, such as a smartphone, this process occurs:

The user connects the client to the Onboard or Onboard/Guest SSID. Because this SSID is open or uses PSK, the user can connect the device without any problems. If you alternatively had users connect to an SSID that implements 802.1X with PEAP, the clients would need to trust CPPM’s certificate. That can cause issues for some smartphones.

The AP is set up to implement captive portal on the open SSID. It redirects the client’s HTTP/HTTPS traffic to the portal indicated in the captive portal settings. If the SSID is only for onboarding clients, it can redirect the clients directly to the Onboard portal. Otherwise, it can redirect clients to a generic guest portal, which has a link to the Onboarding portal.

The user logs into the Onboard Portal.

Onboard checks with CPPM to authenticate the user; CPPM has an Onboard Authentication service for this purpose.

Assuming the user and device type are authorized for access, the user enters the portal. The user follows simple instructions there, and the client is automatically provisioned for access. This process typically involves installing a certificate on the client and configuring its network settings.

At the end of the process, the user clicks Connect. The client now connects to the Corporate SSID for which the settings were configured on the client during the onboarding process. Using different SSIDs for onboarding clients and for the secure corporate WLAN also helps the reconnection process run more smoothly.

Figure 3-15: Overview of a typical onboarding process (Connectto Corporate SSID)

The client can now authenticate with EAP-TLS using its certificate.

CPPM assigns the client to the correct role, based on policies in the service. In the example shown in Figure 3-15, that role is Tellers.

Onboard experience based on device type

You will now look in a bit more detail at the part of the process in which the user is interacting with the Onboard portal.

No matter what device type, the user begins by logging in. Onboard checks the user credentials against an Onboard Authentication service on CPPM. Onboard next profiles the device type using methods such as checking the HTTP User-Agent string.

Profiling the device lets Onboard do two things. First, it can check with CPPM to determine whether devices of this particular type are authorized for onboarding. For example, a company might want to allow Windows and MacOS devices but deny Android and iOS devices. The company can enforce those rules in an Onboard Authorization policy; however, the default policy permits all device types. Second, profiling the device type lets Onboard customize the portal experience based on that type.

Figure 3-16: Onboard experience based on device type

These three steps occur in the background; the user simply experiences logging into the portal (assuming that the user and device type are authorized for access).

What the user sees next depends on the device type, as shown in Figure 3-16.

On iOS devices, the user is prompted to accept a certificate. Onboard then automatically provisions the device.

On Windows devices, the user is prompted to download the QuickConnect client. The user then launches the client and follows instructions within the client to complete the provisioning process.

On Android devices, the user is directed to download the QuickConnect app from Google Play. The user installs and launches the app and follows its instructions to provision the device. Note that supporting this process requires the Aruba wireless device to permit the client to access Google Play. Some form of walled garden, or allow list, is required on the Onboard or Onboard/Guest SSID.

Overview of configuring ClearPass to support onboarding

You will now look at the process for configuring ClearPass Onboard and CPPM to support onboarding, summarized in Figure 3-17. This study guide does not have the room to cover every detail of the configuration, but you will get a basic sense of the process.

First you need to determine what option you will use for the ClearPass Onboard Certificate Authority and set up that option.

Figure 3-17: Overview of configuring ClearPass to support onboarding

Then you set up the ClearPass Onboard Portal, including Network Settings, a Configuration Profile, and a Provisioning Profile.

You then set up CPPM services to support the onboarding process.

Options for Onboard certificate authorities

You can configure ClearPass Onboard as one of three types of certificate authorities, as shown in Figure 3-18. In every case, ClearPass Onboard is the authority that issues the certificate to the client. The difference is the location of the certificate’s root.

Figure 3-18: Options for Onboard certificate authorities

Root CA

You can set up ClearPass Onboard as its own root CA. It issues its own certificate and also issues certificates to clients. It is generally recommended that you use this straightforward option. Many companies want to limit how users can use the certificates deployed to them through the onboarding process. They should be able to use the certificates to connect to the network, but not to gain any other privileges. When Onboard issues the certificates from its own PKI, the certificates are only valid for authenticating to that ClearPass cluster.

Intermediate CA

However, if a company wants to use its existing PKI to issue certificates, you can set up ClearPass Onboard as an intermediate CA within that PKI. ClearPass Onboard requests an Intermediate CA certificate, which the root CA must sign for it. Onboard can then sign and issue certificates to clients. These certificates will be trusted throughout the existing domain.

Registration authority

ClearPass Onboard can also act as a registration server for a Windows CA. Basically, ClearPass Onboard requests a block of certificates from the Windows CA. These certificates are already signed by that CA. Onboard then distributes the certificates to clients.

One question that always arises is whether you should put a public certificate on ClearPass Onboard. The answer is no. Because of the contained nature of Onboard, and the fact that Onboard loads all of the certificate trust a client stores, the client will be able to validate the self-issued certificates from ClearPass.

Onboard Portal components

You will now look in a bit more detail at how the remaining settings fit together.

You must create at least one Network Settings definition, as shown in Figure 3-19. Network Settings define all the parameters for provisioning the clients’ network connections. This object defines whether wired, wireless, or both types of connections will be provisioned, as well as settings for the wireless network. It defines which EAP authentication methods are supported (protocols), and where the certificates that Onboard sends will be stored on the client (authentication). It also configures the client to trust the subject name and root CA certificate for the proper RADIUS server certificate, typically the RADIUS/EAP certificate on CPPM. Finally, it provides some additional settings that might be required for configuring networking on Windows devices, and in an environment that uses a proxy server.

Figure 3-19: Onboard Portal components

You can optionally create iOS Settings and Window Applications objects. These objects provision iOS or Windows devices with applications that the company wants to deploy to BYOD clients.

You then bundle the Network Settings, iOS Settings, and Windows Applications into a Configuration Profile. The Configuration Profile tells the Onboard portal what it should push to the client.

Finally, you create the Provisioning Profile. This profile references the Configuration Profile and the certificate authority that you established earlier. It further specifies support devices that can use this profile, and all the settings for the portal such as the Web Login page, customized instructions and messages, and settings specific to iOS and MAC clients. The Web Login page defines the page name to which Aruba network infrastructure devices should redirect devices that need onboarding. Another important setting can be Prevent CNA. Captive Network Assistants (CNAs), often provided in smartphones, help users log into captive portals. However, CNAs cannot support the onboarding process; the Prevent CNA setting allows ClearPass Onboard to bypass the CNA. You can enable sponsorship in the profile, which would require a user to receive permission from a sponsor before downloading the Onboard Client. Or you can leave sponsorship disabled and allow anyone who can successfully log into the portal to download the client.

CPPM services for onboarding

When analyzing the CPPM services related to Onboard, you need to consider all phases of access. Two services regulate the user’s and client’s access to the Onboard Portal. The third service authenticates onboarded clients and managed clients. If CPPM is already implementing EAP-TLS to authenticate managed clients, it already has this service configured on it.

Figure 3-20: CPPM services for onboarding

When the user logs into the portal and the portal begins to execute, Onboard triggers the two Onboard services, as shown in Figure 3-20. The first is the Onboard pre-auth, which controls which users may execute the portal. The second service is the Onboard authorization service. Enforcement in this service filters what types of client devices you can onboard.

After the client onboards and reconnects to the secure network, the authentication triggers the 802.1 X service. The client will execute an EAP-TLS authentication, presenting the TLS certificate received from Onboard as the credentials. CPPM simply needs to trust the Onboard CA certificate with the RADIUS/EAP usage. This trust is added automatically on CPPM when you set up the Onboard CA.

Onboard Service Only template

You can use the Onboard Service Only template to create the Onboard Pre-Auth and Onboard Authorization services that you need for the two-SSID scenario. You should edit the Onboard Service Pre-Auth service to permit access only for the desired users. For example, you may edit this service to use your AD authentication source. Then only users who have valid domain credentials can log into the Onboard portal. You can also reference role mapping and enforcement policies within the Onboard Service Pre-Auth and Onboard Service Authorization services to enforce more sophisticated policies based on user or device attributes. You can then use an existing 802.1X wireless service, as shown in Figure 3-21, which you should validate will work for onboarded and non-onboarded clients.

Figure 3-21: Onboard Service Only template

How CPPM authenticates and authorizes clients using Onboard and AD

As you learned earlier, when CPPM uses EAP-TLS to authenticate a client and AD is the authentication source, CPPM checks the certificate validity and it also checks that the user has an account in AD.

This process continues to hold true when CPPM is validating certificates issued by an Onboard CA. CPPM checks the validity of the certificate with Onboard during the authentication cycle. It also checks with the AD server to determine if the user account on the certificate exists in AD. During the authorization cycle, ClearPass will also gather the AD attributes for the user account, so you can use enforcement rules based on AD attributes for your Onboard clients, just as you do for managed clients. This includes checking whether the user account is enabled.

Figure 3-22: How CPPM authenticates and authorizes clients using Onboard and AD

If the user has been deleted from AD, then, even though the certificate is valid, CPPM will block access to the Onboard client, as shown in Figure 3-22.

TEAP

Finally, you will learn how to use Tunneled EAP (TEAP) to support machine and user authentication within a single EAP session. You will see how this method better enables you to distinguish between users on domain computers and users on other types of devices. And you will learn how to set up TEAP on CPPM.

Use case: Distinguishing between users on domain computers and users on other clients

Often companies want to distinguish between users who access the network on domain computers and users who access the network on unmanaged devices. The company manages the domain computers to minimize their vulnerability to malware and exploits. However, the company has no idea whether the unmanaged devices are configured securely or not.

You learned earlier about CPPM’s [Machine Authenticated] and [User Authenticated] roles. You can use those roles to distinguish between several types of client. A domain computer with no user logged in has the [Machine Authenticated] role. CPPM assigns a domain user on an unmanaged device to the [User Authenticated] role, on the other hand.

Figure 3-23: Use case: Distinguishing between users on domain computers

and users on other clients

You want a domain user logged in through a domain computer to receive both the [User Authenticated] and [Machine Authenticated] roles, as shown in Figure 3-23. Then you can use that combination of roles to provide the user a higher privilege level than a user who is only [User Authenticated].

Validating domain users are on domain computers with EAP-TLS

However, with EAP-TLS (or PEAP), the computer authentication and user authentication occur separately. CPPM has to cache the [Machine Authenticated] role for the client across sessions.

When a client authenticates as a computer, CPPM marks the client as Machine Authenticated and caches the client’s MAC address with this status, as shown in Figure 3-24. When a user later logs in, CPPM marks the client as User Authenticated and also matches the client with the cached Machine Authentication. Role mapping and enforcement policies can dictate that the [User Authenticated] status plus [Machine Authenticated] delivers full privileges. In this example, CPPM tells Network Access Devices (NADs) to place the client in the “employee-fullaccess” role.

Figure 3-24: Validating domain users are on domain computers with EAP-TLS

If a user logs in on a client that does not have a cached Machine Authentication, role mapping and enforcement policies can place that client in a different Aruba role, which provides limited privileges.

This EAP-TLS solution can work, but it can also introduce complexity and sometimes fails. The Windows client has to figure out when to trigger machine authentication or user authentication as separate sessions. Consider a situation in which a user is logging into a domain computer for the first time. If the company is using certificate auto-enrollment, it can take some time for the computer to obtain the new certificate. The user authentication might time out, and the user is left without full access.

Validating users are on domain computers with TEAP

Windows 10 2004 and CPPM 6.9 support EAP-TEAP, or TEAP, which provides a more graceful solution to validating whether domain users connect on domain computers. Whenever the Windows client authenticates, it always does so as both a machine and a user, as shown in Figure 3-25.

Figure 3-25: Validating users are on domain computers with TEAP

Much as with PEAP, TEAP creates a TLS session and carries another EAP method within the session. However, TEAP supports the chaining of multiple authentication processes. The supplicant “chains” a token from the earlier authentication to the subsequent authentication. In this way, the machine and user authentication can take place within the same session. Whenever a user logs in, the Windows OS using TEAP runs two methods. The first method authenticates the computer. When a client succeeds at TEAP Method 1, CPPM assigns that client the [Machine Authenticated] role. The second method authenticates the user, and when a client succeeds at Method 2, CPPM assigns the [User Authenticated] role.

TEAP supports multiple types of inner methods. However, Aruba recommends EAP-TLS for both Method 1 and Method 2. The computer authenticates with its computer certificate, and the user authenticates with the user certificate.

TEAP makes it easier for the Windows domain client to authenticate as both a computer and user in a consistent fashion. The client is less likely to fail to authenticate as a user and get stuck in a computer role. On CPPM’s side, CPPM no longer needs to cache the [Machine Authenticated] role.

As of the release of this study guide, Windows AD does not support configuring TEAP on domain computers through GPOs. However, Microsoft Endpoint Manager does support pushing TEAP to clients.

Additional TEAP scenarios

Scenarios can also occur in which a client succeeds at one TEAP method but not at another. CPPM counts this client as authenticated, and you can set up enforcement policy rules to assign appropriate profiles to these clients.

A domain computer that is set up to use TEAP still implements both TEAP methods when no user is logged in. The computer succeeds at Method 1, and CPPM assigns it the [Machine Authenticated] role. The client fails at Method 2. CPPM still counts this client as authenticated, but only with the [Machine Authenticated] role. You can create an enforcement policy rule that assigns clients with the [Machine Authenticated] role to an enforcement profile that applies an Aruba-User-Role VSA. In this example, shown in Figure 3-26, that VSA value is “domaincomputers,” which matches up with an AOS role with appropriate firewall rules for domain computers.

Figure 3-26: Additional TEAP scenarios (domain computer)

Keep in mind, though, that CPPM uses the Method 2 authentication to collect authorization attributes from the authentication source. In this case, Method 2 failed, so the client has no authorization attributes from AD. Therefore, you need to be careful not to try to use those attributes in your rules.

Figure 3-27: Additional TEAP scenarios (BYOD)

As another example, a BYOD that is using TEAP will fail TEAP Method 1 but pass TEAP Method 2. In this case, CPPM assigns the client to [User Authenticated] role. You can use that role to assign the client to an appropriate enforcement profile. In the example shown in Figure 3-27, that enforcement profile applies “Aruba-User-Role=internet-only.”

Configure CPPM to use TEAP to validate users are on domain computers

You will now look at how to configure CPPM to use TEAP to validate that users are on domain computers and assign clients to roles based on the answer to this question. This process is summarized in Figure 3-28. You can easily edit an existing 802.1X wireless service, such as the one that you examined in the previous scenario, for this purpose.

CPPM supports TEAP as of version 6.9, but you must create the TEAP method manually. You can then add that method to your 802.1X services.

Figure 3-28: Configure CPPM to use TEAP to validate users are on domain computers

You should also create a special enforcement profile, which informs the Network Access Server (NAS) of the client’s username. This profile is necessary because TEAP often obscures the username in the outer method.

To finish the set up, you configure the enforcement policy rules to take [Machine Authenticated] and [User Authenticated] statuses into account when assigning enforcement profiles. You also add the enforcement profile that informs the NAS of the client’s username.

The following sections explain more.

Example setup

Add the TEAP Authentication Method

Add a new method and name it an appropriate name such as TEAP. Choose TEAP for type.

As you learned, TEAP supports multiple inner methods. Its Method 1 is the machine authentication because the computer authenticates first. Its Method 2 is the user authentication. You should typically choose to use Method 2 as the User-Name in Access Tracker because the username is more relevant to track than the computer name.

Figure 3-29: Example setup: Add the TEAP Authentication Method

For this scenario, you want to use certificate-based authentication for both the computer and the user. Therefore, you should select Inner method and specify an EAP-TLS method. In Figure 3-29 you see an EAP-TLS method that uses OCSP with no override of the OCSP URL specified in the certificate.

When you are finished configuring the method, click Save. You can now add this authentication method to the service.

Create an enforcement profile to inform the NAS of the username

Often clients’ TEAP settings dictate that the client sets the username for the outer method to “anonymous,” as shown in Figure 3-30. Only the inner methods reveal the client’s actual name, which is the computer name for Method 1 and the username for Method 2. The NAS, such as the Aruba AP or switch, only sees the outer method name. You want your NASes to know client’s actual user names so that you can properly monitor, troubleshoot, and audit.

Figure 3-30: Example setup: Create an enforcement profile to

inform the NAS of the username

You can create an enforcement profile that CPPM applies together with the enforcement profile that assigns the client’s Aruba-User-Role. This second enforcement profile specifies a standard Radius-IETF attribute called “User-Name.” The value for the attribute is this variable: %{Authentication-TEAP-Method-2-Username} CPPM then replaces that variable with the username submitted as part of TEAP Method 2.

If you want CPPM to inform NASes of the client user name for a client that only passes TEAP Method 1, create another enforcement profile. In that profile specify this variable for the Radius-IETF User-Name attribute: %{Authentication-TEAP-Method-1-Username}.

Example role mapping policy

If you have already set up a role mapping policy that works for 802.1X authentication with EAP-TLS to your AD server, you can typically continue to use the same role mapping policy with TEAP, as shown in Figure 3-31. This example shows a very minimal policy, which assigns clients to roles based on whether the AD user account is enabled or not.

When you use TEAP, you will not be able to check whether the machine account is enabled because the machine will only succeed at Method 1, not Method 2, and so the required authorization attributes will not be collected.

Figure 3-31: Example setup: Example role mapping policy

Edit the enforcement policy

You need to edit the enforcement policy to include the [Machine Authenticated] and [User Authenticated] roles as conditions within rules.

In the real world, the enforcement policy might have many rules. But in this example, you are focusing on a very minimal policy so that you can focus on the main points related to TEAP.

Figure 3-32: Example setup: Edit the enforcement policy

This policy used to have a single rule that provided full-access to users with enabled accounts in AD. You now want to add a further condition. The users must have also received the [Machine Authenticated] role, which they could have achieved by passing both TEAP Method 1 and TEAP Method 2. You could also add a condition that requires the users to have the [User Authenticated] role. However, in this case, the existing conditions within the rule implicitly vouch for the fact that the user authenticated, based on the authorization attributes that were collected during user authentication. For this rule, you continue to use the enforcement profile associated with full access. You also add the new enforcement profile that informs the NAS of the client’s Method 2 username.

The example policy shown in Figure 3-32 also has a second rule, which applies to domain computers without users logged in. You should use the “Tips: Role EQUALS [Machine Authenticated]” condition for this rule. If you were using different conditions, such as a role assigned based on the machine account’s status, you must remove those conditions. Remember that only the Method 2 authorization attributes apply, and Method 2 failed in this scenario. Although not shown in Figure 3-32, you could also add a second enforcement profile to this rule. This profile would inform the NAS of the client’s Method 1 username.

Finally, you add a rule for clients that are [User Authenticated], but not [Machine Authenticated]. In this example, the rule matches a CPPM role that indicates the user account is enabled. A client can only receive this role if it has passed user authentication, so you do not have to add a separate condition to explicitly check for the [User Authenticated] role. You then assign an appropriate enforcement profile. (You will learn more about coordinating profiles assigned in CPPM with firewall roles in the infrastructure in the next chapter.)

Note that, in this example, BYOD clients are using TLS, so rule for BYOD clients does not need to include the enforcement profile for informing the NAS of the client’s Method 2 username.

The rule for BYOD clients must be at the bottom of the list. Otherwise, clients that are both [User Authenticated] and [Machine Authenticated] would match it.

Summary

Congratulations! You have completed Chapter 3. You should now be able set up certificate-based 802.1X authentication for wireless clients in a variety of scenarios.

You can now follow best security practices to authenticate clients that are part of a domain, as well as unmanaged clients. You can also create policies to distinguish between users on domain clients versus unmanaged clients and control each type of client appropriately.

Learning checks

A CPPM service uses the default [EAP-TLS] method for the authentication method and AD for the authentication source. What is required for a client to pass authentication? (Select two.) The client certificate is signed by a different CA from the one that signed CPPM’s RADIUS/EAP certificate.

The client certificate is signed by a CA in the CPPM trust list with the EAP usage.

The serial number for the client certificate is listed on a CRL.

The subject name in the client certificate matches an account in AD.

What function does the Onboard Pre-Auth service provide in the onboarding solution? It authenticates users who are using 802.1X to authenticate with certificates issued by Onboard.

It checks whether the user is attempting to onboard an authorized device type.

It checks the credentials that the user submits to the Onboard portal.

It authenticates users who are attempting to connect to an Onboard SSID.

A client has completed TEAP. It succeeded at TEAP Method 1 and failed at TEAP Method 2. What role does CPPM assign it? [Unauthenticated]

[Partial Authenticated]

[Machine Authenticated]

[User Authenticated]

Note: For answers to all learning checks, refer to the Appendix.

4

Implement Advanced Policies on the Role-Based ArubaOS Firewall

EXAM OBJECTIVES

✓ Deploy AAA for WLANs with ClearPass Policy Manager (CPPM).

✓ Define and apply advanced firewall policies.

Assumed knowledge

ArubaOS firewall and how to create firewall policies and rules that use basic actions

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

ArubaOS Mobility role derivation

To continue implementing Zero Trust Security (ZTS), an organization must assign each client to a role. The network infrastructure can then apply access control appropriate to the client.

In this chapter, you will review how ArubaOS devices derive a role for every client that connects to a WLAN. You will also learn how to use ClearPass Policy Manager (CPPM) to assign a role and communicate that assignment to the ArubaOS device. You will then complete a lab in which you practice completing that configuration on CPPM.

Role derivation sequence on ArubaOS devices

Because the power of the ArubaOS firewall partially derives from its role-based nature, you will now briefly review how an ArubaOS controller or gateway assigns a client to a role.

The role derivation sequence begins when a user associates to the network, and the ArubaOS device assigns an initial role, as shown in Figure 4-1. Any user-derived role can override the initial role. User-derived roles are based on criteria such as SSID, location, MAC address, and encryption types. Be aware, though, that user-derived roles are less commonly used now; as you will see, Aruba solutions now have better ways to derive the role.

Figure 4-1: Role derivation sequence on ArubaOS devices

If the user connects to an SSID that requires authentication, the role returned based on the authentication process takes precedence over both the initial role and the user-role derivation.

After authentication, the authentication server, such as ClearPass Policy Manager (CPPM) can return attributes, which will assign a role to the user. Aruba has a set of vendor-specific attributes (VSA) that you can integrate into a RADIUS server. If the server returns an Aruba VSA, the ArubaOS device will automatically place the user into the role or specified VLAN.

If you are using a third-party authentication server and cannot configure or integrate the VSAs in that server, the server will return a typical RADIUS Access-Accept with standard attributes. In that case, you can define rules to specify the server-derived roles. These rules tell the ArubaOS device to look for particular standard attributes returned by the RADIUS server and then to assign a specific role (or VLAN). However, Aruba recommends using the Aruba VSA in most situations.

If the ArubaOS device does not receive a role from a VSA and cannot derive a server-derived role based on a rule, it assigns a default authentication role. Each authentication method has a default role. The ArubaOS device will assign a role depending on which authentication method you configure on the SSID.

Understanding which post authentication role takes precedence

After successful authentication, the client is reassigned to a new, post-auth role. The ArubaOS device can derive this role in one of three ways.

Figure 4-2: Understanding which post authentication role takes precedence

First it looks for an Aruba-User-Role VSA in the Access-Accept from the authentication server, as shown in Figure 4-2. If this VSA is present, and if the VSA specifies the valid role name—in other words, a role that exists on the ArubaOS device—the device assigns this role to the client. (CPPM could also send a downloadable role in a VSA, but this feature is less often used with ArubaOS devices.)

Only if there is no valid VSA does the ArubaOS device move on to the next type of role derivation, which are server rules. These rules allow the ArubaOS device to make the ultimate decision about the authenticated client’s role, but under advisement from the authentication server, based on attribute value pairs (AVPs) or VSAs sent by that server.

Typically, Aruba recommends that you use VSA-derived roles. This approach lets CPPM make decisions about the role to which clients belong, drawing on all the contextual information that it has. You usually use the server rule-derived roles only if you are using a third-party authentication server, which is not the focus for this study guide.

Finally, only if no valid VSA- or server-derived role applies, the ArubaOS device assigns the client to the default role for the authentication method that the client passed. This is sometimes called the role of last resort because you typically want to assign the client to a granular role based on information received from the authentication server. For security, choose a role with the lowest access level appropriate to authenticated users or even “denyall.”

In most cases, role assignment ends at a VSA-derived role, server rule-derived role, or authentication default role. However, if an Authentication, Authorization, and Accounting (AAA) Profile’s user rule set includes rules with L3 criteria, such as DHCP fingerprints, this rule can take effect after authentication and reassign the client to a new role. But L3 user rules are not often used; preferably, you would use CPPM or ClearPass Device Insight (CPDI) to fingerprint and classify devices instead.

What happens if authentication fails?

It is important for you to understand what happens to a client if the client undergoes authentication and fails. If the WLAN enforces 802.1X only, authentication fails, and the client is dropped, as shown in Figure 4-3. WPA-Enterprise uses the 802.1X process to derive keys, and a client cannot connect to the WLAN in this mode without succeeding at 802.1X.

Figure 4-3: What happens f authentication fails?

If the WLAN enforces MAC-Auth, you have choices. If you do not enable fail-through, and a client fails authentication, the client is denied access. But if you enable fail-through, a client that fails authentication remains connected with its current role. That could be the initial role or a user rule-derived role, if a user rule applied to the client.

If the WLAN enforces Layer 3 authentication, such as captive portal, a client that fails authentication also remains connected in the current role.

Recommendations when using CPPM as the authentication server

Aruba recommends that, whenever possible, you leverage the capabilities of CPPM and other solutions in the ClearPass suite to assign devices to roles.

Consider an example, shown in Figure 4-4.

Figure 4-4: Recommendations when using CPPM as the authentication server

You need to support connectivity for some headless devices that do not support 802.1X authentication. You want to sort these devices into different roles based on their type. You might consider setting up an open WLAN and creating user rules to assign various lists of MAC addresses to various roles. However, a more powerful solution might leverage CPPM. You can create a WLAN that uses MAC-Auth and authenticates clients to CPPM. CPPM could then handle assigning the clients to their roles based on profiling information. It sends the correct role for each device in a VSA to the ArubaOS device as usual.

Example of using CPPM to assign clients to roles

You will now learn how to set up CPPM to assign authenticated clients to roles by following an example scenario, illustrated in Figure 4-5.

A company has a Windows domain, Aruba Instant APs (IAPs), and Aruba CPPM. The company assigns users to several AD groups, and it wants to apply different firewall policies to users in different groups. You need to plan how to use CPPM to communicate the correct ArubaOS role for each client to Aruba APs. You will start by looking at a single ArubaOS role for simplicity, the role for loan officers.

Figure 4-5: Example of using CPPM to assign clients to roles

This company has several AD groups for loan officers—for example, “Sunnyvale-LoanOfficers” and “Roseville-LoanOfficers.” The company wants the mobility infrastructure to enforce the same firewall policies for all loan officers, so you decide to create one role on the APs called “loanofficers.” It will be up to CPPM to identify clients who belong to the loan officers AD groups and tell the AP to put those clients in the “loanofficers” ArubaOS role.

First, you create a role mapping policy. The policy will have a rule that selects clients that belong to any of the loan officers groups and applies the “loanofficers-cppm” role.

Next you create an enforcement policy. It has a rule that selects clients with the “loanofficers-cppm” role and applies the “employee-loan-profile” enforcement profile. This enforcement profile defines an Aruba-User-Role VSA with the name of the desired ArubaOS role: “loanofficers.”

At this point, creating both a role mapping policy and an enforcement policy might seem like extra steps. However, you will see the benefits of this approach as you create more complex policies, which draw on additional context. You will also later see that you can add other services that reuse the same role mapping policy.

CPPM [Machine Authenticated] and [User Authenticated] roles

Usually you need to create a role mapping policy in order to assign a client to a CPPM role. However, as shown in Figure 4-6, CPPM has two roles that it assigns to authenticated clients on its own without a role mapping policy: [Machine Authenticated] and [User Authenticated].

Figure 4-6: CPPM [Machine Authenticated] and [User Authenticated] roles

These roles first indicate that the client passed authentication. Next they indicate against what type of account the client authenticated. When CPPM is authenticating clients against Windows AD, a client that authenticates with a domain computer account is [Machine Authenticated], while a client that authenticates with a domain user account is [User Authenticated].

Example role mapping policy

In Figure 4-7 you see the role mapping policy for this example scenario. It has two rules to assign clients to ClearPass roles based on AD group. The example rules use the EQUALS_IGNORE_CASE operator to match the precise AD group name, except for capitalization. As a variation, you could specify that the Group must contain a value, or begin or end with a value. In that way, the rule can match multiple similar group names. In the real world, you would likely have many more rules for other AD groups.

Figure 4-7: Example role mapping policy

As you see, this example policy still has a rule for assigning a CPPM role based on the AD account status, which is important for solutions that use EAP-TLS with authorization to AD. And you will learn about more ways to assign CPPM roles throughout this study guide.

If a client does not match any of these rules, it is assigned the default [Other] role.

Example enforcement policy

As shown in Figure 4-8, this enforcement policy features several rules which combine together multiple CPPM roles and output an enforcement profile. That enforcement profile is configured to send an Aruba-User-Role value to the authenticator. For example, users in the AD security group named Loan Officers (CPPM role, “loanofficers-cppm”) who have active AD accounts (CPPM role, “AD-user-enabled-cppm”) and who are on domain computers (CPPM role, “[Machine Authenticated]”) receive the “loanofficers” enforcement profile. That profile has an Aruba-User-Role VSA set to “loanofficers,” which matches a firewall role on the AOS devices.

The second rule is similar, but for users in a different AD security group.

The third rule uses the [Machine Authenticated] role to assign clients to a “domaincomputers” profile. Your role mapping policy did not assign the [Machine Authenticated] role; remember CPPM applies that role itself if a client authenticates to a computer account on AD. Because this rule is lower in the list, it applies only to domain computers without users who have succeeded in user authentication.

The final rule applies only to users who have not succeeded in machine authentication—in other words, users on BYOD devices.

All of these rules also have enforcement profiles with Aruba-User-Role VSAs.

Figure 4-8: Example enforcement policy

Clients that fail authentication and clients with the [Other] role are denied access.

Applying role-based firewall policies

Next, you will review how ArubaOS devices take a role and enforce controls on it. You will review the role-based firewall and access control rules. You will also look at application policies in more detail and see how they enhance organizations’ security. You will then learn about role-to-role ACLs and receive some general tips for formulating and analyzing tips, which will be useful for the lab. This section concludes with a quick look at some global firewall policies.

Role-based ArubaOS firewall

The role-based ArubaOS firewall can enforce different rules based on user identity and assigned role, rather than simply on features in packet headers. For example, as shown in Figure 4-9, the firewall can restrict contractors to sending Web traffic to limited ranges of IP addresses while it allows managers’ traffic to flow more or less unrestricted.

With less sophisticated firewalls, you would try to create such behavior by ensuring that contractors and managers receive IP addresses in different ranges. You would then create different rules based on source IP address. However, such an approach makes planning user connections more complex—you need more VLANs/subnets and a way to get users in the right VLAN every time. With the ArubaOS firewall, you can place users in the same subnets, but easily create different rules for different users.

Figure 4-9: Role-based ArubaOS firewall

By sending all internal user traffic through the role-based ArubaOS firewall, you can change from a model in which you protect a single perimeter to a model in which you place every user within their own unique and properly customized firewall.

ArubaOS role-based firewall policies

You are now ready to look at the role-based firewall policies in more detail. First you will look at how rules are organized on Aruba Mobility Controllers (MCs) or gateways.

Gateways or Mobility Controllers (MCs)

The ArubaOS firewall implements a different set of policies for each role. Each policy contains a series of rules or access control entries (ACEs), which filter traffic for users assigned to that role.

At the top of every role’s list of policies is the “global-sacl” policy, in which you can place any rules that you want to apply to every user and device, no matter what the role. In Figure 4-10, this policy includes a rule for allowing DHCP traffic. This is just an example of the type of rule that you can put in this policy.

Figure 4-10: ArubaOS role-based firewall policies: Gateways or Mobility Controllers (MCs)

The AppRF policy comes next in every role; it is related to application visibility. It includes application rules that are specific to the role. (More precisely, application rules are categorized as application, application category, Web category, and Web reputation.)

When you create a role in the Web UI, the role has a policy with the same name as the role automatically created for it. This is the default policy for access control rules that are specific to the role.

In addition to adding rules to the default role-specific policy, you can also add other policies to the role. An ArubaOS device comes with many pre-configured policies, and you can also create policies of your own.

Instant APs or APs controlled by Central

Instant APs, including APs controlled by Central, also take a role-based approach to access control rules. However, you cannot create separate policies and apply the policies to multiple roles. Instead you create access control rules within the role itself, as shown in Figure 4-11. Network access control rules control traffic based on the IP header, while application rules permit deeper inspection.

Figure 4-11: ArubaOS role-based firewall policies: Instant APs or APs controlled by Central

You can create a separate ACL, if you want, and then reference that ACL within the role. However, you can only reference one ACL per role, as opposed to on MCs and gateways, which allow you to combine multiple policies in a role.

Access control rules

You will now review access control rules. You can create rules that select IPv4 or IPv6 traffic. On gateways or MCs, the source and destination can be user, any, host, network, Local IP, or an alias. You can select the service from pre-defined services like DHCP or a specific port like TCP 21.

Figure 4-12: Access control rules

As shown in Figure 4-12, the various actions include permit, drop, NAT, and route. When a packet matches a rule, the ArubaOS device executes the main action, as well as any extended actions such as log, mirror, or time range. You can add multiple extended actions to a single rule.

Note that Aruba APs (Instant APs or APs managed by Central) support similar rules to MCs or gateways. However, these rules do not specify a source. Instead the rule always implicitly matches clients assigned to the role (called “wlan access-rule” in the CLI). In addition, “alias” and “user” are not options for destinations. Also the APs do not support the redirect or routing actions. They also might not support the mirroring extended action.

For APs, if you configure the rules through Central WebUI, you will be able to select the destination and services from a drop-down list. Here is an example of a few rules configured as commands (note that the destination is followed by “match” and then the protocol number, the first port in the TCP/UDP range, and then the last port in the TCP/UDP range):

wlan access-rule contractors

rule any any match 17 67 67 permit

rule any any match 17 53 53 permit

rule any any match 6 53 53 permit

rule 10.1.4.0 255.255.255.0 match 6 80 80 permit

rule 10.1.4.0 255.255.255.0 match 6 443 443 permit

rule 10.1.0.0 255.255.0.0 match any any any deny

rule any any match any any any permit

This list permits all DHCP traffic (17 67 67) and DNS traffic (17 53 53 and 6 53 53). It permits HTTP and HTTPS traffic to 10.1.4.0/24. It denies other traffic to 10.1.0.0/16, and it permits all other traffic.

Review application visibility

One of the challenges of controlling user access with a firewall is that so many different modern applications run over HTTP/HTTPS. For example, a user might very well be accessing social media, working in a shared Wiki, sending chats over a company app, and even attending video conferences—all over Web. With traditional ACLs you must allow none or all of the applications that use HTTP/HTTPS, as shown in Figure 4-13. But the ArubaOS application visibility feature provides deep packet inspection (DPI), which gives visibility down to the application layer.

The first step to using application visibility is enabling Deep Packet Inspection (DPI) globally, which requires a reboot. You must also ensure that DPI is enabled on the role (it is by default). If you want to filter by Web category, as well as application, you must also enable WebCC globally and on the role (it is enabled on the role by default).

Figure 4-13: Review application visibility

Also make sure that you have the proper licenses for these features. DPI is supported with the PEF license, but WebCC requires the PEF and WebCC license.

Application visibility and WebCC use cases

By enabling admins to create rules that filter traffic based on application or Web site category, rather than IP header alone, application visibility and WebCC make it much easier for admins to create useful policies. They also enable the company to give admins much greater control over how users connected to the network use the network, as shown in Figure 4-14.

Figure 4-14: Application visibility and WebCC use cases

By filtering traffic based on application or web content, the organization can better control the types of tasks that users perform on the network. This can help eliminate resource-intensive applications, that are not important to the company’s mission. For example, bitcoin mining can consume many resources and is usually an unauthorized activity. With application rules, you can deny this activity entirely.

You can also protect your users from untrustworthy sites, which are often sources of malware or phishing attempts. In this way, you can help keep the internal network free of malware and eliminate some of the most common ways that hackers compromise devices.

Many companies also want to limit their legal liability for content that users access on their network. Application and web content filtering rules make it much easier for the company to implement policies that meet the approval of the legal team.

Application rule

A rule can be made up of application scopes. In an application rule, the source and destination options are the same as the services’ rules. However, instead of selecting services, you can select scopes, as shown in Figure 4-15.

The scopes fall into three categories. Application scopes deal with applications such as Acrobat, Apple Airplay®, and several others. The Application category breaks down into gaming, streaming, and other selections.

Figure 4-15: Application rule

If you are using WebCC, you can specify web category and reputation. Categories include categories for web sites like shopping or travel. When you define the web category, you must also define the reputation. Aruba has partnered with WebRoot to assign each URL a reputation score (1-20 = high-risk, 21-40 = suspicious, 41-60 = moderate-risk, 61-80 = low-risk, and 81-100 = trustworthy). When you specify a reputation in a permit rule, the ArubaOS firewall permits matching traffic with that reputation or higher. When you specify a reputation in a deny rule, the ArubaOS firewall denies matching traffic with that reputation or lower.

You can only configure two actions: deny and permit. You can also apply extended actions if you want.

Example role with application and WebCC rules

You will now look at an example of some application and WebCC rules that many corporations apply.

Role structure

In Figure 4-16 you see a basic structure for the role.

Figure 4-16: Example role with application and WebCC rules: Role structure

It begins with a standard “logon-control” policy, which permits DHCP, DNS, and denies IPv6 router advertisements.

It then has policies for “blocked-apps” and “blocked-websites.”

Next the role could have a policy or policies for controlling the users’ access to the corporate LAN. The rules in these policies depend on the corporation’s particular needs, and they are not the focus for this example.

Finally, the policy permits all other traffic, which will be traffic destined to the Internet. The total effect is that users can access the Internet, but the applications and sites that they access will be restricted by the “blocked-apps” and “blocked-websites” policies.

You can create a similar role for Instant APs, including ones managed by Central. However, rather than defining rules in separate policies, you would define them all within the role.

Example Blocked-Apps policy

An example of the applications that many corporations block in a blocked-apps policy is shown in Figure 4-17. You can adjust this policy based on your organization’s particular requirements. For example, a school offering access to students might want to prohibit youtube, or prohibit most youtube channels, but permit educational youtube channels. Application policies give you the power to meet specialized requirements like these.

Figure 4-17: Example Blocked-Apps policy

Again, the syntax is slightly different for APs, but you can adapt this example to them.

Example Blocked-Websites policy

An example of a blocked-websites policy is shown in Figure 4-18. Note that this policy is particularly restrictive, making it appropriate for a guest role when guests might be minors. You would, of course, communicate with your organization’s stakeholders to customize a policy appropriate for each role.

Figure 4-18: Example role with application and WebCC rules

Again, the syntax is slightly different for Instant APs, but you can adapt this example to them.

Role-to-role ACLs

On Aruba MCs using an Aruba 8 architecture under a Mobility Conductor, you can also implement role-to-role ACLS. A role-to-role ACL allows or denies communications between clients in different roles on a role-by-role basis. For example, you might want to permit users in the Finance role to access clients in the printer role, but not to access other user clients.

Figure 4-19: Role-to-Role ACLs

Starting from ArubaOS 8.6.0.0, multi-MC deployments support role-to-role ACLs between two clients terminating on different MCs. (Earlier versions only permitted role-to-role ACLs between clients on the same MC.) In the example scenario shown in Figure 4-19, MC-1 and MC-2 are part of the same Policy domain group and Finance users are anchored on MC-1, Sales users are anchored on MC-2 and the printer has anchored on MC-3. Based on the sample Role-Role-ACL which is configured on MC-1, user traffic from the Finance user to the Sales user is denied, but traffic from the Finance user to the Printer client is allowed.

Tips for formulating and analyzing ACLs and policies

As you formulate ACLs and policies within a rule, you need to continuously assess it to make sure that the policy does what you expect. In a moment you will practice doing just that. First consider a few tips.

It is important to consider rule order. The firewall applies the first rule that a packet matches and only that rule. It is best practice to define the most specific rules at the top of the list to ensure that packets will always hit those rules. For example, as shown in Figure 4-20, an HTTPS packet sent to 10.1.0.24 would match both the first and third rules. The first rule applies, and the packet is dropped.

Figure 4-20: Tips for formulating and analyzing ACLs and policies

You also need to be able to interpret network masks or prefix lengths so that you can understand the IP addresses included in a range.

Also keep in mind that the firewall is stateful. If a client is permitted to send traffic to a destination, the destination can send traffic in return.

For MCs and gateways, remember the difference between “user” (IP addresses of clients assigned to the role) and “any” (all IP addresses). Note that APs’ access control rules, configured within roles, do not specify a source; the source is always clients assigned to the role.

To understand which rules are more specific than others, you need to understand a bit about subnet masks. Remember: the more 1s in the binary mask, the more specific the match because each 1 indicates a bit that must match. For example, 10.1.0.0 255.0.0.0, or 10.0.0.0/16, matches all IP addresses from 10.1.0.0 to 10.1.255.255 (the first two octets must match the network address, and the second two octets do not need to). 10.1.0.0 255.255.255.0, or 10.0.0.0/24, matches all IP addresses from 10.1.0.0 to -10.1.0.255.

On the subject of “user” vs “any,” “user” matches all IP addresses that belong to users assigned to this role, while “any” matches all IP addresses, including on devices on the other side of the firewall (connected to trusted ports). A rule that permits users to send any traffic to any destination allows users to initiate sessions and send requests to devices on the other side of the firewall. But those devices on the other side of the firewall cannot initiate sessions or send requests to clients assigned to the role. A rule that permits any source to send any traffic to any destination allows both users and devices on the other side of the firewall to initiate.

Keep in mind that the MC or gateway discovers the user IP address when the user is assigned that address by DHCP; the rule that permits DHCP traffic must use “any” as the source.

Summary

Congratulations! You have completed Chapter 4. You can now use CPPM to authenticate clients, classify them, and tell ArubaOS authenticators to assign the clients to roles. You can also implement role-based policies with the ArubaOS firewall. You can take instructions from your security team and translate them into effective rules.

Learning checks

An ArubaOS device uses 802.1X to authenticate clients to ClearPass Policy Manager (CPPM). How does Aruba generally recommend you assign roles to clients that successfully authenticate? Using the authentication default method

Using server-derived rules

Using user-derived rules

Using the Aruba-User-Role VSA sent by CPPM

If a client attempts to access a particular subnet, the company wants to lock that client out of the network for a period. How can you enforce this action? Enable DPI and create an application rule that denies traffic sent to that subnet.

Enable WebCC and create an application rule that denies traffic sent to that subnet.

Create a firewall rule that denies traffic sent to that subnet and also applies denylisting (blacklisting).

Create a firewall rule that denies traffic sent to that subnet and also applies NAT.

Note: For answers to all learning checks, refer to the Appendix.

5

Evaluate Endpoint Posture

EXAM OBJECTIVES

✓ Evaluate endpoint posture.

Assumed knowledge

Authentication, Authorization, and Accounting (AAA) framework and basics of protocols such as RADIUS and TACACS+

Forms of Layer 2 authentication such as 802.1X

PKI and digital certificates

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

ClearPass posture architecture

A user might be trusted, but the user’s device might have insecure settings, leaving it vulnerable to compromise. To obtain a Zero Trust Security (ZTS) network, companies require a way to evaluate devices’ “posture,” or compliance with best security practices. They further need a way to take action based on what is found—for example, granting full access to compliant endpoints but quarantining non-compliant or insecure endpoints.

This chapter will begin with an overview of the ClearPass posture architecture and key concepts related to posture assessments.

Why evaluate posture?

Up to now, you have been primarily looking at how ClearPass Policy Manager (CPPM) can use information about clients’ identity to control those devices’ access. Identity is a crucial aspect to understand and on which to base access decisions. However, for true zero trust security, companies must go beyond identity to include other forms of context as well.

Posture provides another crucial piece of context on which to base access control decisions. Posture refers to the state of settings on the client OS and whether those settings comply with the company’s security policies. For example, is the client’s firewall enabled, as shown in Figure 5-1? Is the browser set up securely? Does the client have all required patches installed? Posture could also refer to whether the client is infected with malware. These are just some of the examples of settings that can be assessed to determine a client’s posture.

Figure 5-1: Why evaluate posture?

Many companies find it difficult to control all of these settings on every client. Companies need a tool like ClearPass, which can dynamically assess every client’s posture and then use that assessment to adjust the client’s rights on the network. For example, many companies now have employees who work both on- and off-site at various times. When employees take their clients off-site, those clients might be subjected to more threats, which the employees could then introduce back into the corporate environment when they return on-site.

It makes sense to grant a different level of access to a client that is set up securely and a client that is vulnerable to attack, even if exactly the same user is on the two different clients. Often the company wants to “quarantine” the insecure client. In other words, the insecure client is granted very limited access, only sufficient to reach a remediation server which gives the user guidelines for bringing the client into compliance and correcting its posture.

ClearPass posture tokens

ClearPass tracks clients’ posture using application posture tokens, which represent the clients’ health, as shown in Figure 5-2. You may configure these tokens to take on different meanings, but they are generally used in this way:

A Healthy token means that the client is compliant, and no restrictions should apply to network access.

A Checkup token means that the client is compliant, but there is an update available for the client. A client can proactively remediate to a healthy state.

When a client evaluation is in progress, the client receives a Transient token. Typically, this occurs when auditing a client. The network access granted in this case is interim.

A Quarantine token means that the client is out of compliance and should get restricted network access. This means the client should only have access to the remediation servers.

An Infected token returns when the client is infected and threatens other systems in the network. ClearPass should deny or severely restrict network access.

When ClearPass cannot obtain the client’s posture token, it returns an Unknown token. This might occur if there is no posture agent assigned to the client, if the client agent is unable to communicate with ClearPass, or the client agent hasn’t performed a posture check.

Figure 5-2: ClearPass posture tokens

Tokens are information about the endpoint. As the ClearPass administrator, you have the ability to interpret the tokens in any way that you wish. You can do this by writing enforcement rules to evaluate the token. For example, you could do something like: IF the tips: Posture equals healthy THEN assign employee full access.

Whenever a client first connects to the network, their posture token will always be unknown. After the agent checks in, ClearPass policies can update the token to any one of the other five depending on conditions.

OnGuard options for posture

ClearPass Policy Manager (CPPM) can receive information about clients’ posture using ClearPass OnGuard.

As shown in Figure 5-3, the OnGuard agent is available as a persistent agent or dissolvable agent. The persistent agent installs an application on the user’s device. Windows, Mac OSX, and Linux clients are supported. The dissolvable agent is web-based and does not require the user to install a permanent OnGuard application on their device. There are some advantages to using the persistent agent, such as auto-remediation capabilities, which are not possible with the dissolvable agent. Auto-remediation helps to resolve the client’s issues by automatically enabling or disabling a function like a firewall. Furthermore, the persistent OnGuard agent performs a large range of posture checks, including checking for peer-to-peer applications, virtual machines, USB device presence, and many others. In light of this, most users choose to implement the OnGuard agent for posture analysis.

Figure 5-3: OnGuard options for posture

OnGuard also supports an agentless option. Agentless OnGuard supports health checks and posture analysis on Windows clients without installing the persistent OnGuard agent. It supports Windows clients as well as servers joined to the domain. CPPM can also provide agentless scanning of MacOS and Linux clients using SSH. To support agentless OnGuard, ClearPass servers themselves must be joined to the domain. You must enable Insight and device profiling on CPPM. The devices that you want to scan must also be joined to the domain, and they require a local admin account. If you want CPPM to scan MacOS or Linux devices, you must configure CPPM with the SSH credentials for their devices under Administration > External Accounts. CPPM uses its device profiling capabilities for agentless scanning. You will learn more about device profiling in a later chapter.

More detailed prerequisites for agentless OnGuard, in ClearPass v6.9, are as follows:

On ClearPass Policy Manager:

Policy Manager Insight must be enabled.

Endpoint device profiling must be enabled.

The ClearPass Policy Manager server must be joined to the domain.

The server requires OnGuard licenses or Compliance Suite Licenses.

On Windows client:

Windows endpoints should be joined to a domain.

Administrative Shares must be enabled on Windows endpoints.

Server Message Block (SMB) v2 should be enabled on Windows endpoints.

C:\Windows\winexesvc.exe and other Agentless OnGuard files should be whitelisted in Antivirus and Firewall applications.

In Policy Manager 6.9.3 and earlier releases, PowerShell scripts must be allowed on Windows endpoints. Starting with Policy Manager 6.9.4, Agentless OnGuard for Windows uses an .exe file instead of a PowerShell script to launch Agentless OnGuard on Windows endpoints.

On the network:

Access to TCP Ports 135, 139, and 445 should be allowed.

For DHCP profiling, the CPPM server IP address should be configured as an IP helper on the network devices.

Interaction of information from multiple sources

To determine the client’s system posture, CPPM primarily uses posture policies. These policies define how OnGuard agents check clients’ posture and how the results of those checks translate to an application posture token for the client.

Figure 5-4: Interaction of information from multiple sources

CPPM can also integrate with audit servers like Nessus, as shown in Figure 5-4. The Nessus audit server settings include a scan profile, which defines how the server’s checks translate to an application posture token for the client. Note that audit servers might also have rules that determine a role for a client.

If CPPM receives application posture tokens for the same client from multiple sources, CPPM assigns the client a system posture token based on the lowest-rated application posture token. It then uses this posture token when applying enforcement policy rules.

ClearPass posture actions

As shown in Figure 5-5, ClearPass can take a number of actions based on the posture tokens. Often you make the change in token trigger a change of authorization (CoA). Then the client re-authenticates and is assigned a new enforcement profile based on posture-based rules within the authentication service’s enforcement policy. You could alternatively use a posture action to place the client in a quarantine VLAN directly.

Figure 5-5: ClearPass posture actions

If the user’s Windows security patches are out of date, you could redirect the device to a remediation portal to download the requisite application, patches, and hotfixes. Optionally, you could display a simple message to contact support or IT.

If you use a persistent OnGuard agent, you can auto-remediate the client to automatically enable a firewall, update the antivirus software, or disable peer-to-peer applications.

Evaluate endpoint posture with the OnGuard agent

ClearPass supports many options for posture assessment. This study guide has time to focus on just a couple examples. First, you will learn how to use the ClearPass OnGuard agent to run posture checks on managed endpoints, as well as how to create policies with ClearPass Policy Manager (CPPM) to use the information collected.

Example of posture evaluation in action

As you learned in the previous section, ClearPass provides many options for enforcing posture assessment. You will now examine a basic configuration for implementing the OnGuard persistent agent and for using posture as part of an 802.1X service.

First examine the process by which a client authenticates, receives a posture token, and receives network access in this scenario, shown in Figure 5-6.

Figure 5-6: Example of posture evaluation in action

When the client first requests access, the Network Access Device (NAD), such as the AP, blocks everything except Layer 2 authentication traffic. This allows the client the ability to send authentication traffic to CPPM, but does not allow the agent to send an SHV report. The authentication request matches the 802.1X service on CPPM. This CPPM has an enforcement policy with a rule that matches “unknown” posture tokens.

This rule applies an enforcement profile, which instructs the Network Access Device to grant limited access only. With a limited role on the Network Access Device, the client can get an IP address with DHCP. It also needs DNS services. It must also be able to make an HTTPS (TCP 443) connection with CPPM and also send traffic to CPPM on TCP 6658.

This level of access allows the agent to send an SHV report to CPPM. A Web-based Health Check Service on CPPM reads the SHV report from the agent and updates the posture token.

You must configure this service to also send a terminate session message to the Network Access Device, forcing the client to re-authenticate.

It is important to note that the posture token must be cached in the service, so the updated token is available for the second authentication. If you do not select the Cached Policies and Roles option on the 802.1X service Enforcement tab, then the new posture status will disappear as the client re-authenticates.

When the client authenticates for the second time, the 802.1X service in CPPM will reevaluate the enforcement rules and, this time, because of the cached posture token, it will assign the client a new role and grant full access.

You can also use posture evaluation with Layer 3 authentication methods such as captive portal. However, this topic is beyond the scope of this study guide.

Ongoing connectivity and temporary tokens

As shown in Figure 5-7, the posture tokens assigned to the endpoints are temporary and expire in five minutes if there is not an update from the agent. If the agent is continually sending updates to ClearPass, the token will continually get updated. If the client leaves the network for more than five minutes, the token expires and returns to an unknown token.

Figure 5-7: Ongoing connectivity and temporary tokens

This ensures that when any client connects to the network the status is always unknown until the agent has time to check-in and update the status.

Overview of posture policies

To complete this configuration, you must create at least one posture policy. As shown in Figure 5-8, the posture policy defines one or more System Health Validator (SHV) plugins, each of which consists of a set of compliance checks, as well as instructions for remediation.

Figure 5-8: Overview of posture policies

The posture policy further includes rules, which define the posture token assigned to each client based on the results of the SHV checks. These example rules apply the Healthy posture to clients that pass all checks and the Quarantine posture to clients that fail any checks.

More details on posture policies

Add a new posture policy

Now that you have an overview of the configuration, you will look at some of the new components in a bit more detail. You can configure the posture policies in the sidebar menu under Configuration > Posture > Posture Policy. Click Add.

When adding a new posture policy, you will need to give the policy a name and select OnGuard Agent as the Posture Agent, as shown in Figure 5-9. (The NAP Agent is a legacy option.) You also select on which OS the agent will run.

Figure 5-9: More details on posture policies: Add a new posture policy

You can also restrict the policy to only certain ClearPass roles. You might use this option when the company wants to apply one set of restrictions to general users and another set of restrictions to a specialized user group, for example. Based on identifications and role assignments, CPPM could instruct the agent differently depending on the user type.

You should configure a different posture policy for each family of OS that you want to assess, such as one posture policy for Windows operating systems (including multiple client and server OS versions) and one posture policy for Linux operating systems.

Posture policy plugins

On the Posture Plugins tab, you will need to configure one of the plugins. This study guide focuses on the ClearPass Windows Universal System Health Validator, which is supported by the OnGuard agent. (The Windows NAP agent supports the Windows System SHV and Windows Security SHV plugins.)

When you select a plugin, you must configure it. Selecting the Configure button opens the configuration page. For the ClearPass Windows Universal SHV, you can select each OS that you want to check, as shown in Figure 5-10. You can expand various settings menus under the OS and select options. For example, you can check whether the firewall is on, whether specific services are running or not running, whether various hotfixes are applied, and many other settings.

Figure 5-10: More details on posture policies: Posture policy plugins

For some settings, you can select an auto-remediation option, which enables the OnGuard agent to try to fix the problem itself. If you want the agent to auto-remediate different features, you will need to select auto-remediation in the settings as well as configure auto-remediation in the service. The auto-remediation setting in the service executes the settings you have configured.

The OnGuard agent has an option for messaging where you can configure a user notification message. This message pops up on the user’s screen telling them what they are in violation of – in this example, the firewall. You can also configure a quarantine message that sends when ClearPass applies the quarantine token.

After you configure the desired checks for one OS, you can then select other operating systems and configure the checks for them. When you include multiple operating systems within the same posture profile, ClearPass applies the correct checks, based on the current client OS, during the Web-Based Service process.

Many of the settings have the option to allow the system to check for a specific product and version, or you can check for any valid product.

Posture policy rules

You can apply OnGuard tokens through a set of rules. These rules are relatively simple in scope. You have the option for “Passes all SHV checks,” “Passes one or more SHV checks,” “Fails all SHV checks,” or “Fails one or more SHV checks.” For each of these options, you select the corresponding posture token. Aruba recommends you do not assign the transition token and the unknown token as the system uses these. When you configure the rule, you must also select the plugin for which the rule applies.

An example of a go/no-go set up is shown in Figure 5-11. The client either passes all checks and receives the healthy posture, or it fails one check and is assigned to the quarantine posture.

Figure 5-11: More details on posture policies: Posture policy rules

These rules do not discern which metrics the client health check passed or failed. For example, for the “Passes one or more SHV checks” condition, the client could pass any one of the checks and the result is the same. If you want to control clients based on whether they pass or fail particular metrics, you must create policy enforcement rules that reference the Posture namespace and specific checks. However, this configuration is beyond the scope of this study guide.

Example configuration Web-Based Health Check service

In addition to creating a posture policy, you must create a WebAuth enforcement policy. This policy’s rules use posture tokens as conditions and define the actions that should be taken on clients, when they first receive that posture. For example, a rule might say "If a client has a healthy posture, apply the Agent Enforcement Profile (Healthy)." Agent enforcement profiles define the posture actions that you examined earlier. In this scenario, though, you are not using the agent enforcement profiles for their enforcement and remediation capabilities. You will simply use them to send a message to the OnGuard agent. Instead you are also attaching a second profile to each rule that tells the Network Access Device (NAD) to terminate the session, as shown in Figure 5-12. The NAD then forces the client to log in again, at which point the 802.1X service can take over.

Figure 5-12: Example configuration Web-Based Health Check service

Note that the action specified in the WebAuth enforcement policy rule only applies when the client’s posture changes to that posture. If a client had a Healthy posture and then receives a Healthy posture again, the rule action does not apply.

You pull together the posture policy and WebAuth enforcement policy in a Web-Based Health Check Only service, which is responsible for receiving incoming SHV reports. You can reference multiple posture policies in a service as long as the policies do not apply to the same client. You reference just one enforcement policy.

Example configuration 802.1X service

When you are using posture and 802.1X together, as in this example, it is important that you configure the 802.1X service's enforcement policy to take posture into account. Then, when a client is forced to reauthenticate by a change in its posture, the 802.1X service can use that posture to apply the appropriate profile.

Figure 5-13: Example configuration 802.1X service

Aruba generally recommends referencing the posture in the enforcement policy, rather than the role mapping policy. This ensures CPPM will take the latest posture token into account.

You can create an 802.1X service using similar guidelines to those discussed earlier in the study guide. You can also adjust an existing service. When configuring the enforcement settings, make sure to enable the option for caching roles and posture from previous sessions, as shown in Figure 5-13. Otherwise, CPPM will always consider clients to have unknown posture, and they will never be allowed to connect fully.

You can then create or adjust a RADIUS enforcement policy to apply the desired profiles to clients based on their posture and other context. In this example, an enforcement policy had a rule that assigned clients with the “employees-cppm” role to the “employee-full-access” enforcement profile. Now you add another condition to that rule. The client must have a healthy posture.

Because clients begin with an unknown posture, you need a rule for that posture. In this example, that posture applies a “limitedaccess” profile, which sends an Aruba-User-Role VSA. The NADs should be configured to allow very limited access to the corresponding role. For example, the role might only permit the traffic necessary for the OnGuard agent to communicate with ClearPass and obtain a posture (DHCP traffic, DNS traffic, HTTPS traffic to the ClearPass server, and TCP port 6558 to the ClearPass server). Some companies might also choose to permit Internet access for these clients.

You must also create a rule that specifies the quarantine posture and an appropriate profile for those clients. Again, you would typically have this profile send an Aruba-User-Role VSA set to a name like “remediation,” and the Aruba Network Access Devices take responsibility for applying appropriate firewall policies.

You could even create more complex rules, in which, for example, quarantined employees of different types and quarantined contractors receive different profiles, as required by the security team.

ClearPass clusters and CoAs

This scenario features a common setup, in which the WebAuth enforcement policy applies a CoA profile. This profile triggers CPPM to send a CoA to the client’s Network Access Server (NAS) so that the client can reauthenticate and be assigned a new enforcement profile, based on its new posture.

If you are using a ClearPass cluster, you need to consider the time that it takes for the endpoint's new posture to propagate across the cluster. The Subscriber that processes the endpoint's SHV report and assigns the new posture might not be the same Subscriber that authenticates the client. In the example shown in Figure 5-14, Subscriber 1 receives and processes the SHV report, while the AP is using Subscriber 2 to authenticate clients. When Subscriber 1 detects that the client's posture changes to Quarantine, for example, it does two things. It pushes the new posture information to the Publisher, which then distributes the information to other subscribers. Based on the WebAuth enforcement policy rules, Subscriber 1 also sends a CoA to the client's AP (or other NAS) after a brief delay. You want to make sure that it sends the CoA after the new information has propagated throughout the cluster. That ensures that Subscriber 2 knows that the client's posture is now Quarantine when the client reauthenticates.

Figure 5-14: ClearPass clusters and CoAs

By default, CPPM uses a 2-second delay between when it decides to issue a CoA and when it sends the CoA. But you can adjust the delay in each server's configuration under Service Parameters. Most solutions require at least a 5-second delay. However, the time required to propagate information depends on many factors such as cluster size and network latency. You might start with a 5-second delay, run some tests, and then increase the delay if required.

You should also note that the Subscriber that processes the SHV report sends the CoA, even if that is not the Subscriber with which the NAS is configured to use as its authentication server. So, make sure to configure your NASes to accept CoAs from all servers in the cluster.

Microsoft Endpoint Manager integration

The rest of this chapter will cover one more option for posture assessment. You will be introduced to how ClearPass integrates with Microsoft Intune to evaluate endpoints’ posture.

Third-party integration for endpoint information

CPPM can also receive information about endpoints by integrating with third-party solutions in the 360 Security Exchange program. CPPM integrates with a variety of mobile device management (MDM) and mobile application management (MAM) solutions, including Microsoft Endpoint Manager, formerly called Intune, which is an Azure cloud-based MDM. It also integrates with AirWatch, Citrix XenApp, and Ivanti LANDesk. These solutions can send information about endpoints’ settings, as well as applications running on them. CPPM can also integrate with McAfee ePolicy Orchestrator to receive information about endpoints’ compliance with various policies. For a complete list of Exchange partners, visit https://www.arubanetworks.com/partners/technology-partners/partner-finder and filter for “360 Security Exchange” under programs.

Figure 5-15: Third-party integration for endpoint information

The integrated MDM and endpoint compliance solutions do not specifically set CPPM posture tokens. Instead CPPM periodically polls them for endpoint attributes, as shown in Figure 5-15. It adds these attributes to the client’s endpoint profile within the CPPM Endpoints Repository, which is a database that CPPM maintains with a profile for each client that has authenticated to it (or about which CPPM has learned in another way). These endpoint attributes provide rich information about the client’s status and posture. ClearPass admins can then use these attributes in role mapping or enforcement policy rules. In this way, they can assign clients to CPPM roles and enforcement profiles based on information relevant to the company’s specific security policies.

Microsoft Endpoint Manager

Microsoft Endpoint Manager is an MDM and MAM system, which runs in the Microsoft Azure cloud. Microsoft manages a broad array of operating systems, including Apple iOS, Apple iPadOS, Apple MAC, Google Android, and Windows. For a complete list, refer to Microsoft documentation.

Endpoint Manager integrates with Azure Active Directory to regulate users’ access to the corporation’s Microsoft Office 365 and other SaaS applications. Admins can create application protection policies to control which applications users in various groups can access and what users can do within those apps. The company can further create different policies for devices that are enrolled in Endpoint Manager and for unmanaged devices. Endpoint Manager also provides profiles and policies to configure mobile devices.

Figure 5-16: Microsoft Endpoint Manager

Of most interest to you for this study guide, though, is Endpoint Manager’s ability to assess mobile device’s compliance status. As shown in Figure 5-16, Endpoint Manager integrates with Mobile Threat Defense, which feeds it information about the devices’ security compliance and posture. Endpoint Manager can then provide that information to a Network Access Control partner such as CPPM. (CPPM must run version 6.7.2 or above to integrate with Endpoint Manager.)

CPPM integration with Endpoint Manager

When you integrate CPPM with Endpoint Manager, CPPM can use Endpoint Manager’s information about the mobile device’s posture to make its decisions. The extension for this integration is still called “Intune.” The process when the Intune extension uses Periodic Sync mode, which was added in v5, is illustrated in Figure 5-17.

In this mode, CPPM periodically polls Microsoft Endpoint Manager for endpoint attributes. The default polling interval is 30 minutes, but you can change this interval when you configure the Intune extension. At the polling interval, CPPM pulls down the attributes from Microsoft Endpoint Manager in batches. It then adds the attributes with their latest values to the corresponding endpoint record in its Endpoint Repository.

Figure 5-17: CPPM integration with Endpoint Manager

When a client authenticates, CPPM uses its role mapping and enforcement profile policies to assign enforcement profiles to the client. These rules can use Endpoint attributes received from Microsoft Endpoint Manager in their conditions. For example, you might have a role mapping rule that assigns clients with an Endpoint attribute of “Intune Compliance State EQUALS compliant” to a “compliant-­cppm” role. Then you can edit enforcement profile rules to require clients to have the “compliant-cppm” role status to receive full access.

Note that CPPM uses the endpoint attributes that it received in the last polling period. If an endpoint’s attributes change in a later poll, the endpoint remains authenticated with the current profile. But when the client reauthenticates, CPPM will use the new information.

The Intune v5 extension also supports HTTP Authorization Source Mode. When the extension uses this mode, you add Intune as an authorization source and specify that source in the services that authenticate clients. CPPM then dynamically calls Microsoft Endpoint Manager to receive the latest attributes during the authorization process. It can request the attributes for the client in question based on MAC address. However, MAC address is not supported for wired devices, in which case, CPPM must request the attributes based on the client Intune ID.

This study guide, however, focuses on the Periodic Sync mode. If you want to learn more about HTTP Authorization Source Mode, refer to the Microsoft Intune Integration Guide available at the following URL: https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=27076#bm4318f5bb-0e1b-45de-8f6e-c3ef8648bd0d

How to configure the Intune Extension in Periodic Sync mode

To configure CPPM to use the Intune Extension, you follow the basic process summarized in Figure 5-18:

You register CPPM in Microsoft Azure. During this process, you will also collect information, which you will later use to configure the Intune extension.

You install the extension and configure settings for it.

You can then use Intune attributes in rules within your enforcement policies.

Figure 5-18: How to configure the Intune Extension in Periodic Sync mode

Note that this process applies to using the extension in Periodic Sync mode.

If you want to use HTTP Authorization Source Mode, you must also set up Intune as an authorization source. Refer to the Microsoft Intune Integration Guide available at the following URL: https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=27076#bm4318f5bb-0e1b-45de-8f6e-c3ef8648bd0d

Register CPPM in Microsoft Azure

To integrate with Microsoft Endpoint Manager, you must register CPPM as an application within Microsoft Azure. These instructions assume that an Intune (Endpoint Manager) Tenant Admin account has already been set up in the company's Azure solution.

Access Azure at https://portal.azure.com. Log in with the Intune Tenant Admin account.

Open Azure Active Directory and select App Registrations. Click New registration. Specify an intuitive name like “CPPM-CompanyABC.” Accept default settings and click Register.

You will then see the registered application as well as information about it. Record the values for “application (tenant) ID” and “client (directory) ID.”

Next you must assign the registered application several permissions. Click Add API permissions. Add at least these minimum permissions:

Intune (or Endpoint Manager) – get_device_compliance

Microsoft Graph – DeviceManagementApps.Read.All

– DeviceManagementManagedDevices.Read.All

– DeviceManagementManagedDevices.ReadWrite.All

– User.Read

Then use the left-hand menu in Azure to navigate to Certificates & secrets > Client secrets. Select New Client secret. Specify a secure value, which you will also need to specify when you configure the Intune extension. You can set an expiration period of your choice.

For more details on these steps, refer to the Microsoft Intune Integration Guide.

Install the extension

You are now ready to install the Intune Extension. You complete this step using the ClearPass Guest pages. Go to Administration > Extensions and choose to install an extension, as shown in Figure 5-19.

Figure 5-19: Install the extension

You can then search for the extension by name. You will see the Intune extension, which you can then choose to install. You will also be asked to give Intune an extension IP address. When you use the v5 extension, you can let ClearPass set the extension IP address automatically.

The extension will then install. After the installation you should choose to edit the extension configuration. You will see XML settings like the ones shown in Figure 5-20. You should then enter the information that you collected for the various fields in the previous step.

When you are done, select the check box for restarting the extension and save your changes. The extension will restart with the correct configuration.

Configure the extension

After the installation, you should choose to edit the extension configuration. You will see XML settings like the ones shown in Figure 5-20.

Figure 5-20: Configure the extension

Specify the information that you previously collected from Azure in these attributes:

“tenantID”—You collected the tenant ID when you registered CPPM as an application in Microsoft Azure Active Directory.

“clientID”—You collected the client ID when you registered CPPM as an application in Microsoft Azure Active Directory.

“clientSecret”—You set this value when you created the client secret in Microsoft Azure Active Directory.

If you want, you can edit the polling scheduling. The value for "syncSchedule" uses cron syntax:

First value = Minute (0-59)

Second value = Hour (0-23)

Third value = Day of the month (1-31)

Fourth value = Month (1-12)

Fifth value = Day of the week (0-6 in which 0 is Sunday)

An asterisk permits all values. The default setting establishes polling at a 30-minute interval: “*/30 * * * *”

When “syncUpdatedOnly” is set to true, CPPM only pulls down attributes that have changed since the last poll. This setting speeds up polling, particularly when CPPM polls frequently. The “syncOnStart” attribute determines whether or not CPPM pulls down the current attributes when the extension first starts.

You can leave the “enableEndpointCache” and “cacheTimeInSeconds” attributes at their default values. These attributes only apply when you are using HTTP Authorization Source mode.

In version 6.9 and later, you should leave the “cppmUserName” and “cppmPassword” attributes undefined.

Use “intuneAttributes” if you want to specify the list of attributes that CPPM collects from Endpoint Manager. For example, you could set the value to the following: [“complianceState”, “deviceEnrollmentType”, “jailBroken”]. If you leave the default value, null, CPPM collects all attributes.

You can generally leave other attributes at their default values.

When you are done, select the check box for restarting the extension and save your changes. The extension will restart with the correct configuration.

Use Intune attributes in CPPM policies

CPPM will now receive endpoint attributes from Microsoft Endpoint Manager. It will store the attributes for each client in the Endpoint Repository record for that client. You can set up role mapping and enforcement policies that use those attributes. To use the attributes in a rule, set the condition Type to Endpoint. In the Name field, type Intune to see the list of attributes delivered by Endpoint Manager, as shown in Figure 5-21. For example, you could create a condition that checks the endpoint’s compliance state: Endpoint Intune Compliance State EQUALS compliant. This is just one example of what you can do.

Figure 5-21: Use Intune attributes in CPPM policies

You can look in records within the Endpoint Repository to find examples of the Intune attributes and their values. Work with the IT security team to formulate policies that meet that particular organization’s needs.

CPPM always has access to Endpoint attributes even if you have not enabled authorization in the service. However, if you want to specify attributes through the Endpoint Repository, you must enable authorization in the service to which you want to apply the endpoint enforcement policy. Then add the Endpoint Repository as an authorization source in the Authentication tab.

Summary

Congratulations! You have completed Chapter 5. You can now set up ClearPass OnGuard agent-based health checks. You can also use the postures derived from these health checks in CPPM enforcement policies. You also learned how to integrate CPPM with Microsoft Endpoint Manager (Intune) to obtain rich information about the posture of clients managed by that third-party solution. You can now better control clients’ access based on their compliance with key security policies.

Learning checks

What is one difference between the OnGuard persistent agent and the dissolvable agent? The persistent agent only works for Windows systems while the dissolvable agent supports Windows and Linux.

The persistent agent supports ongoing monitoring while the dissolvable agent supports a one-time check.

The persistent agent integrates with Microsoft Intune while the dissolvable agent offers no integration.

The persistent agent posture overrides the posture delivered by any other source while the dissolvable agent posture is overridden by other sources.

Match the Component with its Role. ___Posture policy

___WebAuth enforcement policy

___Web-based Health Check Only service

Provides rules that assign enforcement profiles based on system posture

Provides SHV plugin configuration and rules for assigning posture based on SHV checks

Responds to requests from OnGuard agents

You have added an Intune extension, and now you need to configure it. How do you determine what to specify for the “tenantId,” “clientId,” and “clientSecret? You should always leave the default values for these fields.

You should consult with Aruba support to assess the right values for your environment.

You should register ClearPass as an App in Azure AD and collect the values there.

You should use XML files available in GitHub to look up the right values.

Note: For answers to all learning checks, refer to the Appendix.

6

Implement a Trusted Network Infrastructure

EXAM OBJECTIVES

✓ Set up secure authentication and authorization of network infrastructure managers, including: – Advanced TACACS+ authorization

– Multi-factor authentication

✓ Secure L2 and L3 protocols, as well as other protocols such as SFTP.

Assumed knowledge

Basics of managing ArubaOS-CX (AOS-CX) switches

Authentication, Authorization, and Accounting (AAA) framework and basics of protocols such as RADIUS and TACACS+

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

Implement secure management of Aruba devices

The foundation of trusted network communications lies on a trusted network infrastructure.

In this first section, you will learn how to implement secure management of ArubaOS devices. In this way you will ensure that only authorized managers can change switches’ configuration, as well as control their rights.

Review management access on AOS-CX switches

AOS-CX switches offer two, main options for accessing the management plane, as shown in Figure 6-1.

The switches support out-of-band management through an Ethernet port called the management (mgmt) port. The management port operates at Layer 3 and has an IP address. Admins can access the CLI or Web UI at the mgmt IP address.

Figure 6-1: Review management access on AOS-CX switches

AOS-CX switches also support in-band management. With this method, admins reach the management plane through the same ports to which users and other endpoints connect. They contact the switch at an IP address configured on one of the switch Layer 3 VLAN interfaces or ports.

You control which access methods are available out-of-band and in-band by telling the switch on which VRFs particular protocols are enabled. The mgmt port is part the “mgmt” VRF while data ports are part of the “default” VRF, by default. If you want to confine the switch to out-of-band management, you should enable SSH and HTTPS on the mgmt VRF and disable them on the “default” VRF. This approach makes it easy to specify and determine which protocols the switch accepts from different network segments.

Aruba generally recommends out-of-band management as the more secure option. To achieve the best available security, you should ensure that the OOBM network and the production network are physically separated. In other words, you should connect the mgmt ports and the management stations to switches dedicate to the management network. Doing so does require extra effort and equipment. However, management switches can be inexpensive, since 1GbE will provide all the necessary bandwidth for management.

If the customer requires inband management, you should leave SSH and HTTPS enabled on the default VRF (or whatever VRFs the customer is using).

Note that enabling a protocol on a VRF or port applies to traffic using that protocol that is directed to the switch. It has no effect on traffic using that protocol but sent to another destination.

Adding a control plane ACL for inband management

When you use inband management, users can reach the switch management interfaces. You will implement authentication, as discussed in a moment, but it is best practice to implement an additional layer of security beyond manager authentication alone.

Figure 6-2: Adding a control plane ACL for inband management

You can create an IP access control list (ACL) that specifies the types of traffic that you want to allow, as well as authorized sources. You can then apply that list to the control plane.

The ACL uses the format shown in Figure 6-2.

Example control plane ACL

It is very important that you understand that the control plane ACL filters all IP traffic to the switch control plane as well as the management traffic. The ACL must permit all necessary traffic, including routing updates, RADIUS traffic, SNMP traffic, DNS traffic, and any other traffic that you want the switch control plane to accept, as shown in Figure 6-3. Carefully document all the traffic that the switch might need to receive before implementing the ACL.

Figure 6-3: Example control plane ACL

The control plane ACL filters traffic in the inbound direction. In other words, when you add a rule to the ACL, the source IP address is the device that you want to permit to communicate with the switch.

Review management authentication options

As shown in Figure 6-4, you have several options for authenticating managers who reach the switch’s management plane. For the best scalability and manageability for authenticating SSH and HTTPS managers, you should generally choose an external authentication option: TACACS+ or RADIUS. Each of these protocols have their advantages, and often a company will have its own preference as to which you use.

Figure 6-4: Review management authentication options

TACACS+ provides the ability to control the commands that managers enter in a granular way. It also provides detailed auditing for each command that managers enter, which is a requirement for some companies. In addition, the TACACS+ packets exchanged between the switch and the authentication server are encrypted by a shared secret. While this encryption does not meet modern standards and can be cracked, it does provide a layer of obfuscation against casual eavesdropping.

RADIUS also has some features that companies might want. RADIUS is the standard authentication protocol used with port authentication like 802.1X. So, if the company is also implementing port authentication, the company might choose to use the same RADIUS server to authenticate managers. RADIUS itself does not encrypt messages between the switch and the authentication server. However, if security is required, you can add RadSec.

Managers can also authenticate against a local list of users. However, Aruba primarily recommends local authentication as a backup method in case the TACACS+ or RADIUS authentication server is not available.

Review TACACS+ server setup

To use either of these external authentication methods, you must specify the authentication server on the Aruba switch.

First you must identify the server by IP address or fully qualified domain name (FQDN). The latter assumes that you have configured the switch to communicate with a DNS server.

You must also specify a key, which sets a shared secret for communicating with the server, as shown in Figure 6-5. You can specify a global key used for all authentication servers configured on the switch, or you can specify an individual key when you define the server, which overrides the global key. Set the key as long as possible to enhance security. AOS-CX switches allow keys up to 31 characters in length.

Figure 6-5: Review TACACS+ server setup

You must also be aware of the network topology and understand on which VRF the switch reaches the server. You can then specify this VRF when you define the TACACS+ server. If you do not define a VRF, the default VRF is used.

You can optionally place the server in a manually defined group. If you do not, the server is part of the default group for its type. For TACACS+ servers, this group is named “tacacs.” For RADIUS servers, this group is named “radius.”

You can also configure the authentication protocol used with RADIUS or TACACS+. The switches support CHAP or PAP with both TACACS+ and RADIUS; the default protocol is PAP. You do not need to set the protocol on ClearPass Policy Manager (CPPM). It will accept either CHAP or PAP for RADIUS messages, but only PAP for TACACS+ messages. Therefore, you should leave the switches’ TACACS+ protocol as PAP.

You must verify that the authentication server is similarly set up to communicate with the switch. For the purposes of this study guide, this server is CPPM. CPPM must have the switch defined on it as a network device. The shared secret configured for this network device must match the key configured for the server on the switch. Otherwise, the server will not respond to the switch’s messages.

Review using TACACS+ for manager authentication

After you have specified the RADIUS or TACACS+ servers on the switch, in the default or other group, you can enable external authentication for specific access types. After specifying aaa authentication, you specify the access type (such as ssh or https-server), the primary authentication method (such as “group tacacs,” “group radius,” or “local”), and an optional secondary authentication method.

When a manager attempts an SSH or HTTPS connection with the switch, the switch queries the manager for a username and password. The switch then submits them to a server in the primary authentication group specified in the aaa authentication login command. In the example shown in Figure 6-6, that server is CPPM. CPPM authenticates the client and returns a TACACS+ response, which rejects or accepts the login request. If CPPM accepts the request, it generally also includes an Aruba-Admin-Role VSA in the message to define the manager’s role on the switch.

Figure 6-6: Review using TACACS+ for manager authentication

The switch uses the secondary authentication method if the switch does not receive a reply from the server specified in the primary method. Typically, you should specify local as the final option and create at least one local user account so that the switch remains manageable in case of network outages.

Setting the secondary authentication option only causes the switch to use that option when the first option times out. However, sometimes you want to use the secondary option when the first authentication server actually rejects the client. Then users can authenticate with either a remote or local account during normal operation, which some companies prefer. Also, managers avoid issues in which they are not able to log into a switch because the authentication takes too long to time out. To enable the switch to use the secondary method when the primary one rejects the user, enter aaa authentication allow-fail-through.

Methods for assigning users to manager roles

The AOS-CX switch determines which group to assign a particular manager based on information in the TACACS+ server’s response.

CPPM, and other TACACS+ servers that support vendor specific attributes (VSAs), can include an Aruba-Admin-Role VSA. The value for this VSA is the name of the group: administrators, operators, auditors, or a custom group created on the switch. This VSA is simple to use and flexible.

Figure 6-7: Methods for assigning users to manager roles

However, AOS-CX switches support other VSAs as well. If multiple VSAs or attribute value pairs (AVPs) are included, the Aruba-Admin-Role VSA takes precedence, as shown in Figure 6-7. If that VSA is not present, the Aruba-Priv-Admin-User VSA takes precedence. It assigns roles based on numbers from 1-15 and 19. 1 assigns the user to the operators group, 15 to the administrators group, 19 to the auditors group, and 2-14 to any manually configured local groups that have those IDs.

AOS-CX switches can also accept the standard TACACS+ privilege levels. The level takes effect for TACACS+ if no Aruba VSAs are sent. Privilege level 1 corresponds to the operators group. Privilege level 15 corresponds with the administrators group. Note that the standard TACACS+ privilege levels do not support assigning managers to the auditors group. You can also set up custom local groups to correspond with a privilege level.

Administrators

Administrators have full privileges, including full read-write access to the CLI and Web UI. They can configure any settings, including user accounts.

Operators

Operators have no configuration privileges. They can only view nonsensitive switch configuration information. In the CLI, operators can only issue show commands, and they can only view settings in the Web UI.

Auditors

Finally, auditors have access to CLI commands only in the auditor context (auditor>). Auditors can view event log contents and local accounting log contents. They can also copy command output to a remote server or a local USB drive.

Using Aruba CPPM as the TACACS+ authentication server

You will now look at how to configure Aruba CPPM to act as the TACACS+ server for the Aruba switch, AP, or gateway.

As with all functions on CPPM, you must define a service to receive the incoming requests. You can choose to use a wizard for TACACS+ Enforcement, or you can create a service manually. In either case, the correct service type is TACACS+ Enforcement.

Figure 6-8: Using Aruba CPPM as the TACACS+ authentication server

As shown in Figure 6-8, CPPM submits the manager’s credentials to the authentication source, which is AD in this example. It also collects authorization attributes for authenticated clients.

CPPM then processes the service’s role mapping and enforcement policies. In the end, it applies a TACACS+ enforcement profile. It is this profile which defines the specifications for the TACACS+ response, including the Aruba-Admin-Role VSA.

Defining TACACS+ enforcement profiles

You set up TACACS+ Enforcement services much like you do other CPPM services. The main new concept is the TACACS+ enforcement profile.

You will need one TACACS+ enforcement profile per admin role that you want to assign to managers on your infrastructure devices. For example, if you want to authenticate switch managers and assign them to the “administrators” and “operators” roles, you will need two profiles.

Much like the RADIUS enforcement profiles that you have already examined, a TACACS+ enforcement profile is defined by a name and type (TACACS+). The profile further specifies whether to accept or reject the request.

But TACACS+ accept enforcement profiles have a Services tab, rather than an Attributes tab like RADIUS enforcement profiles. In this tab, you define the TACACS+ privilege level from 0 to 15. This privilege level determines the client’s level of management access on the network infrastructure device. However, when CPPM also sends the Aruba-Admin-Role VSA, the role specified in that VSA overrides the privilege level.

In the Services tab, you can also add one or more services and then specify attributes or other settings for those services, as shown in Figure 6-9.

Figure 6-9: Defining TACACS+ enforcement profiles

When you are using TACACS+ to authenticate managers of Aruba CX switches or ArubaOS mobility devices, you should add the “Aruba: Common” service. You then add the “Aruba:Common Aruba-Admin-Role” VSA and set the value to the name of the group to which you want to assign managers with this profile.

CPPM has two default TACACS+ enforcement profiles related to Aruba network infrastructure devices:

[ArubaOS Wireless – TACACS+ Root Access] adds the Aruba:Common service, sets the Aruba-Admin-Role VSA to “root”

[ArubaOS Wireless – TACACS+ Read-Only Access] adds the Aruba:Common service, sets the Aruba-Admin-Role VSA to “read-only”

If you want to assign managers to different roles on ArubaOS network devices, you will need to add similar enforcement profiles with those roles’ names as the value for the Aruba-Admin-Role VSA.

Defining TACACS+ enforcement policies

Once you have defined the TACACS+ enforcement profiles, you can reference them in an enforcement policy.

You generally want one enforcement policy for each different type of network infrastructure devices that are using CPPM as a TACACS+ server. In the example shown in Figure 6-10, you have a policy for wired devices, your AOS-CX switches. And you have a policy for your wireless devices. This approach often works well because Aruba switches and ArubaOS mobility devices required different TACACS+ profiles for their managers.

Like all enforcement policies on CPPM, TACACS+ enforcement policies consist of rules. Each rule has a condition. The action for each rule is one of your TACACS+ enforcement profiles.

Figure 6-10: Defining TACACS+ enforcement policies

In this example, you are using the Authorization:AD instance:Groups attributes for conditions. In other words, managers are assigned to a profile and admin role based on AD security group. For example, the Wired TACACS+ enforcement policy assigns members of the NetworkAdmins group to the Wired Admin TACACS+ enforcement profile. And this profile assigns the managers to the “administrators” group on AOS-CX switches based on the Aruba-Admin-Role VSA.

However, you can use different attributes in conditions to fulfill different use cases.

You could also use role mapping policies and then reference ClearPass roles in the enforcement policies. However, in this example, you are not using role mapping policies; because you cannot reuse the same role mapping policy across multiple services, it is simpler to just use enforcement policies.

Example TACACS+ enforcement services

When you have created the TACACS+ enforcement profiles and policies, you are ready to combine those components in services. You will now look at one way to set up these services. You can adjust the approach shown in Figure 6-11 to your particular requirements.

Figure 6-11: Example TACACS+ enforcement services

CPPM comes with a default service for authenticating TACACS+ managers on ArubaOS devices. This service authenticates managers against CPPM’s local repository. By default, this service matches all incoming TACACS+ requests. When you look at the service, you will not see any service rules. However, services with the TACACS+ Enforcement type always include an implicit rule of “Connection:Protocol EQUALS TACACS+.”

If you want to authenticate managers on multiple types of devices, using accounts in a domain or directory, you will need to create new TACACS+ enforcement services. You often need different services and enforcement policies for wireless and wired managers because these devices use different names for their roles.

You can create the service manually or using a wizard. The considerations are much the same.

When you select the TACACS+ Enforcement type, the service will automatically select TACACS+ requests. You will need to add another rule that selects requests from specific infrastructure devices. One way to do this is by selecting ranges of NAD-IP-Addresses. For example, a company might give all switches at a site IP addresses in subnet: 10.1.10.0/24. You would create this rule to select TACACS+ requests from those devices: “Connection:NAD-IP-Address BEGINS with 10.1.10.” You could create a similar rule in a TACACS+ Enforcement service for wireless managers that selects IP addresses on ArubaOS devices.

For each service, you would then proceed to specify the correct authentication source and reference your enforcement policy.

You must make sure to place the new services in the list above the default Aruba Device Access Service so that TACACS+ requests are processed against those services first. Or you should disable the default service.

Using command authorization on AOS-CX switches

Up to now you have focused on authenticating managers and controlling their access level based on Aruba admin role name. However, you can also control admin access more granularly by authorizing admins for particular commands.

Figure 6-12: Using command authorization on AOS-CX switches

When you enable command authorization to a TACACS+ server on an AOS-CX switch, the switch checks every command submitted by a manager to the TACACS+ server, as shown in Figure 6-12. The server then tells the switch whether the manager is allowed to enter that command or not. The switch enforces the response by executing the command or by outputting a message that the command is not authorized.

In addition to providing granularity of access control over managers, command authorization also creates an audit trail on CPPM, which records in Access Tracker every command entered by each manager. You can even set up alerts in ClearPass Insight if admins enter denied commands.

Adding command authorization to a TACACS+ enforcement profile

Before you enable command authorization on the switches, you should adjust the TACACS+ enforcement profiles to implement the authorization.

Edit the enforcement profile associated with the admin role to which you want to apply per-command authorization.

Figure 6-13: Adding command authorization to a TACACS+ enforcement profile

Then add the “Shell” service in addition to the “Aruba:Common” service, as shown in Figure 6-13. The Shell service makes the Commands tab appear.

Specifying denied/permitted commands

The Commands tab includes a list of commands, which are either permitted or denied. You can choose to deny all unmatched commands (the default option) and add specific permitted commands. Or you can choose to permit all unmatched commands and add specific denied commands, as shown in Figure 6-14. If you choose to permit unmatched commands, the manager is still bound by the specific limits of the assigned role. For example, this profile uses the “Aruba:Common” service to assign the operator role with a VSA and the “Shell” service to permit or deny specific commands. Permitting all unmatched commands will permit all operator commands that are not specifically denied; however, the operator will still be prohibited from entering manager commands even though those commands are not explicitly denied.

When you add a command, you specify only the first keyword in the command for the command value. For example, you could enter “show.” This command entry will now act a bit like a permit or deny list itself. You can specify a list of attributes for the command and choose whether to permit or deny each of those attributes. You also select whether unmatched attributes are permitted or denied. You can use regular expressions to make the entries more flexible. For example, “show users information” will not match the “show” command “users” attribute because it is not an exact match to that attribute. However, “show users information” will match the “users .” attribute with . indicating a wildcard for multiple characters.

If you want to deny all arguments for a command, it is easiest to simply add the command, specify no arguments, and set the unmatched arguments setting to “deny” as shown in the first rule in this example. Similarly, if you are using a deny unmatched command approach, you can easily permit all arguments for a command by adding the command, leaving the arguments list empty, and setting the unmatched arguments to “permit.”

Figure 6-14: Specifying denied/permitted commands

You can add multiple commands to the list to create as granular a policy as the company requires.

This example is a profile for operators on AOS-CX switches. As a result of this configuration, operators cannot enter any command that begins “user” or “show user.” They can enter all other operator commands. However, they cannot enter administrator or auditor commands because the role limitations continue to apply.

However, if you want you can take a different approach. You can assign all users to TACACS+ privilege level 15 and set no Aruba-Admin-Role. You can then use the commands rule list alone to control the users’ privileges. This approach gives you more flexibility, but it does require you to be careful in defining precisely which commands are permitted and denied.

Enforcing command authorization

Once you have set up the enforcement policies with the desired command lists, you can enter this command on the AOS-CX switches to enable command authorization to CPPM: aaa authorization commands group local. The option after commands specifies for which forms of access to the CLI this type of command authorization applies (default applies if either connection type does not have a method explicitly configured for it). You then specify group and the TACACS+ group to which you assigned CPPM.

Aruba strongly recommends specifying local or none as the secondary authorization source. Otherwise, managers will not be permitted to enter any commands if the switch loses connectivity with CPPM. If you specify local, the switch checks the command list configured for the particular admin group to which the user is assigned. Therefore, if you choose that option, you must create local command lists and apply them to the group.

Figure 6-15: Enforcing command authorization

After you enter the aaa authorization commands command, the switch imposes a check each time a manager connected in the specified way (SSH or console) enters a command. Because CPPM’s TACACS+ group is the source in the example shown in Figure 6-15, the switch sends a TACACS+ authorization request to CPPM. The request falls under the authentication request for login, which the user already passed. CPPM checks the user’s enforcement profile and determines whether the command is allowed. It then sends an authorization response with its decision (permit or deny the command).

SSH public key authentication

SSH also provides some additional authentication options.

You have been concentrating on password authentication. With this form of authentication, the switch checks the manager credentials—a username and password—against a local list, RADIUS server, or TACACS+ server based on the choice that you make with the aaa authentication login ssh command.

Figure 6-16: SSH public key authentication

However, AOS-CX switches also support public key authentication for SSH, as shown in Figure 6-16. Public key authentication takes a similar approach to certificate authentication, but without a concept of a PKI. The SSH client is configured with one or more public/private key pairs, sometimes called SSH host keys. When the client is prompted to log in with public key authentication, the client submits the manager’s username. It further proves its identity by also submitting that manager’s public key and by signing data with the corresponding private key.

The key stands on its own without having a trusted issuer in the way a digital certificate does. Therefore, the SSH server on the AOS-CX switch must be set up with a list of authorized usernames and their public keys in advance.

Public key authentication on AOS-CX switches is always implemented against the local list of users, regardless of the setting in the aaa authentication login ssh command.

Setting up SSH public key authentication

Public key authentication is enabled by default on AOS-CX switches. If it has been disabled, you can enable it with this command: ssh public-key-authentication.

To use public key authentication, you must also create one or more user accounts and assign them to a managers group: administrators, operators, or auditors. In the example shown in Figure 6-17, you are adding the user without a password because you want the user to login with the public key.

Figure 6-17: Setting up SSH public key authentication

You must then specify the public key that the user has installed on their SSH client. The correct syntax consists of the key algorithm, a space, and then the full key with no line breaks. After you create the account, the manager with the corresponding public and private key can connect to the switch. The manager receives the rights associated with that account on the switch without submitting a password.

If you want to use only public key authentication, you must disable password authentication with this command: no ssh password-authentication.

If you leave both password and public key authentication enabled, you can choose to enable two-factor authentication. The switch then requires a manager to pass both public key and password authentication. The switch first checks the SSH client’s key against its local admin accounts. It then submits the manager’s username and password to the authentication server specified for SSH.

Secure L2 and L3 protocols

It is also critical that you secure the fundamental protocols on which network communications rely. The next section covers AOS-CX features for protecting many Layer 2 and Layer 3 protocols.

Overview

Many of the protocols used to regulate Layer 2 and Layer 3 communications were developed in a time in which internal users and clients were considered inherently trustworthy. By default, these protocols accept all valid protocol packets without distinguishing between whether those packets arrive from legitimate network infrastructure devices or not.

Figure 6-18: Overview

But you need to deal with the reality that internal users might be untrustworthy or internal clients might be compromised. Hackers can exploit Layer 2 and Layer 3 protocols to manipulate where traffic is directed, eavesdrop on traffic, create DoS attacks, and launch man-in-the-middle attacks.

A Zero Trust Security network implements protection for the protocols, some of which are listed in Figure 6-18. You will learn about these protections in the following sections.

Review BPDU protection

Without protections on spanning tree, rogue switches can connect to the network and, worse, become the spanning tree root. The new root alters paths, which can cause DoS attacks, as well as let the user on the rogue device eavesdrop on traffic or even launch an MITM attack.

Figure 6-19: Review BPDU protection

BPDU protection prevents this situation from occurring. This feature operates at the port level and is best implemented on edge ports, which should not be receiving BPDUs.

BPDU protection monitors a port for incoming BPDUs. If the port receives a BPDU, the switch shuts down the port, as shown in Figure 6-19, protecting the network from the rogue device. You can configure the amount of time the port remains disabled using a number of seconds that ranges from 0 to 65535. Configuring a value of zero (0) specifies an infinite time out period. In other words, the port remains disabled until manually re-enabled.

The switch also logs an event when BPDU protection blocks the port.

BPDU protection versus BPDU filtering

Do not confuse BPDU protection with BPDU filtering.

BPDU filtering effectively disables spanning tree on a port. It drops all incoming BPDUs and also prevents the transmission of BPDUs on a port. The port also always remains in the forwarding state. Therefore, BPDU filtering, implemented on an edge port, would prevent a rogue switch from taking over as root by dropping the rogue switch’s BPDUs. However, because BPDU filtering forces the port into a forwarding state, it could allow loops to occur.

Edge ports that are vulnerable to rogue switches are often also vulnerable to situations such as these, which could create loops:

Users connect an unauthorized switch that does not support spanning tree. The users loop ports together on that switch.

Users loop wall jacks together.

Therefore, you should NOT implement BPDU filtering on edge ports. BPDU filtering is best suited to disable spanning tree on trusted switch-to-switch ports that are implementing routing and that you know will not create loops.

Review DHCP snooping

When possible, you should enable DHCP snooping to protect your network against address spoofing and address exhaustion attacks. Because, on its own, the straightforward DHCP process offers no security, your switch takes the role of a security guard, overseeing DHCP exchanges and ensuring that endpoints act as they should.

AOS-CX switches support DHCPv4 and DHCPv6 snooping as of version 10.04. The example configuration shown in Figure 6-20 focuses on v4 for simplicity. But remember to also configure v6 snooping if your network uses IPv6.

You should typically implement DHCP at the access layer, as shown in Figure 6-20.

Figure 6-20: Review DHCP snooping

With DHCP snooping, the switch distinguishes between trusted and untrusted ports. When you enable DHCP snooping on a VLAN, all interfaces in that VLAN become untrusted by default. You must configure trusted ports manually.

Untrusted ports

The switch filters DHCP packets on untrusted ports and determines whether or not they are allowed.

For example, only DHCP servers should send Offer and Acknowledgement packets, so if the switch detects these types of packets on an untrusted port, it immediately discards them. On the untrusted ports, the switch only accepts DHCP client packets:

Discover

Request

Decline

Inform

Release

The switch also verifies information in the DHCP clients’ Discover and Request packets against the packet headers before allowing the packets onto the network. It drops packets in which the source MAC address does not match the DHCP client MAC address—a sign of spoofing. It also drops Release and Decline packets that arrive on a different port from one detected for the packets’ source MAC. In other words, the packets have the signs of coming from a hacker trying to prevent a legitimate client from receiving an IP address.

In addition, although the switch accepts DHCP client packets on untrusted ports, it does not forward client packets on these ports. This behavior prevents other clients from hearing each other’s DHCP traffic.

Trusted ports connect to the network’s own trusted devices, such as your DHCP server or, if the server is centralized, an upstream switch. The switch allows DHCP packets to flow freely on these ports. It accepts any DHCP packet on these ports. The switch also forwards DHCP client broadcasts on these ports.

You can also set a max binding on a per-interface basis. This setting limits the number of DHCP addresses a client can obtain on a given port in order to prevent IP exhaustion attacks. In this example, you set the max binding to 4, but you could adjust that limit based on the needs of your network (for example, if the port connects to an AP).

Configuration

DHCP snooping operates on an individual VLAN level. Generally, you enable this feature on endpoint VLANs, especially untrusted ones such as guest VLANs, on access switches. To enable DHCP snooping, you must enable the feature both globally and on the desired VLANs. You then set the trusted port.

In the example shown in Figure 6-20, the access switch, which is implementing DHCP snooping, forwards the DHCP traffic to the core switch, which relays the traffic. However, in some networks, the access switch might be routing traffic and acting as the relay. In this case, the port (or link aggregation) that forwards DHCP Discover and Request packets and receives DHCP server packets does not support the VLAN on which DHCP snooping is enabled. However, you must still make that port a trusted port for DHCP snooping.

You can increase the level of security that DHCP snooping provides by configuring authorized servers. When you configure authorized server addresses, the switch must receive packets from DHCP servers on a trusted port and the packets must have a source address that is on the authorized server list. If the server address is not on the list, even if the port is trusted, the switch considers the packet invalid and drops it.

Configuring authorized servers is optional. If you do not configure them, your switch will consider all DHCP server packets that arrive on trusted ports to be valid. You can configure multiple authorized DHCP servers.

Review ARP inspection

To review, ARP helps devices map each IP address on a subnet to the MAC address of the device that owns that IP address. Most IP devices update their tables every time they receive an ARP packet even if they did not request the information. This makes ARP vulnerable to several attacks.

Hackers can commit ARP spoofing by sending fraudulent ARP responses to other clients on the network. This can allow attackers to “poison” clients’ ARP tables with the wrong MAC address for an IP address. In effect, the hacker is able to spoof an IP address. ARP poisoning and IP spoofing can lead to MITM attacks, in which hackers intercept traffic that does not belong to them. If a hacker masquerades as a network infrastructure device, the poisoning can create a DoS attack.

Figure 6-21: Review ARP inspection

When you enable ARP inspection in a VLAN, all interfaces in that VLAN become untrusted by default. The switch checks ARP requests and responses on all untrusted ports. It:

Examines all ARP requests and responses received on that port

Verifies the packet’s IP address and MAC address match an entry in the switch’s IP-to-MAC binding table for that VLAN – If the binding is valid, the switch updates its local ARP cache or forwards the packet to the appropriate destination.

– If the binding is invalid, the switch simply drops the packet, preventing other devices from receiving it and being tricked by the faulty information.

Implements optional validity checks

The IP-to-MAC binding table is typically built up by DHCP snooping. Therefore, you should enable DHCP snooping on your network at least one week before enabling ARP inspection. You can also add static IP-to-MAC bindings if you have any devices with static IP addresses on ports that are untrusted for ARP inspection.

Also make sure to configure any switch-to-switch ports, such as lag 1 in the example shown in Figure 6-21, as trusted ports. Otherwise, the switch will reject ARP responses on this port and interfere with communications across the network.

In addition to verifying IP-to-MAC address bindings, you can configure the switch to perform three further checks:

src-mac—The switch checks ARP request and response packets to ensure that the source MAC address in the Ethernet header matches the sender MAC address in the body of the ARP packet. If the two addresses do not match, the switch discards the packet.

dest-mac—The switch checks each unicast ARP response packet to ensure that the destination MAC address in the Ethernet header matches the target MAC address in the body of the ARP packet. If the two do not match, the switch drops the packet.

ip—The switch checks the sender and target IP addresses of ARP packets and drops any ARP packets that have an invalid address. Invalid IP addresses include: – 0.0.0.0

– 255.255.255.255

– all IP multicast addresses

– Class E IP addresses

By default, none of these checks are enabled.

IP source lockdown

ARP inspection prevents ARP spoofing and ARP poisoning attacks. You can also add dynamic IP lockdown to prevent hackers from spoofing their source IP address in any IP traffic. You enable this feature on a physical interface with this command: ipv4 source-lockdown or ipv6 source-lockdown. When you enable IP source lockdown on a port, the switch inspects all traffic that arrives on a port. It checks that the source MAC address and source IP address match the binding for that port, as shown in Figure 6-22.

Like ARP inspection, IP source lockdown relies on DHCP snooping to build a table of IP-to-MAC bindings, so you should make sure to enable DHCP snooping well before enabling IP source lockdown. Then IP source lockdown ensures that wired clients send traffic only from the source IP address that was assigned to them by the legitimate DHCP server. You can alternatively create static binding entries for IP source lockdown, which manually associate a particular IP address with a particular MAC address on a particular VLAN and port.

Figure 6-22: IP source lockdown

Saving IP-to-MAC bindings to external storage

Because the IP-to-MAC binding table is so important for the ARP inspection and IP source lockdown features, you might want to preserve it in case the switch reboots. Otherwise, ARP inspection might interrupt traffic while the switch rebuilds the table.

Figure 6-23: Saving IP-toMAC bindings to external storage

To prevent this situation, you can configure the AOS-CX switch to back up the IP-to-MAC binding table to external storage, as shown in Figure 6-23.

First, create an external-storage volume that references a Network Attached Storage (NAS) server. Then specify saving the IP-to-MAC binding table to a filename on that server. Use these commands, replacing the volume name, IP address, and filename with values suitable for your environment:

Switch1(config)# external-storage myNAS

Switch1(config-external-storage-myNAS)# address 10.254.1.13

Switch1(config-external-storage-myNAS)# enable

Switch1(config-external-storage-myNAS)# exit

Switch(config)# dhcpv4-snooping external-storage volume myNAS file Switch1_iptomac

The switch then copies all the IP bindings to an external storage file so that they are retained after the switch restarts. When it restarts, the switch reads the IP bindings from the configured external storage file to populate its local cache, as shown in Figure 6-23.

Secure OSPF communications on client VLANs

Now you will briefly review how to secure routing protocol communications on client VLANs, focusing on OSPF. Often the routing topology is designed such that some Layer 3 interfaces are used to support endpoints, but not to connect to other routers (stub networks) while others are used to connect to other routers or routing switches (transit networks).

The stub networks are usually VLANs, and you can configure these VLANs as “passive interfaces.” The subnet associated with a passive interface is advertised in the protocol, but the OSPF routing device does not accept OSPF packets on this interface and does not form neighbor relationships on it. This is a very easy way to prevent rogue devices from sending unauthorized OSPF packets.

Figure 6-24: Secure OSPF communications on client VLANs

On AOS-CX switches, you should typically configure the OSPF instance to make all interfaces passive by default. You then explicitly disable the passive interface settings on the correct interface or interfaces—lag1, in the example shown in Figure 6-24. The other interfaces, such as VLAN 11 here, remain passive interfaces.

Secure OSPF communications on transit interfaces

Occasionally a VLAN or other Layer 3 interface will support both endpoints and legitimate OSPF neighbors. Or you might sometimes have a routing-switch-to-routing-switch link (or routing-switch-to-router link) that you consider to be untrusted (perhaps it passes through a service provider network). In both of these cases, you cannot make the interface a passive interface. You can use OSPF authentication in MD5 mode to add a degree of security to the communications.

When operating in MD5 mode, the OSPF interface hashes OSPF packet data and the key. It then places the hash at the end of the packet. The authentication field includes the key ID, a length for the hash, and a cryptographic sequence number; however, it does not include the key itself, protecting it from eavesdroppers. A router receiving the OSPF packet hashes the packet with its secret key, identified by the key ID. If the hash matches, the router knows that the transmitting router has the correct secret key for this key ID, so it accepts the packet.

Figure 6-25: Secure OSPF communications on transit interfaces

To set up OSPF authentication on an AOS-CX switch, set the key ID and key on the Layer 3 interface, as shown in Figure 6-25. Make sure to use exactly the same key ID and key on other routing switches or routers connected to this interface.

As discussed earlier, you might also be using a control plane ACL to filter communications to the AOS-CX switch control plane. In that case, the control plane ACL must include a rule permitting legitimate OSPF packets, and this rule can add another layer of security. However, you should not rely on the control plane ACL alone, as hackers can spoof legitimate IP addresses. You should use the control plane ACL in conjunction with OSPF authentication.

OSPF MD5 mode also includes a cryptographic sequence number. This number provides a degree of protection against replay attacks. An OSPF interface only accepts packets with a sequence number equal to or higher than the number for the most recent accepted OSPF packet from this neighbor. The sequence number might be a counter, but is usually based on the system clock. In either case, the number is always increasing. If a hacker obtains a legitimate OSPF packet and attempts to retransmit it later, the packet’s cryptographic sequence number is no longer valid, and the other routers on the network reject it. A hacker could replay a packet in the window before the legitimate neighbor sends a packet with a higher sequence, but this window is quite small.

MD5 authentication provides authenticity, but not privacy: the contents of the packet are not encrypted.

Note that AOS-CX switches also support OSPF authentication in simple mode, but this mode is not recommended because it transmits the password in plaintext.

Checklist of additional protections

You should ensure that you have followed a few more best practices on switches, which are summarized in Figure 6-26.

Figure 6-26: Checklist of additional protections

You should set the switch clock using Network Time Protocol (NTP), rather than manually. If the company has a private NTP server, you should use NTP authentication to further secure the communications. Ensuring that all network infrastructure devices have an accurate clock and take their time from a consistent source benefits security in many ways. It ensures that switches can properly validate certificates using the certificates’ validity periods. It makes logs easier to read and correlate across multiple devices. The logs must also have a valid time in order to be used for auditing or investigating security incidents. NTP also helps switches to implement replay protection with various protocols; only with an accurate clock can the switch accurately check packets’ timestamps and ensure that they are up-to-date.

AOS-CX switches also support control plane policing (CoPP). CoPP examines packets incoming to the switch control plane and rate limits them. This rate limiting protects against protocol floods, which could tie up the switch CPU and lock up the switch. The switch comes with many default policies for the specific rate limit to apply to each traffic class. For example, the switch has policies for STP BPDUs, ARP messages, and many others. You should generally accept the default policies. CoPP is enabled by default on the “default” VRF. If you create additional VRFs, you should enable CoPP on them.

AOS-CX switches use SFTP for transferring files. SFTP is a secure file transfer protocol, which uses authentication and encryption.

It is also best practice to enable sending logs to a central Syslog server for auditing and archival.

If you want more information about these features, you can refer to prerequisite training or Aruba manuals.

Summary

Congratulations! You have completed Chapter 6. You now know how to implement secure management of AOS-CX switches. You should have a firm grasp of DHCP protection on AOS-CX switches, as well as ARP inspection on AOS-CX switches.

Learning checks

What purpose does the “aaa authentication allow-fail-through” command serve on AOS-CX switches? It lets the switch authenticate users against the secondary method only if the primary method times out.

It lets the switch actively test whether a TACACS+ server is available.

It lets the switch allow users operator level access if their authentication fails.

It lets the switch authenticate users against the secondary method if the primary method rejects the user.

How does ARP inspection prevent MITM attacks? It discovers which IP and MAC addresses belong together.

It drops all ARP responses that arrive on untrusted ports.

It drops ARP responses on untrusted ports that do not match the IP-to-MAC table.

It stops clients from generating gratuitous ARP responses.

Note: For answers to all learning checks, refer to the Appendix.

7 Implement 802.1X and Role-Based Access Control on AOS-CX

EXAM OBJECTIVES

✓ Deploy AAA for wired devices using ClearPass Policy Manager (CPPM), including local and downloadable roles.

✓ Explain Dynamic Segmentation, including its benefits and use cases.

✓ Deploy Dynamic Segmentation using VLAN steering.

✓ Configure 802.1X authentication for APs.

Assumed knowledge

Authentication, Authorization, and Accounting (AAA) framework and basics of protocols such as RADIUS and TACACS+

Forms of Layer 2 authentication such as 802.1X, including common EAP methods such as PEAP and EAP-TLS

Basics of managing ArubaOS-CX (AOS-CX) switches

PKI and digital certificates

VLANs

Access control list (ACL) basics

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

802.1X for wired devices

Dynamic Segmentation allows you to optimize both internal security and employee performance. It lets you give each user the right level of access and to adjust that access as circumstances change. In this section, you will learn about laying the groundwork for Dynamic Segmentation by implementing 802.1X for wired devices.

Why 802.1X for wired clients

Dynamic Segmentation involves identifying each client as it connects to the network and then adjusting the point of access based on the client’s identity as well as other context-based information. To implement Dynamic Segmentation on wired clients, you must set up port-based authentication, which allows the switch to authenticate clients against an external authentication server and then grant that user a particular level of network access, based on the authentication server’s decisions.

Figure 7-1: Why 802.1X for wired clients

Just as 802.1X provides the most secure authentication option for wireless networks, it also provides the most secure option for port-based authentication. As shown in Figure 7-1, you can configure AOS-CX switches to use 802.1X to authenticate wired clients to CPPM, much as APs do. Then users on wired devices can authenticate with the same credentials and a similar process that they use for connecting to the wireless network. In this way, users have a consistent authentication experience no matter how they connect, and they also obtain a consistent experience on the network.

Review 802.1X setup on AOS-CX Switches

To implement 802.1X on an AOS-CX switch, you must specify the RADIUS server, and then follow the remaining steps shown in Figure 7-2.

Figure 7-2: Review 802.1X setup on AOS-CX Switches

If you are using CPPM, Aruba recommends that you specify the server by the hostname in CPPM’s HTTPS certificate. This practice will help the switch successfully download user-roles from CPPM if you decide to use that feature.

If you placed the RADIUS server in a non-default group, you must specify that RADIUS group as the one that you want to use for 802.1X.

Then, you must enable 802.1X on a per-interface basis. You must also enable 802.1X globally. For 802.1X to operate on a port, it must be enabled both on the port and globally.

Finally, best practice is to enable RADIUS accounting. You can select start-stop, in which case the switch sends a start accounting message to the RADIUS server when a session begins. Both start-stop and the stop-only options send a message when the session ends. Stop messages describe the user’s identity, location, and bandwidth consumption, as well as other information. You should also set up interim accounting messages so that the switch can periodically update CPPM.

CPPM 802.1X wired service

When a switch enforces 802.1X, it relies on a RADIUS server to make decisions about whether clients are allowed network access and what level of access they receive. For the purposes of this study guide, this RADIUS server is CPPM.

Service

As always, CPPM requires a service for processing the incoming RADIUS requests. A wired 802.1X service resembles a wireless 802.1X service in many ways. To create the service, you can create a service and select the 802.1X wired service template. Or you can use the 802.1X wired wizard, as shown in Figure 7-3. When you use either the template or the wizard, CPPM automatically creates service rules, which match 802.1X-related RADIUS requests from switches. Note that the value for the RADIUS NAS-Port-Type AVP is “Ethernet.” This value helps CPPM distinguish the wired 802.1X service from a wireless 802.1X service.

Figure 7-3: CPPM 802.1X wired service

Authentication

Choose authentication methods and sources following the same guidelines that you use for wireless 802.1X services. In this example, shown in Figure 7-4, you are using EAP-TEAP and EAP-TLS. The order of the authentication methods indicates the order in which CPPM suggests them; in this example, EAP-TEAP is preferred.

Figure 7-4: CPPM 802.1X wired service—authentication

You are also using the same AD instance as in the wireless service. When you select this AD instance as an authentication source, it is automatically set as an authorization source.

Remember to set up the rules for stripping usernames if users might enter their names with domain names or if certificates include domain names in the subject name.

Roles and enforcement

If you have already created a role mapping policy for an 802.1X wireless service, you will often use the same role mapping policy in the 802.1X wired service. Doing so ensures that clients receive a consistent ClearPass role regardless of whether they connect to the wireless or wired network.

Figure 7-5: CPPM 802.1X wired service—roles and enforcement

Sometimes you can even use the same enforcement policy for the 802.1X wired and 802.1X wireless services. This is the case when you are using local defined roles on switches, and you intend to use the same role names on switches as on the ArubaOS mobility devices. These policy configurations are shown on the left side of Figure 7-5.

Sometimes, though, the 802.1X wired service will need its own enforcement policy. This policy will typically follow a similar format to the enforcement policy used in the 802.1X wireless service, mapping ClearPass roles to enforcement profiles. However, the enforcement profiles will be specific to the CX switches. For example, you should take this approach when you want to use downloadable roles, which need to be specific to the network device software. You will learn more about defining enforcement profiles that work with CX switches later in this chapter.

Review AOS-CX roles and Dynamic Segmentation

Next, you will review AOS-CX roles and Dynamic Segmentation.

What are AOS-CX user-roles?

AOS-CX switches are designed to apply user-roles as part of the authentication process. An Aruba switch user-role, much like an ArubaOS mobility role, dictates how the network infrastructure device controls traffic from a client.

Figure 7-6: What are AOS-CX user-roles?

User-roles enable the switch to dynamically adapt how a port behaves based on the identity and context for the client that connects to the port. An example of this dynamic adaptation from connecting to a port is shown in Figure 7-6. Such a port is sometimes called a “colorless” port because it does not require admins to pre-define, or color, its settings. Similarly, such a port is sometimes called a “multi-use” port because admins can define the same settings on all edge ports and then connect any client type to any port. Admins and users can also move clients around. The port dynamically adapts to the client that is currently connected to it.

AOS-CX user-role benefits

The benefits of assigning “roles” to users and/or devices are well known within the Aruba wireless world. Aruba has simply adapted this approach for use with the wired switch port. Just as with Aruba mobility solutions, companies can now simplify the burden of configuration. They can group grouping policies into a “role,” which can be used for many clients on many network infrastructure devices. Additionally, when you use CPPM to manage the roles, you can add context (time of day, type of machine, device profiling) when deciding if the network will allow a user/device as well as what access rights it will grant or deny.

When you use downloadable user-roles (DURs), admins can centrally define the role settings, rather than have to define settings manually on all access switches across the network.

While Aruba recommends ClearPass for the highest levels of security, companies can use third-party RADIUS servers if they choose. In this case, only local user-roles (LURs) are supported.

Common settings defined in AOS-CX user-roles

The user-role controls a client’s access based on several settings.

The user-role dictates settings such as the VLAN for the client’s traffic (tagged or untagged). It also defines whether traffic is locally switched or tunneled back to an Aruba gateway or mobility controller (MC).

You can also apply ACLs or quality of service (QoS) settings to clients through a port access policy. You can also configure reauthentication timers, which dictate how often the client must reauthenticate.

You can also set up a captive portal redirect for a role that you want to use for guests or for onboarding clients.

You will learn how to use VLAN settings and port access policies in this chapter. You will learn how to use tunneling to a gateway in the next chapter.

Methods for creating user-roles

You can take two approaches for defining user-roles for clients on AOS-CX switches. These two approaches, using LURs or DURs, are shown in Figure 7-7.

Figure 7-7: Methods for creating user-roles

LURs

Admins must configure LURs on the switch in advance of clients connecting and being assigned to those user-roles.

When a user authenticates on the port, CPPM sends an Access-Accept with the client’s assigned user-role in an Aruba-User-Role VSA. The switch matches that VSA’s value to the LUR with the same name and applies the settings within.

DURs

With DURs, the switch does not need to have any user-roles configured on it in advance. Instead the user-role is defined on CPPM, and the switch downloads the user-role from CPPM on demand.

When a user authenticates on the port, CPPM sends an Access-Accept with the name of the assigned DUR in the Aruba-CPPM-Role VSA.

If the switch has not downloaded that DUR yet, it accesses CPPM with HTTPS and downloads the user-role from the server. It then applies the settings in that user-role to the client. Once a user-role is downloaded, it is saved in the switch’s cache, so if the same user-role is applied to another user, the switch does not have to download it again. The DUR is saved in the memory, not the configuration.

Some companies prefer to use DURs because they allow simpler, centralized configuration of user-roles. Once the user-roles are defined on CPPM, the company can easily add more switches, and the new switches will receive the user-role configuration dynamically.

Enabling DURs for AOS-CX switches

To support DURs, the AOS-CX switch must meet a few key requirements. Make sure that the switch is correctly set up to specify CPPM as its RADIUS server.

This switch also needs the root certificate authority (CA) certificate for CPPM’s HTTPS certificate installed in a TA profile. The switch uses this root CA certificate to validate CPPM’s HTTPS certificate when it establishes a connection to CPPM. Without the certificate, the switch will abort the HTTPS connection and fail to download any user-roles.

To validate that the certificate has not expired, the switch also needs to have a correct clock. You learned about enabling Network Time Protocol (NTP) for this purpose earlier in this study guide.

The switch also needs the username and password for an account on CPPM.

You will now go over each of these requirements in more detail.

Ensuring the RADIUS server host value is correct

Typically, when you define the RADIUS server on an AOS-CX switch, you can specify an IP address or hostname, and either can work. It can be a good idea to use a hostname to future proof against changes to the IP address, but an IP address does work.

However, when you are using DURs, the switch checks the precise value that you specify for the RADIUS server host against the common name (CN) in the HTTPS certificate’s subject name. This CN should be a fully qualified domain name (FQDN). Therefore, you must make sure to define a DNS server on the switch. Then it can resolve the hostname that you specify as the RADIUS server.

Figure 7-8: Ensuring the RADIUS server host value is correct

You must make sure that you specify exactly that same FQDN for the RADIUS server host name on the switch, including the domain name. In Figure 7-8, you see how you can view the HTTPS server certificate on a ClearPass server at the Administration > Certificates > Certificate Store page. Make sure that you select the HTTPS usage. Then find the CN. You can also match to a DNS SAN within the HTTPS server certificate.

Also take note of the root CA certificate for this certificate. In this example, the certificate was signed by an intermediate CA. That CA’s certificate was signed by a root CA certificate. It is the root CA certificate that you will want to upload on the AOS-CX switch.

Installing the CA certificate in the TA profile

To validate the CPPM HTTPS certificate, the switch also checks the certificate signature. This means that you must install the root CA certificate for this certificate on the switch. Obtain this certificate in Base64 format. Then create a TA profile on the switch and import the certificate into that profile. As you learned earlier, you can import from the terminal by copying the Base64 formatted text into the CLI. Or you can import with SFTP.

Figure 7-9: Installing the CA certificate in the TA profile

The example in Figure 7-9 shows importing the certificate using the terminal. You copy the Base64 text directly into the terminal. As you see, each line will copy in separately. This is okay. After you see the ---END CERTIFICATE---line, press [Ctrl+D].

You will see information about the certificate and be prompted to accept it. Do so.

Also make sure to exit out of the profile to save the root CA certificate. The certificate will only be saved when you do so.

Note that you only need to install the root CA certificate, not the intermediate CA certificate.

CPPM user account for downloading user-roles

Because the switch must log into CPPM and download the DUR, it needs credentials for authenticating to CPPM. In Figure 7-10, you see the command for configuring the username and password for a ClearPass server on an AOS-CX switch.

Figure 7-10: Figure 7-10: CPPM user account for downloading user-roles

You must also set up a matching account on CPPM.

Log into CPPM and navigate to Administrator > Users and Privileges > Admin Users. Click the plus icon to create a new account.

Give the user any User ID and password that you desire, making sure, of course, to match the credentials configured on the AOS-CX switches. Note that the password shown in Figure 7-10 is for simplicity while in the real world you should follow best practices for using long, random, complex passwords that are not based on dictionary words.

Give the account the Privilege Level of Aruba User Role Download.

Click Save.

Creating Downloadable Enforcement Profiles on CPPM

With the prerequisites for switches to download the user-roles in place, you can create the DURs themselves on CPPM. You do so by creating Downloadable Enforcement Profiles as shown in Figure 7-11.

Figure 7-11: Creating Downloadable Enforcement Profiles on CPPM

In CPPM, go to Configuration > Enforcement > Profiles and then click Add Enforcement Profile. Create a RADIUS profile.

Under the Profile tab, set the Template to Aruba Downloadable Role Enforcement and the Action to Accept.

Under Product, choose AOS-CX Switch. You will then see options for specific AOS-CX user-role settings such as VLAN assignment, UBT settings, and reauth interval. These settings are the practical elements that define users’ access level. The next topics will explain which settings to choose for various use cases when constructing these user-roles.

More details on how clients are assigned a user-role

Now that you know how to ensure that user-roles are in place, you will look at how clients receive the user-role assignment.

Pre-authentication

When you enable 802.1X or Mac-Auth on a port, the switch attempts to authenticate all clients that connect on the port. When the client first connects, before authentication occurs, one of two situations occurs.

Figure 7-12: User-role assignmentßžpre-authentication

As shown in Figure 7-12, if no pre-auth role is defined on the port (the default setting), access is blocked until the client completes L2 authentication.

If you have defined a pre-auth role, the port applies that role to the client. A pre-auth role always references LURs, rather than DURs. For example, you could define a LUR named “onboard.”

Authentication timeout

After about two minutes (in default settings), if the client does not attempt to authenticate, authentication times out. Note that this is different from the client attempting to authenticate, the switch sending an Access-Request to the RADIUS server, and the RADIUS server never responding. In this case, the client never attempts to authenticate.

Figure 7-13: User-role assignmentßžauthentication timeout

When client authentication times out, as shown in Figure 7-13, the AOS-CX switch checks whether the port has a port fallback role assigned to it. This role is always a LUR. If the fallback role is specified, the switch applies the indicated LUR to the client. You might apply this role when you want to accommodate devices that need to be onboarded.

If no fallback role is specified for the port, the switch simply continues to block access after authentication times out.

Note that the fallback role was added in AOS-CX 10.05. Prior to that version if authentication times out, the pre-auth role continues to apply. Or if no pre-auth role exists, the client is blocked from access.

Post-authentication

You will now examine what happens when a client connects and succeeds in authenticating, as shown in Figure 7-14.

Figure 7-14: User-role assignment—post-authentication

First, the switch attempts to apply a user-role communicated by the RADIUS server in an Access-Accept VSA. This VSA could be an Aruba-User-Role VSA, which must have a value that matches a LUR already configured on the switch. Or it could be a CPPM-User-Role VSA, which triggers the switch to attempt to download a DUR.

If the VSA is not present, the switch moves on to trying the next type of user-role. Similarly, if the Aruba-User-Role value does not match with a LUR, or the switch cannot download the DUR, the switch moves on. Next the switch attempts to apply the auth role defined on the port. This user-role always matches a LUR defined on the switch.

If no valid VSA is sent to define the user-role, and the port does not have an auth role defined on it (the default setting), the client is allowed to connect without a user-role. The switch simply applies the settings defined on the port to the client connection.

Best practice is to have the RADIUS server, such as CPPM, define the user-role. As a failsafe, define a user-role that denies access or permits minimal access as the port’s auth role.

Authentication failure

You will now consider a situation in which the client attempts to authenticate and fails.

Figure 7-15: User-role assignmentßžauthentication failure

As shown in Figure 7-15, the authentication could fail because the server sends an Access-Reject. In that case, the switch checks whether a reject role is defined on port. If it is, the switch applies that role, which always corresponds with a LUR. If this type of role is not defined, the switch checks whether a port fallback role is specified. If it is, the switch applies that role. Otherwise, the switch blocks access.

The authentication could also fail because the switch cannot reach the RADIUS server. The switch would then check whether a critical role is defined on the port. If so, it applies that role. This role is intended to provide access in case of an outage on the RADIUS server or a disruption in connectivity. It should typically provide minimal access only to services that can never be down. As with all roles defined on the port, the role references a LUR. If no critical role is defined on the port, the switch again checks for a port fallback role. If that role is defined, the switch applies the specified LUR. Otherwise, the switch blocks the client’s access.

Client vs device auth-mode

By default, AOS-CX switches implement port-access in client auth-mode. In client auth-mode, the switch tracks all MAC addresses on the port and enforces 802.1X for each separately. The switch can apply a different role to each client. You can also configure a limit for the number of clients permitted on a port.

Alternatively, a port can operate in device auth-mode. In this mode, the switch implements authentication on the first client that connects to the port. As soon as that client authenticates, the port is open for all clients connected behind the port, and the port uses the role applied to the first client.

Figure 7-16: Client vs device auth-mode

Both modes are shown in Figure 7-16. The auth-mode is configured on the port. However, you can also configure an auth-mode in a role, and that auth-mode overrides the port auth-mode.

Generally, you should leave all ports operating in client auth-mode. This mode ensures that only authorized clients connect to the port. Or if the port connects to multiple clients, such as a phone and computer, each client receives its own role and access level. However, if you are implementing 802.1X on ports that connect to APs, you should use port mode so that the switch does not try to authenticate wireless clients again. You can specify port mode in the AP role to dynamically apply that mode when necessary. You will learn more about implementing 802.1X to authenticate APs later in this chapter.

Consideration questions

You will now review how users are assigned a role in a scenario.

Consider an example customer: Aruba Bank, which has a corporate headquarters and multiple branch offices. The bank’s network is built on Aruba APs and switches, and the bank uses Aruba ClearPass Policy Manager (CPPM) to authenticate users on the wireless network. Now the bank wants to add 802.1X to wired ports to bolster the security of that infrastructure, while still ensuring that users on wired clients have the appropriate access level.

You have been asked to set up the port role settings on AOS-CX switches. The bank security team has given you these instructions.

Authenticated clients should receive their role assignment from CPPM, and the switch should also download the role configuration from CPPM. But if CPPM fails to send a valid role, the authenticated client should be given the “guest” role. The clients should also receive the “guest” role if the RADIUS server is unavailable. Clients that do not try to authenticate should receive a role called “unauthenticated.” Clients that fail authentication should be denied access entirely.

How will CPPM assign roles to users that successfully authenticate? How should you configure switch ports to apply the “guest” and “unauthenticated” roles? Finally, which roles need to be configured locally on the switches?

Methods for handling wired client traffic

Once the switch has assigned a client to a role, the switch has three broad ways to handle that client’s traffic, based on the role settings.

Local forwarding

User-based tunneling (UBT)

Virtual network-based tunneling (VNT)

Local forwarding

Figure 7-17: Local forwarding

The switch can use local forwarding, as shown in Figure 7-17. In this case, the role assigns the user to a VLAN (this is sometimes called VLAN steering), and switches direct the traffic toward its destination locally. The switch can also apply other settings, like a port access class, which filters traffic based on IP header.

Local forwarding often works well for companies who want to start implementing authentication, but retain their current VLAN and access control list (ACL) structure. The company might choose to use local forwarding for typical employees, whose traffic does not necessitate additional security measures. IP-based filtering policies are sufficient.

It is also typical to forward AP traffic locally. The AP itself might bridge wireless client traffic or tunnel that traffic to a gateway, but once the traffic reaches the switch, the switch should forward the traffic locally. (It does not make sense, for example, for the switch to tunnel already tunneled traffic.)

User-based tunneling (UBT)

Alternatively, the role can specify user-based tunneling (UBT). In this case, the role indicates a gateway profile, and the switch uses GRE to tunnel the traffic to an Aruba gateway (AOS 10) or Aruba Mobility Controller (AOS 8). The gateway or MC then applies security policies and forwards the traffic. The switch can also tunnel traffic to a gateway cluster or MC cluster for high availability.

You might want to use this method when you need to apply extra security with application-based policies that draw on deep packet inspection (DPI) and Web Content Control (WebCC) policies.

Figure 7-18: User-based tunneling (UBT)

This approach, which can be seen in Figure 7-18, also makes it easier to apply consistent security policies to wireless users and wired users. For example, a gateway might be handling traffic for employees that connect on both wireless and wired connections. You can define a wireless_employees role and a wired_employees role and assign the same firewall policies to both roles.

Some companies also like the fact that the UBT approach centralizes traffic distribution. Then admins do not need to worry about where they extend particular VLANs. Instead they know that client traffic is always tunneled to a central location, where gateways reside, and the required VLANs only need to exist there.

Virtual network-based tunneling (VNBT)

Finally, you can use virtual network based tunneling (VNBT). With VNBT the switch uses Virtual Extensible LAN (VXLAN) to tunnel the client’s traffic to another VXLAN endpoint—typically an AOS-CX switch in the data center, as shown in Figure 7-19. In this case, the role settings are similar to those used for local forwarding—they include a VLAN assignment and can include other settings like a port access class. However, the VLAN to which the user is assigned has VXLAN enabled on it.

Figure 7-19: Virtual network-based tunneling (VNBT)

VNBT is useful when you want to centralize traffic distribution without using Aruba gateways. Your main goal might be to assign clients to VLANs without regard to the underlying physical infrastructure. However, you do not care about receiving access to additional security features provided by Aruba gateways for this particular client group. In this case, it is more cost effective to tunnel the traffic to another AOS-CX switch.

You might also use VNBT if you want to send clients’ traffic through a third-party security solution in the data center.

Note that the role settings have no relationship to how the role is applied, as a LUR or a DUR. In other words, a DUR could apply local forwarding, UBT, or VNBT, just as a LUR could specify any of these forwarding types.

Implementing local forwarding with VLAN steering

You will now take a look at implementing local forwarding with VLAN steering.

Overview

In previous chapters, you learned how Aruba Bank can use Aruba ClearPass and Aruba mobility devices to authenticate employees who connect to the wireless network and control their access using role-based policies. Now the bank wants to similarly authenticate and apply role-based access controls to employees on wired connections.

Figure 7-20: Overview

Currently the company uses VLANs to divide wired clients into different logical segments, as shown in Figure 7-20. A core routing switch then applies ACLs to the VLANs. IT has to manually specify the correct VLAN when setting up users’ workstations or the connections for other wired devices like cameras. However, this approach is a management hassle. In addition, the bank is now letting some employees divide their time between the bank and their home offices, which means that some employees are now sharing a workspace. The company needs a way to ensure that each user and device is placed in the correct VLAN without IT intervention.

You will set up roles that use VLAN steering for this purpose. A teller could connect to a port one day, and the teller’s computer is placed in the Tellers VLAN. The next day a loan officer could connect to the same port, and that user’s computer is placed in the LoanOfficers VLAN. Employees can move security cameras where required, and they always receive the correct VLAN assignment too.

Best practices for assigning role-based VLANs

You will now review best practices for assigning role-based VLANs.

ID versus Name

In order to apply a role that specifies a VLAN, the switch must already have a matching VLAN configured on it. If a role specifies a VLAN that does not exist on the switch, the application of the role will fail, and the client will not be able to connect.

The match can be by ID or by name.

Figure 7-21: Best practices for assigning role-based VLANsßžID or name

Using the VLAN name in the role can provide easier management and greater scalability. Different areas of the network do not always support the same VLAN IDs. In the example in Figure 7-21, the VLAN ID for the LoanOfficers group at headquarters does not match the VLAN ID for the LoanOfficers group at a branch. But if IT uses VLAN names in their roles, then the same VLAN name will work in each location, and a single user-role configuration will have the same effect across the entire network, regardless of which particular VLAN ID a switch associates with the VLAN name.

Keep in mind that the VLAN name is derived from the VLAN ID, by default. If you want to use this approach in roles, switch admins and ClearPass admins must coordinate and assign the correct name to each VLAN.

Note that support for applying a VLAN by name in a user-role was added in 10.06. If your switches have earlier software, you must use the ID method.

Access VLANs and Trunk VLANs

When setting up the VLAN for a role, you also need to understand whether clients will send untagged or tagged traffic.

VLAN assignments for untagged traffic

Most endpoints send untagged traffic, including most PCs, printers, POS devices, security cameras, and wired IoT devices. When setting up a role for these clients, specify the desired VLAN with the “VLAN Access” setting as shown in Figure 7-22.

Figure 7-22: Best practices for assigning role-based VLANsßžuntagged and tagged traffic

When the switch port operates in client mode, and a client is assigned to a role, the switch does not actually change the port access VLAN. Instead the switch creates a MAC-based VLAN (MBV) for the port. An MBV specifies a VLAN that applies to untagged traffic from specific MAC addresses—in this case, the MAC addresses of clients assigned to the MBV by role. This approach lets multiple clients connect to the same port, but be assigned to different role-based VLANs. (However, in most cases, only one client connects to the port.)

The port access VLAN applies to untagged traffic from any clients assigned to roles that do not specify a “VLAN Access” or “VLAN Trunk Native” setting. Typically, you should ensure that all roles specify a VLAN setting. (Roles that implement tunneling can be an exception, as you will learn later.) As a failsafe, you can place the port itself in a deadend VLAN, which is not carried on other ports.

VLAN assignments for tagged traffic

Occasionally, clients will need to send tagged traffic. This scenario might occur when a computer and VoIP phone are daisy chained to a single port. The computer sends untagged traffic, and the VoIP phone sends tagged traffic.

In this case, you should continue to set up roles for users with “VLAN Access” settings. The switch port will create MBVs for clients in those roles, as you just learned.

For the VoIP role, specify a “VLAN Trunk Allowed” setting. When the switch applies a role with a “VLAN Trunk Allowed” setting, it begins accepting traffic tagged with the indicated VLAN ID, or with the ID associated with the indicated VLAN name, from clients with that role.

The switch can apply the “VLAN Trunk Allowed” setting even though the port is statically configured as an access port. This behavior simplifies configuration; admins do not need to know in advance which edge ports will need to accommodate clients that send tagged traffic.

With the settings shown in Figure 7-22, if the VoIP phone happened to send any untagged traffic, that traffic would be assigned to the port access VLAN. If you do not want that behavior, you can add an additional VLAN setting to the VoIP role: “VLAN Access” or “VLAN Trunk Native.”

VLAN steering roles

Now that you understand the VLAN settings, you can specify them within an AOS-CX switch local role or within a downloadable enforcement profile.

LURs

The first step for establishing VLAN steering is always to create the VLANs to which you want to assign clients. In the example shown in Figure 7-23, you create two VLANs, one for “LoanOfficers” and one for “Tellers.”

Figure 7-23: VLAN steering rolesßžLURs

Rather than assign ports to the VLANs as you would do traditionally, you create two roles for your two types of clients. You then specify the vlan access name within the role. Now when a client is assigned to this role, the switch will assign the client’s traffic to the role dynamically.

DUR—Aruba Downloadable Role Enforcement profile with standard configuration

When you are using DURs, then define the user-role, including its VLAN settings, within an enforcement profile on CPPM as shown in Figure 7-24.

Figure 7-24: VLAN steering roles—DUR and Aruba Downloadable Role Enforcement profile (standard configuration)

As you learned earlier, you set the profile template to Aruba Downloadable Role Enforcement. You then have two choices for the Role Configuration Mode, Standard and Advanced. Choose Standard to select options from set fields. In CPPM v6.9, you can use Standard to define the VLAN by ID, but not by name. In that version, standard configuration also allows you to specify only one VLAN ID for the VLAN Trunk Allowed setting. (However, in v6.10 and above, CPPM provides fields for specifying VLAN names and also permits specifying more than one VLAN for the VLAN Trunk Allowed setting.)

After choosing Standard, click the Role Configuration tab. You can then fill out the VLAN settings, as well as other settings, using fields presented by the interface.

DUR—Aruba Downloadable Enforcement Profile with advanced configuration

Choose Advanced for the Role Configuration Mode if you want complete flexibility in configuring any settings that are supported on your local switch. In CPPM v6.9, use Advanced mode to specify VLANs by name or to allow multiple trunk VLANs.

Figure 7-25: VLAN steering rolesßžDUR and Aruba Downloadable Role Enforcement profile

To configure the role for Advanced mode, click the Attributes tab. As shown in Figure 7-25, you will see the Aruba-CPPM-Role attribute. For the attribute value, simply enter the same CLI commands that you would use to configure a role on an AOS-CX switch.

Adding port-access policies

This section explores adding port-access policies, which are role-based ACLs, to the solution.

Approaches for applying ACLs to wired devices

Dividing wired clients into different VLANs provides a first step toward segmenting their traffic. However, if you want to truly assign different rights to different users, you must add ACLs to enforce those rights. AOS-CX switches support MAC and IP ACLs, which consist of rules that filter traffic based on its MAC or IP header.

You can take two general approaches for using switch-based ACLs to boost security.

You can assign users to different VLANs based on role, and then configure a core routing switch to apply ACLs as the traffic is routed from one VLAN to another VLAN.

Alternatively, you can continue to assign users to different VLANs based on role, but configure each access layer switch to apply ACLs to all traffic incoming on edge ports. You can use roles to apply the ACLs so that the port enforces a different set of rules for each client, based on that client’s role. In this case, the ACLs are IP ACLs. You can see both approaches in Figure 7-26.

Figure 7-26: Approaches for applying ACLs to wired devices

While both approaches add another layer of security beyond VLAN steering, the second approach has some additional advantages. By using ACLs on access layer switches, traffic is filtered immediately, rather than passing through the network before reaching a core switch. Similarly, traffic destined to another device within the VLAN, as well as traffic that will be routed to another VLAN, is filtered.

Many companies prefer a centralized approach to configuring ACLs to simplify setup and ensure consistency. However, with DURs you can apply ACLs at the edge port while also centralizing configuration.

Implementing role-based port access policies

As shown in Figure 7-27, to implement a role-based ACL on a port, you reference the name of a port access policy as a policy within the role.

Figure 7-27: Implementing role-based port access policies

When a client is assigned to that role, the switch will use the rules defined within the port access policy to filter all ingress traffic from the client.

Sources for port access policies

An AOS-CX switch can have a port access policy defined on it in three ways. Each of the three ways is shown in Figure 7-28.

Figure 7-28: Sources for port access policies

You can configure the port access policies locally on the switch. As you will see in more detail later, port access policies reference classes. When you use local configuration, you must configure these classes manually on the switch as well.

Alternatively, if CPPM is applying DURs, the Aruba Downloadable Role enforcement profile can also include the port access policy and class configuration. The switch will dynamically download the classes and port-access policy as well as the role configuration.

The switch can also receive rules sent in RADIUS attribute value pairs (AVPs). AOS-CX switches support the standard RADIUS NAS-Filter-Rule AVP or the Aruba-NAS-Filter-Rule VSA. You might use this option when you want to centralize the policy configuration, but you have a third-party RADIUS server. However, this last option is not the focus of this study guide.

Port access policy components

To implement a port access policy, you must first create IPv4 or IPv6 classes. Each class selects one or more types of traffic. You then reference those classes within the port-access policy and specify how you want to treat the traffic.

Figure 7-29: Port access policy components

For example, you might want to enforce a simple policy that permits most traffic but prohibits a few applications and destinations. You could create an IP class named “prohibited” for selecting the traffic to drop. In the example shown in Figure 7-29, prohibited traffic includes SSH traffic and traffic to a sensitive subnet in the data center. However, you can define whatever traffic you want to prohibit based on your organization’s policies.

Then you could create an IP class name “allowall,” which selects all traffic.

Then you could specify in a port-access policy that you want to drop IP class “prohibited” but permit IP class “allowall.”

Configuring classes locally

Whether you create a policy locally or in a CPPM downloadable role, the syntax for the setup is the same. You first use commands to create IPv4 or IPv6 classes, which select traffic based on criteria within the IP header. You can see the syntax for IPv4 in Figure 7-30, and the IPv6 syntax is very similar.

Figure 7-30: Configuring classes locally

First specify this command: class ip . You can then enter a sequence of rules.

A sequence number at the beginning of the rule is optional. As with access lists on ArubaOS devices, the rule order matters, so specifying a sequence number helps you to control where the rule is placed in the list. If you do not specify a sequence number, the switch automatically assigns the rule to the highest place in the list, rounding up to a divisible of 10.

You next specify the action: match or ignore. The match action means that the class selects the specified traffic as part of the class. What you do with the traffic, whether drop, permit, or rate limit it depends on the action you apply to the class as a whole in a policy.

Next you specify the protocol, which is an IP protocol such as tcp or udp. If you specify ip, then the rule applies to all IP traffic that meets the rest of the rule’s criteria.

You then specify the source, which can be any or an IP address. You can specify a range of IP addresses using a prefix length or subnet mask.

Next you specify the destination, which follows the same format as the source.

If you specified tcp or udp for the protocol, you can specify a destination port, which helps to specify the particular application such as SSH or HTTPS. You begin with a keyword such as eq to specify an exact port or range to specify a range of ports.

You can then specify a number of extra options such as vlan to specify the VLAN to which the traffic must belong. You can refer to the switch documentation for more details.

10 ignore ip any 10.101.10.0/24

This IP class now ignores IP traffic coming from any source destined for 10.101.10.0/24.

If, in the same context, you enter 20 match tcp any eq 443, then the class will also match TCP traffic from any source going to any destination on port 443 (for HTTPS).

If you enter 30 match tcp any 10.101.20.0/24 range 50000, then the switch will further use this class to identify TCP traffic from any source, destined for 10.101.10.12/24 on an SSH port.

Configuring port access policies locally

Once you have created classes for the traffic you want to control, you can create a policy, which assigns actions to each class. In the config context, you enter port-access policy followed by the policy name.

Figure 7-31: Configuring port access policies locally

Then you create a series of rules for the classes. Begin with an optional sequence number, followed by class {ip | ipv6} and the class name.

If you want to permit the class with no rate limit or change in priority, you simply end the command there, as shown in rule 20 in Figure 7-31.

If you want to deny the class, enter action drop, as shown in rule 10. The redirect action sends all traffic of a class to a captive portal server. Or you can apply a police action, which rate limits the traffic. After action, enter cir kbps followed by the rate in kilobits per second you want to enforce.

It is important that you understand that the switch processes packets against each rule in order. If the packet matches the class in the rule, the switch applies the specified action. Otherwise, it processes the next rule. If the switch reaches the end of the policy without finding a match for the packet, the switch drops the packet based on an implicit deny.

You can also apply actions that are more related to QoS than to security, applying a remark action to change the traffic’s priority.

Defining classes in an Aruba downloadable role on CPPM

If you are using DURs, you define the classes directly within an Aruba Downloadable Role enforcement profile. Add a new enforcement profile of this type and configure the other settings as you learned how to do previously. Or edit an existing profile.

Then click Manage Classes.

You will see the Class Configuration window. Choose a name for the class and set its type to IPv4 or IPv6.

You can then add one or more rules. You define the rules in the Rule Configuration tab. As you see in Figure 7-32, the fields available for the rule resemble the options that you can configure in a locally defined class. If you do not want to select traffic based on a particular type of criteria, leave that field blank or set to “any.” The example shown in Figure 7-32 selects all SSH traffic.

Figure 7-32: Defining classes in an Aruba downloadable role on CPPM

After you have added the desired rules, you can save the class. The class is now available for use in a port access policy in this enforcement profile or in other Aruba Downloadable Role enforcement profiles.

Defining port access policies in an Aruba downloadable role on CPPM

You can also define port access policies directly within the Aruba Downloadable Role enforcement profile.

Figure 7-33: Defining port access policies in an Aruba downloadable role on CPPM

Click Add Policy. Then use the windows presented by CPPM, as shown in Figure 7-33, to configure the policy. You will name the policy. You can then add a rule by either selecting Add Rule or click the Rule Configuration tab. For each rule, choose a class and define an action for it.

When you have finished configuring the policy, click Save Policy.

You can then choose the policy in the Policy drop-down menu for this enforcement profile. The policy will also be available for selection in other Aruba Downloadable Role enforcement profiles.

802.1X authentication of APs

ZTS calls for implementing 802.1X on all edge ports, including ones that connect to APs. In this final topic, you will learn how to authenticate Aruba APs with 802.1X. You will look at the setup on the APs, as well as on the AOS-CX switches and CPPM.

Why authenticate APs with 802.1X

It is best practice to implement 802.1X on all switch edge ports, including ones that connect to APs, particularly when the APs are connected in locations accessible to users. As shown in Figure 7-34, enforcing 802.1X prevents hackers from disconnecting an AP and connecting their own device to the switch port intended for the AP. This port could provide hackers with a backdoor into the network, which they might be able to leverage into access to other systems. By implementing 802.1X, you stop the hacker immediately at the port.

Figure 7-34: Why authenticate APs with 802.1X

You can also use the authentication process to assign the AP to a role and apply the appropriate settings for the port dynamically. This process can simplify setup on the access switch, as admins no longer need to plan which ports will connect to APs in advance. Using DURs, they can also control those settings centrally. (Device profiles offer another way to dynamically apply the appropriate settings for the switch port that connects to an AP. However, device profiles are not covered in this study guide.)

Configuring 802.1X on Aruba AP uplinks

With the certificates in place, you can enable 802.1X on the APs’ uplink. The settings are similar for the Instant UI or in a Central group that contains APs. However, in the Instant UI you find the uplink settings by selecting System in the left menu and clicking Show Advanced. In Central, you go to a group’s Devices > Access Point tab and then select the Config option in the upper left corner. You then activate advanced settings and click the Interfaces tab.

Figure 7-35: Configuring 802.1X on Aruba AP uplinks

In either case, under Uplinks, expand the AP1X section as shown in Figure 7-35. Now, you have two choices for the AP1X Type: PEAP or TLS (EAP-TLS). You must match the method configured on CPPM. EAP-TLS is recommended. When you select TLS, you must further select the certificate that the AP uses to authenticate. You can choose between the User certificate, which is a CA-signed certificate that you must load on the APs, or the factory-installed TPM certificates. Note that for APs managed by Central to support TLS, the APs must run AOS 10.3 and Central must be at version 2.5.4.

On APs managed by MCs, you can also specify a domain name, which the APs append to the hostname that they submit as their username.

When you configure APs managed by Central, you can select the Validate Server check box. The IAP then validates the certificate submitted by the RADIUS server. You must make sure to configure the IAPs with CPPM’s RADIUS/EAP certificate as a Trusted CA for 802.1X. Finally, save the settings.

Example AOS-CX roles for APs

You need to set up roles to which APs will be assigned after the complete authentication. An example of these roles is shown in Figure 7-36.

Figure 7-36: Example AOS-CX roles for APs

The role should implement local forwarding. It should further assign the AP's traffic to the correct VLANs. If the AP is tunneling all client traffic to a gateway or MC, you only need to assign the role to the VLAN which the AP uses to communicate with the gateway or MC and tunnel the traffic. But if the AP is bridging client traffic, it often bridges traffic into one or more tagged VLANs. You need to configure the bridging APs' native VLAN, on which it sends untagged traffic as well as the tagged VLANs in which it forwards user traffic. Remember that you configure the tagged VLANs with the vlan trunk allowed command. You must also configure the bridging APs' role to set the port in device-mode. This mode prevents the switch from attempting to authenticate the client MAC addresses that it sees the AP bridging on the port.

For both types of APs, you can assign settings that give the AP privileges suited to its role. You can set the port PoE priority to critical, which gives the port priority for delivering PoE power if the switch’s power is oversubscribed. You can also configure the switch to trust DSCP, which are quality of service (QoS) marks within IP headers. APs can set the DSCP for IP traffic to indicate its priority.

And you can specify other supporting settings such as a session timeout.

As always you can configure the roles locally on switches or centrally on CPPM using DURs. If you use DURs, you can set the configuration mode to advanced and use exactly the same syntax that you would for a LUR.

Service rules for an example CPPM service

You will now look at an example service which CPPM can use to authenticate the APs. In the example shown in Figure 7-37, the APs are authenticating with their TPM certificates, but you could take a similar approach to configure CPPM to authenticate APs using CA-signed user certificates. Keep in mind this service is only one example; you can adjust some of these settings based on companies’ particular requirements.

Figure 7-37: Service rules for an example CPPM service

Generally you want to create a dedicated service for authenticating the APs. Then you can configure settings that are appropriate for authenticating APs, but might not be appropriate for corporate users.

To distinguish between RADIUS requests related to authenticating APs and requests related to authenticating clients, you can add another rule to the standard Wired 802.1X rules. Remember that you can configure APs to append a domain name to their username. This rule looks for a username that ends with the domain name you configured. In this example, that is “aps.example.com,” which is designed to be different from the domain name used by normal clients.

Authentication settings for an example CPPM service

For the authentication settings in this example, you add a custom EAP-TLS method as shown in Figure 7-38. In this method you disable authorization because your typical authentication sources, such as an AD instance, do not have accounts for the APs. You also disable OCSP because the TPM certificates do not provide OCSP.

Figure 7-38: Authentication settings for an example CPPM service

Because you disabled authorization, CPPM does not check the APs' usernames against an authentication source. It simply verifies that the certificates are signed by a trusted CA, which has the EAP usage. However, you must specify an authentication source. You can specify any source as a placeholder. However, keep in mind that the authentication source will also become an authorization source, which you can reference in your enforcement policy rules. For this example service, you will use the Endpoint Repository.

Enforcement settings for an example CPPM service

In this example shown in Figure 7-39, you have created an enforcement policy that only assigns an enforcement profile if the client passes two checks.

Figure 7-39: Enforcement settings for an example CPPM service

First, the client’s certificate must have been issued by an Aruba CA. This check ensures that the client is using an Aruba device (TPM) certificate and not a certificate signed by a different CA that CPPM also trusts for EAP.

Second, the client must have a known status in the Endpoints Repository. As you will learn in more detail later, CPPM can discover all the devices in the network and add them to its Endpoint Repository. However, the devices start with an unknown status. In this scenario, admins initially connect APs to ports that do not enforce 802.1X. They have a list of the authorized APs’ MAC addresses, and they mark those devices as known. After that they set up 802.1X on the AP ports. CPPM detects whether the client is known in the Endpoint Repository and only applies the enforcement profile if it is. This check prevents users or hackers from connecting unauthorized APs that have a valid Aruba Device Certificate.

Clients that do not match both of these conditions are denied.

CA trust list

CPPM checks the APs’ certificate during authentication. Remember to install the corresponding root CA certificate and set its usage to EAP, as shown in Figure 7-40. When the APs are using their TPM certificates, you must enable the Aruba Networks Trusted Computing Root CA, which installed on CPPM by default. You can quickly identify this certificate in CPPM's Certificate Trust List because it has the default usage of Aruba Infrastructure. You must enable the CA and add the EAP usage.

Figure 7-40: CA trust list

If a different CA signs your APs’ certificates, you would simply install that root CA certificate and similarly set its usage.

Summary

Congratulations! You have completed Chapter 7. You should now understand how to implement 802.1X for wired clients. You should have a renewed grasp of AOS-CX roles and Dynamic Segmentation. You should be knowledgeable about implementing local forwarding with VLAN steering and role-based ACLs, as well as enforcing 802.1X on ports that connect to Aruba APs.

Learning checks

CPPM already acts as the authentication server for wireless 802.1X. Now the company wants to add wired 802.1X. Which CPPM components does Aruba generally recommend should be the same for wired and wireless 802.1X? (More than one answer might be correct.) Service

Authentication source

Role mapping policy

Enforcement policy

How does a switch receive the configuration for a DUR? CPPM uses SSH to log into the switch and configure the DUR on it.

The switch uses HTTPS to retrieve the role configuration from CPPM.

Admins configure the DUR settings on the switch, and CPPM directs the switch which DUR to apply.

The switch uses SSH to contact an Aruba gateway and receive the DUR from it.

What is the significance of the following syntax on an AOS-CX switch? AOS-CX(config)# class ip NEW-CLASS

AOS-CX(config-class-ip)# 10 match tcp any 10.101.12.0/24 eq ssh

The switch will drop all traffic from any IP address destined for an address in 10.101.12.0/24

The switch now has a class that matches all SSH traffic from devices within 10.101.12.0/24

The switch now will permit all IP traffic destined for SSH ports on 10.101.12/24

The switch now has a class that matches all SSH traffic destined to addresses in 10.101.12.0/24

Note: For answers to all learning checks, refer to the Appendix.

8

Implement Dynamic Segmentation on

AOS-CX Switches

EXAM OBJECTIVES

✓ Explain Dynamic Segmentation, including its benefits and use cases.

✓ Deploy Dynamic Segmentation, including: – User-based tunneling (UBT)

– Virtual network-based tunneling (VNBT)

Assumed knowledge

Authentication, Authorization, and Accounting (AAA) framework and basics of protocols such as RADIUS and TACACS+

Forms of Layer 2 authentication such as 802.1X, including common EAP methods such as PEAP and EAP-TLS

Basics of managing ArubaOS-CX (AOS-CX) switches

AOS-CX user-roles

PKI and digital certificates

VLANs

IP address and routing fundamentals

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

Implementing UBT on AOS-CX switches

When you implement Dynamic Segmentation with tunneling, you have even more power to segment and control clients. You can direct the traffic to the correct destination, which then applies powerful access control policies.

In this chapter, you will review user-based tunneling (UBT) and how to configure it using local user-roles (LURs) and downloadable user-roles (DURs).

UBT

You will now focus in on user-based tunneling (UBT).

As you learned earlier, UBT uses the following basic process, which is illustrated in Figure 8-1. A client connects to a switch port that implements L2 authentication. Based on the authentication, the client is assigned to a user-role. The user-role has a gateway setting defined within it. This setting tells the switch to tunnel client traffic to an Aruba gateway or mobility controller (MC). The switch also informs the gateway or MC of the client’s gateway role. The gateway or MC then assigns the client to that role, applies the policies and settings configured for that role, and forwards the traffic.

Figure 8-1: UBT

Because ArubaOS gateways and MCs support more advanced, application-based policies than the AOS-CX switches, UBT is useful for companies who want to apply deep packet inspection (DPI) and Web Content Classification (WebCC) to wired clients. UBT also enables companies to unify wireless and wired policies, as well as centralize traffic distribution.

Review UBT tunnel configuration

For UBT to function, you must create a UBT zone on each AOS-CX access switch. This zone tells the switch where to access the gateway (AOS 10) or mobility controller (MC) (AOS 8).

Figure 8-2: Review UBT tunnel configuration

In this first simple example, shown in Figure 8-2, the company has a single gateway. The switch UBT zone configuration references that gateway’s IP address as in the primary-controller ip command. For the switch to contact the gateway, you must also enable the UBT zone and set the source interface for UBT. Specify the Layer 3 interface on which the switch reaches the gateway. Generally this is the interface on which the switch has its single IP address and default route.

After you enable UBT, the switch contacts the gateway and requests that the gateway bootstraps its tunnels. If the gateway is reachable and has the proper licenses, it responds. (In AOS 8, MCs require an AP and PEF license for the switch, as well as an RFP license if the MCs are using RFP for APs. In AOS 10, the gateway requires at least a Foundation license.) When you enter show ubt state, You should see the gateway’s IP address as the Primary LMS, and its status should be “ready_for_bootstrap.”

The primary LMS directs the switch to the correct gateways to act as its active Device Designated Gateway (DDG) and standby DDG. In this scenario, the gateway is not part of a cluster, so it directs the switch to use it as its active DDG. The switch establishes a DDG tunnel with the gateway. This tunnel will carry management traffic such as heartbeats. (Note that the switch CLI might refer to the DDG as a Switch Anchor Controller [SAC], but the concept is the same.)

Review UBT tunnel configuration to a gateway cluster

In the scenario shown in Figure 8-3, the company has a gateway cluster. When you configure the ubt zone, you can choose any of the gateway’s IP addresses to at as the primary controller. As before, the switch contacts the primary gateway and is bootstrapped. As you see in Figure 8-3, the primary gateway can assign the switch to any gateways in the cluster as the active and standby DDGs. The switch establishes tunnels with them. When you enter the show ubt state command, you should see a “Registered” state for both of those gateways.

Figure 8-3: Review UBT tunnel configuration to a gateway cluster

You can specify just the primary ip command, and the switch still creates active and standby DDG tunnels. However, it is best practice to also specify another gateway IP address in the backup-­controller ip command in the gateway zone. Then, even if the primary gateway is down, the switch can still become bootstrapped.

Triggering UBT for a client’s traffic

After the switch is registered with its DDG or DDGs, it can tunnel client traffic to gateways in the zone. You trigger tunneling for a client’s traffic using port-based authentication and port-access roles.

Figure 8-4: Triggering UBT for a client's traffic

Enable 802.1X or MAC-Auth on the port as you learned how to do in the previous chapter. The client authenticates to ClearPass Policy Manager (CPPM), and CPPM applies an enforcement profile, as shown in Figure 8-4. This profile assigns the client to a role (which might be a LUR or a DUR). In any case, that role has a gateway zone setting within it. That setting tells the switch to tunnel the user’s traffic to a gateway in the specified zone. The gateway zone setting further specifies a gateway role, which the switch tells the gateway to apply to the client.

The gateway receives the traffic in the tunnel. It applies the gateway role settings, which might include firewall policies and a VLAN assignment. It then forwards the traffic.

Role configuration for UBT

The role that triggers UBT can be an LUR or a DUR. The minimum configuration for each is shown in Figure 8-5. After you create the LUR, you can specify as little as one command: gateway zone gateway-role . The corresponding settings for an Aruba Downloadable Enforcement Profile include the Role Name, Gateway Zone, and Gateway Role.

Figure 8-5: Role configuration for UBT

You can add other settings, such as a session timeout, as you desire. In some cases, VLAN configurations are also required.

Client UDG assignment in AOS 10

When a role activates tunneling on a client, the switch sends the client’s traffic over a different tunnel from its DDG tunnels. It sends the traffic on a User Designated Gateway (UDG) tunnel to the client’s active UDG, as shown in Figure 8-6. Each client is assigned to an active UDG and standby UDG. In AOS 10, the cluster intelligently determines the UDG based on several factors. If Virtual Router Redundancy Protocol (VRRP) is enabled on the user’s VLAN, the VRRP master for that VLAN is always assigned as the active UDG. This configuration ensures that traffic follows a sensible flow, arriving directly on the gateway that acts as the default router for the client’s VLAN. If the client’s VLAN does not use VRRP, it is assigned to an active and standby UDG more or less randomly. The primary LMS gateway sends the switch a “bucket list,” when it bootstraps the switch. This bucket list tells the switch which MAC addresses to assign to which gateways as active and standby UDG; it load shares the assignments more or less evenly. (Note that the switch CLI might refer to the UDG as a User Anchor Controller [UAC].)

Figure 8-6: Client UDG assignment in AOS 10

Note that AOS 10 branch gateway clusters can operate in default gateway mode. In this mode, the gateway assigned as the cluster’s active gateway always becomes the VRRP Conductor regardless of VRRP priorities set on the gateways.

Reserved VLAN mode

For you to configure the port-access role and switch UBT settings correctly, you must also understand whether the switch is operating in reserved VLAN mode or extend VLAN mode.

In AOS-CX 10.04 and above, switches support reserved VLAN mode. In AOS-CX 10.04 and 10.05, this mode is the only option. In AOS-CX 10.06 and later, you can choose reserved VLAN as one option. Reserved VLAN mode is sometimes also called UBT 2.0 or local VLAN mode.

Figure 8-7: Reserved VLAN mode

In this mode, you specify a UBT client VLAN on the switch. This VLAN must exist on the switch, but it must not be configured on any ports. The switch assigns this VLAN ID to traffic that it encapsulates and sends over a UDG tunnel. It uses the same reserved VLAN ID for all UBT clients. The VLAN simply acts as a placeholder.

When the gateway receives the traffic, it assigns the clients to their actual VLANs based on the client’s gateway role. In the example shown in Figure 8-7, it assigns loan officers to VLAN 17 and tellers to VLAN 18. The gateway can have these VLANs configured on its ports and forward the traffic at Layer 2. Or it can route the traffic at Layer 3. In either case, the gateway is solely responsible for setting the VLANs for UBT clients. The switch has no awareness of these VLANs, and you do not configure them on the switch.

Reserved VLAN mode offers a simple set up. Admins can new VLANs on the centralized gateways without having to coordinate with switch admins. However, it also has some drawbacks for some situations. In reserved VLAN mode the switch can only carry untagged traffic with UBT. Companies sometimes want to tunnel tagged traffic, such as from VoIP phones. The switch cannot do so in reserved VLAN mode. In addition, the gateway handles flooded traffic—broadcasts, unicasts with unknown destinations, and multicasts (BUM). It replicates the BUM traffic as unicasts for each client to which the traffic should be flooded. It then sends the separate unicasts over the UDG tunnels. Sometimes this approach causes additional overhead on the gateways and tunnels.

VLAN extend mode

Alternatively, switches with AOS-CX version 10.06 and later can operate in VLAN extend mode. You enable this mode by entering this command: ubt-mode vlan-extend. Note that switches with AOS-CX versions earlier that 10.04 always operated in VLAN extend mode without the use of this command.

In VLAN extend mode, UBT clients’ roles must include a VLAN setting. This VLAN can be untagged (access) or tagged (vlan trunk allow). In this way, VLAN extend mode supports clients that send tagged traffic such as VoIP phones. Just like when you use VLAN steering with local forwarding, the switch must have the VLANs specified in the roles configured on it. Otherwise, the role application fails. However, you must not configure the VLANs in the UBT client roles on the switch uplink.

Figure 8-8: VLAN extend mode

The gateway must have corresponding VLANs configured on each corresponding gateway role, as shown in Figure 8-8.

When a switch operates In VLAN extend mode, its gateways establishes separate multicast tunnels to it. The switch receives multicast traffic destined to its clients on the multicast tunnel. It then replicates the traffic for flooding.

Enabling jumbo frames

The tunnels encapsulate traffic with a GRE header. This extra header means that a packet can exceed the typical maximum transmit unit (MTU) for a packet. To prevent issues, you should raise the MTU on the path between the access switches and their gateways or, in others words, enable jumbo frames.

On AOS-CX switches, you enable jumbo frames by increasing the IP MTU on the Layer 3 interface. You must also raise the MTU on the physical interfaces to match or exceed the Layer 3 MTU.

Figure 8-9: Enabling jumbo frames

On gateways you must enable jumbo frames on the port on which the switch contacts the gateway. You must also enable jumbo processing in the global firewall settings and set the MTU. AOS devices count the frame header in the MTU, so 9216 is the same as 9198 on the AOS-CX switches. Also make sure to reboot the gateways after enabling jumbo frames.

You must take care to set the MTU to equal values on all devices on the path. In the example shown in Figure 8-9, you are using the maximum value for simplicity.

Note that on AOS-CX switches, raising the MTU on a Layer 3 interface might interfere with RADIUS communications. If you encounter this issue, you can set up two L3 interfaces on the switches: one for handling the tunneling and one for handling RADIUS communications.

Troubleshooting

You might run into issues in which a client’s UBT state remains down, or other problems occur. A list of troubleshooting steps is shown in Figure 8-10.

Figure 8-10: Troubleshooting

First, validate that the client authenticated successfully. If not, you must troubleshoot the authentication settings. Make sure that 802.1X and MAC-Auth are correctly enabled, and the switch is accessing the correct CPPM IP address or fully-qualified domain name (FQDN). Also make sure that the switch meets the prereqs for obtaining DURs, if you are using that configuration option.

Be aware of whether your switch is using reserved VLAN mode or VLAN extend mode. If the switch is using reserved VLAN mode, you must specify the UBT client VLAN, and that VLAN must not be used for any other purpose. If you are using VLAN extend mode, you must specify a VLAN in each role. Those VLANs must exist on the switch, but not be on uplinks.

If the user tunnel fails to activate, the gateway-role configured in the switch role might not match the name of a role configured on the gateway. Match up the settings carefully.

Also double-check that CPPM is applying the correct roles and DUR configuration, if DURs are in use.

Implementing VNBT on AOS-CX switches

You will now learn about virtual network based tunneling (VNBT) and how to set it up on AOS-CX switches.

VNBT

Like UBT, VNBT enables AOS-CX switches to tunnel clients’ traffic to a remote destination, rather than switch that traffic locally. Both of these technologies make it simple for companies to group clients together based on identity without regard to the underlying network architecture. For example, you could use VNBT to group all IoT devices into the same Layer 2 network even if those devices are connected to switches divided by a Layer 3 boundary.

However, UBT always tunnels client traffic to an Aruba mobility controller (MC) or gateway, while VNBT tunnels traffic to another switch using Virtual Extensible LAN (VXLAN) tunnels, as shown in Figure 8-11. VNBT works well for companies that want to group clients together at Layer 2, based on role, and then send the clients’ traffic directly to the data center. It also works well for companies that want to send clients’ traffic to an application-layer firewall, before allowing the traffic to continue toward its destination. You can deploy UBT and VNBT in parallel, applying UBT to some roles and VNBT to other roles, based on the company’s particular security requirements for each role.

Figure 8-11: VNBT

For example, the bank in this chapter’s scenario might have IoT devices that manage lighting, temperature, and HVAC. Because those devices are critical to the business, and also at high risk for a security incident, the company wants to run all of their traffic though a security appliance in the data center. VNBT allows the switches to dynamically assign the IoT devices to a virtual network instance (VNI) and send their traffic to the DC security appliance before the traffic continues toward its destination.

Finally, note that VXLAN, like GRE, does not apply authentication or encryption. It is intended to tunnel traffic between switches that connect over relatively trusted links.

VXLAN fundamentals

Underlay vs overlay

VXLAN is called an overlay technology because it uses tunnels to establish virtual networks “over” an “underlay” network (usually an IP network). The underlay network is simply the traditional network, responsible for routing traffic from one point to another. The example underlay network shown in Figure 8-12 consists of routing switches in several buildings and a data center. It features multiple routing hops from end to end. (However, only a couple access switches are shown in Figure 8-12, while a real network would have many more access switches.)

Figure 8-12: Underlay vs overlay

Each virtual “overlay” network extends over the underlay network without awareness of the IP addressing and architecture in the underlay network. Two clients in a virtual network can communicate at L2 even though they are actually divided by several routing hops in the underlay network.

Similarly the underlay network infrastructure devices have no awareness of the IP addressing used within overlay networks. They only see traffic exchanged between Virtual Tunnel Endpoints (VTEPs).

Virtual Network ID (VNI)

Each virtual network in VXLAN is identified by a Virtual Network Identifier (VNI). Often the virtual network is called a VNI.

A VNI is similar to a VLAN in that it defines a broadcast domain. All endpoints assigned to the same VNI have IP addresses in the same subnet, and their broadcasts and multicasts reach each other.

Figure 8-13: Virtual Network ID (VNI)

When you set up a VNI on an ArubaOS-CX switch, you map a VLAN to the VNI. The switch then places any traffic that is assigned to that VLAN within that VNI. For example, client 1 is assigned to VLAN 10, which is mapped to VNI 10010, as shown in Figure 8-13. Therefore, the switch forwards client 1’s traffic within VNI 10010.

Different VTEPs within a VXLAN domain can map the same VLAN IDs to the same VNI or different VLAN IDs to the same VNI. Only the VNI is visible between the VTEPs.

VXLAN encapsulation

To send a frame over a VXLAN tunnel, the VTEP encapsulates the incoming frame at Layer 2. In other words, the existing MAC header remains intact, as shown in Figure 8-14. The VTEP then adds a VXLAN header, which identifies the VNI. Next the VTEP adds a UDP header with the port for VXLAN (typically 4789). It then adds a delivery IP header, which has its own IP address as the source IP and the remote VTEP’s IP address as the destination. Finally, the VTEP also adds an outer MAC header. The outer MAC header directs the traffic to the next hop for reaching the destination IP, just like a MAC header does for any IP traffic sent over an Ethernet LAN. This header can change as the traffic flows across the underlay network, and the rest of the illustrations for this chapter will omit it for simplicity.

Figure 8-14: VXLAN encapsulation

Remember: the underlay network sees only the outer MAC address and delivery IP header. From its point of view, VTEPs are exchanging traffic with each other. The VTEPs are responsible for encapsulating and decapsulating traffic and handling connectivity for the clients in the VNIs.

EVPN

For VXLAN to function correctly, VTEPs need to find each other. Admins could configure the IP address of every other VTEP on each VTEP information manually; however, that approach can be time consuming and inefficient. VTEPs also need to know which traffic to send to which remote VTEP, based on destination MAC address. VTEPs could build MAC forwarding tables for VNIs, much as they do with normal Ethernet, by flooding traffic and listening for the source MAC addresses that arrive on each tunnel. However, this behavior is also inefficient as it requires sending traffic across every tunnel instead of just the one correct tunnel.

Figure 8-15: EVPN

Aruba recommends using Ethernet VPN (EVPN) as the control plane for VXLAN. EVPN both helps VTEPs find each other and helps VTEPs advertise their clients’ MAC addresses. VTEPs use BGP to advertise the VNIs that they support. Each VTEP then establishes tunnels with every other VTEP that supports at least one VNI in common with it. VTEPs also use BGP to advertise the MAC addresses connected to them in each VNI, as shown in Figure 8-15. In version 10.05 and above, in which support for distributed routing was added, other VTEPs use these advertisements to build the MAC forwarding table for each VNI.

EVPN also advertises the host IP addresses in each VNI. The host IP address will help VTEPs route traffic, when necessary, as you will examine in more detail later.

More precisely, ArubaOS-CX switches running 10.5 and above, support three types of BGP EVPN routes:

EVPN type 2 routes, which advertise MAC addresses of clients connected to VNIs on this VTEP

EVPN type 3 routes, which advertise “inclusive multicast routes”—These advertisements indicate the VNIs that the VTEP supports.

EVPN type 5 routes, which advertise IP prefix routes—These advertisements let VTEPs advertise the host IP addresses

BGP autonomous system (AS)

Aruba generally recommends that you use internal BGP (IBGP) for EVPN. With this setup, all of the VTEPs are part of the same private autonomous system (AS). Private AS numbers range from 64512 to 65534. You can choose any private AS number for your EVPN solution, but make sure to use the same number on all of your routing switches.

Figure 8-16: BGP autonomous system (AS)

Aruba recommends that you use a route reflector (RR) or two redundant RRs as part of the BGP AS, as shown in Figure 8-16. The RRs eliminate the need for every IBGP router (VTEP) to establish a neighbor relationship with every other IBGP router, which would not be scalable in an enterprise network. Instead each VTEP, acting as an IBGP router, establishes a neighbor relationship with just the RRs. Each VTEP sends its EVPN BGP advertisements to the RRs, which then distribute the advertisements to the other VTEPs.

Aruba recommends that core routing switches act as RRs. These core routing switches are generally not VTEPs. They can still reflect the EVPN BGP advertisements, even though they do not participate in VXLAN.

Centralized vs distributed L3 gateways

VXLAN can operate with centralized or distributed L3 gateways.

With the centralized approach, a central router, such as the border VTEP or even a firewall connected to that VTEP, acts as the default gateway for VNIs, as shown in Figure 8-17.

Figure 8-17: Centralized L3 gateway

With distributed L3 gateways, each VTEP routes traffic for any VNIs that it supports. In the distributed L3 gateway model, multiple VTEPs that support a VNI share the default gateway address for that VNI, as shown in Figure 8-18. Each VTEP responds to ARP requests for that IP address from its locally connected clients. It does not forward those ARP messages to other VTEPs, so each VTEP can act as if it owns the IP address for its own clients.

Figure 8-18: Distributed L3 gateway

The distributed approach offers a few advantages. Each VTEP only needs to maintain ARP table entries for the clients connected behind it, while a centralized gateway would need a very large ARP table to support all of the clients in the VXLAN solution. In addition, the failure domain is reduced. If one VTEP fails, routing continues undisturbed for clients connected to other VTEPs, whereas if a centralized gateway fails, routing is disrupted for the entire solution. Finally, the distributed approach can reduce latency for client-to-client traffic flows. If two clients in different VNIs on the same switch, or on switches at the same site, need to communicate, distributed routing lets them do so without sending their traffic through a central location.

However, some companies prefer the centralized approach because they want to send all traffic through a centralized router. For example, if the company wants to send traffic through a third-party firewall in the DC, the company might prefer a centralized approach.

Asymmetric Integrated Routing and Bridging (IRB)

When ArubaOS-CX switches act as distributed L3 gateways, they always use symmetric routing, as opposed to asymmetric routing.

To understand the differences between symmetric and asymmetric routing, examine the scenario shown in Figure 8-19, in which client 1 in VNI 10010, connected to VTEP 1, wants to communicate with client 2 in VNI 10020, connected to VTEP 2.

Figure 8-19: Asymmetric Integrated Routing and Bridging (IRB)

With asymmetric routing, VTEP 1 receives the traffic and routes it to the client in VNI 10020. Because VTEP 1 is routing the traffic to its final destination, it changes the traffic’s destination MAC address to client 2’s MAC address, just like a typical router would. To do so, the VTEP requires an ARP table entry for client 2. The VTEP knows that client 2’s MAC address is behind VTEP 2, so it sends the traffic over the tunnel to VTEP 2 in VNI 100020. A similar process happens for the return traffic, but in reverse. VTEP 2 receives the traffic, routes it to VNI 10010, and changes the destination MAC address to client 1’s MAC address. It sends the traffic to VTEP 1 in VNI 10010.

Note two key facts about asymmetric routing. First, the routed traffic uses a different VNI for each direction of the exchange. Second, and even more critically, the VTEPs need to maintain ARP entries for all the clients to which they route traffic. This behavior can lead to many ARP packets flowing over the VXLAN tunnels and large ARP tables.

Symmetric IRB

Now look at symmetric routing. VTEP 1 receives the traffic and routes it to client 2 in VNI 10020. Based on EVPN advertisements, VTEP 1 knows that client 2 is behind VTEP 2. So VTEP 1 changes the destination MAC address to VTEP 2’s MAC address. And VTEP 1 tunnels the traffic in a special VNI that is dedicated to routing. In the example shown in Figure 8-20, that VNI is 20000. VTEP 2 receives the traffic in the routing VNI and handles moving the traffic to VNI 10020 and changing the destination MAC address to client 2’s true MAC address. The return traffic follows a similar process. VTEP 2 routes traffic to client 1 using the routing VNI and VTEP 1’s MAC address as the destination MAC.

Figure 8-20 Symmetric IRB

With symmetric routing, all routed traffic uses the routing VNI, so both sides of the conversation use the same VNI. And each VTEP only needs to maintain ARP entries for the clients actually connected to it, minimizing the size of the table on each VTEP.

VXLAN setup on an access layer AOS-CX switch

Prerequisites

You will now look at configuring VXLAN in order to support VNBT. For the purposes of this study guide, you will assume that the underlay network is already established with a routing protocol such as Open Shortest Path First (OSPF) in place, as shown in Figure 8-21. The VXLAN encapsulation can increase the total size of IP packets. Therefore, you should increase the MTU across the complete underlay. Make sure to use the same MTU on every routing device.

Figure 8-21 Prerequisites

The BGP RRs are also set up, and any VTEPs in the data center are configured. For the purposes of this chapter, your responsibility is simply to configure the access layer AOS-CX switches that will implement VNBT to participate in the VXLAN solution.

Your access layer switches might not currently implement routing. If that is the case, you will need to enable OSPF on your access layer switches. The switch needs a loopback interface, and it needs to advertise that interface is OSPF. Following this paragraph is a simple example configuration in which the switch is part of OSPF area 1, and its loopback interface IP address is 192.168.2.5. You would need to communicate with the admins who set up the OSPF domain for the correct values in your environment.

router ospf 1

 router-id 192.168.2.5

passive-interface default

area 0.0.0.1

interface vlan 10

this is the uplink interface in which the switch communicates with the rest of the OSPF domain

ip mtu 9198

ip address 10.1.10.5/24

ip ospf 1 area 0.0.0.1

no ip ospf passive

interface loopback 0

ip address 192.168.2.5/32

ip ospf 1 area 0.0.0.1

Collect information

To prepare for the configuration, gather some information.

First, you need to understand what overlay networks the company wants to establish and which of those networks the switch that you are configuring should support. You should record the VNI for each network, as well as the VLAN ID that you want to associated to each VNI. It is not strictly required to map the same VLAN ID to the same VNI on every VTEP, but you might want to use the same IDs for clarity. You should also determine how the company wants to route the traffic in the VNI whether with a centralized or distributed approach.

Figure 8-22: Collect information

If a distributed approach is required, you need to know the IP subnet and default gateway address for the VNI (you will configure these settings on the VLAN associated with the VNI). You should also understand to which VRF the company wants to assign each VNI. Also find out what RT import and export values the border VTEP uses for each VRF, as well as the routing VNI. You must match those settings on the same VRF on each VTEP.

Also make sure that you know how to set up communication with the BGP RRs. As shown in Figure 8-22, you will want to record their loopback IP addresses, as well as the private AS number (ASN) used for this deployment.

Configure BGP

You can begin setting up VXLAN EVPN on a switch by establishing the BGP settings.

Specify the AS number that you collected earlier, and set the switch’s BGP router ID to match the switch’s loopback IP address.

Figure 8-23: Configure BGP

Create a peer group with any name that you want; in the example shown in Figure 8-23, the name is “RRs.” Set the peer group’s ASN to the same one as used on this switch because all of your switches belong to the same AS. Configuring the fall-over option enables fast failover if a neighbor in the peer group goes down. You should also set the switch’s loopback IP address as the source of the BGP advertisements.

Assign the core routing switches configured as RRs to the peer group, specifying their loopback IP addresses. Then activate those neighbors.

Configure VXLAN

Once the access layer switch has established a BGP connection with the RRs, you are ready to configure VXLAN on the switch.

The switch needs one VLAN for each VNI to which you want to connect clients on this switch, as shown in Figure 8-24. Create those VLANs. Or you can use existing VLANs if you want to turn those VLANs into virtual overlay networks.

Figure 8-24: Configure VXLAN

Then create the VXLAN 1 interface. Set the interface’s source IP address to the switch’s loopback address.

Under the VXLAN interface, create each VNI that you want to use on this switch. Map the desired VLAN to that VNI.

By default the VXLAN interface is disabled. Make sure to enable it.

Configure EVPN

Next create the EVPN configuration. This configuration requires the VLANs that you map to VNIs. It also requires RDs and RTs for the EPVN advertisements for each VLAN. However, for EVPN, it is easiest to use the “auto” option for these settings.

Figure 8-25: Configure EVPN

In version 10.5, the ability to advertise host networks was added. You should enable this option when you want to support distributed routing. The VTEP then advertises host IP addresses for specific clients connected to it. Because multiple VTEPs support the VNI and subnet, it is important that they advertise the specific host IP addresses. Then every VTEP can identify the precise clients ­connected behind each VTEP.

You must also enable EVPN advertisements in BGP. Create the “l2vpn evpn” address family and enable the “send-community” option for the RR peer group or neighbor, as shown in Figure 8-25.

Creating user-roles that trigger VNBT

To apply VNBT to clients’ traffic, you simply need to place the clients within a VLAN that is mapped to a VXLAN VNI. You could assign this VLAN to edge ports statically. However, it is most secure and flexible to apply the VLAN dynamically, as you learned how to do in the previous chapter.

Figure 8-26: Creating user-roles that trigger VNBT

Create a LUR or DUR that specifies the VLAN associated with the desired VNI as an access VLAN, as shown in Figure 8-26. When a client is assigned to this role, the switch will then tunnel the client’s traffic in that VNI.

Summary

Congratulations! You have completed Chapter 8. You should now understand how to implement 802.1X for wired clients. You should have a renewed grasp of AOS-CX roles and Dynamic Segmentation. You should be knowledgeable about implementing local forwarding with VLAN steering and role-based ACLs, as well as implementing UBT on AOS-CX switches. Lastly, you should have a working knowledge about implementing VNBT on AOS-CX switches.

Learning checks

How do you apply UBT to a client’s traffic? (Select one.) Use the gateway zone setting in the role to which the client is assigned.

Enable the UBT (gateway) zone globally, which applies it to all clients’ traffic.

Apply the UBT zone to the client’s port.

Apply the UBT zone to the client’s VLAN.

How can VNBT help a company secure clients’ traffic? (Select one.) By tunneling the clients’ traffic to an Aruba gateway, which performs advanced security functions

By redirecting the clients’ traffic to a captive portal server, which authenticates the clients

By redirecting the clients’ traffic to a cloud security solution, which performs advanced security functions

By tunneling the clients’ traffic to a switch in the data center, which passes the traffic to an application-level firewall

Note: For answers to all learning checks, refer to the Appendix.

9

Monitor with Network Analytics Engine (NAE)

EXAM OBJECTIVES

✓ Deploy and use Network Analytics Engine (NAE) agents for monitoring.

Assumed knowledge

Basics of managing ArubaOS-CX (AOS-CX) switches

Overview

In this chapter, you will learn how to deploy and analyze NAE agents for monitoring security events on AOS-CX switches.

The AOS-CX NAE helps admins take a new approach toward monitoring and troubleshooting the network. You will begin this chapter by learning about NAE and the ways that you can use this feature in your network. You will then look at NAE agents in more detail, exploring how they monitor various resources on an AOS-CX switch and how they trigger actions.

You will then learn how to deploy NAE agents. You will see how all agents are based on a script, and you will explore ways to install scripts and then create agents from them. You will also learn how to use the Analytics Dashboard, which displays information collected by agents.

Overview of AOS-CX NAE

This chapter begins with an overview of NAE. You will learn about NAE agents, what they can monitor, and what they can do.

Introduction to network automation with AOS-CX

AOS-CX switches come with a powerful tool for monitoring the health of the switch and the network. This tool is the Network Analytics Engine (NAE).

Figure 9-1: Introduction to network automation with AOS-CX

As shown in Figure 9-1, NAE is integrated with the AOS-CX system configuration and time series databases. It uses Python-based agents, developed by Aruba and the Aruba community, to help companies better monitor and troubleshoot their network environment through an automated process. Agents monitor the state, settings, and statistics around specific system components within the current state database. For example, an agent can monitor the number of bytes transmitted on an interface or the switch’s operating temperature. The agent then writes the ongoing results to the time series database for ongoing analysis.

Admins can interact with the NAE through the Web UI’s analytics dashboard. They can also automate the NAE through the REST API using tools such as Postman, Ansible, or another choice. They can also create or obtain Python scripts for new agents and load the agents on the switch using the Web UI or the REST API.

Aruba NAE areas of focus

NAE agents can address many use cases, including monitoring system health, analyzing the network and alerting you to issues or changes, providing insight into application performance, and automatically optimizing the network based on current conditions.

As shown in Figure 9-2, however, the focus for this study guide is security. You can develop NAE agents to analyze network traffic passing through the core and learn about anomalies. For example, normally most traffic might flow north-south from clients to the core. A new burst of east-west traffic flows could signal an issue such as a camera attempting to access a different network segment, indicating that it has potentially been compromised. Or, a flood of invalid ARP packets could indicate a Denial of Service (DoS) attack.

Figure 9-2: Aruba NAE areas of focus

NAE agent components

An NAE agent consists of several components. As shown in Figure 9-3, an agent can include one or more monitors. The monitor tracks a particular resource attribute on the switch, checking the switch’s current state database for the current value of that attribute. The agent collects the data every 5 seconds and writes the data to the time-series database on the switch’s hard disk in order to create an ongoing record of the resource’s state. You can see a graph of the monitored resource state over time in the AOS-CX Web UI.

Figure 9-3: NAE agent components

The agent can also include one or more rules, which consist of a condition and an action. The condition references a monitor, indicating what state for the monitored attribute should trigger an action. For example, a monitor might track hits on an ACL entry. The condition might indicate a number of hits greater than 1, which triggers an alert.

The monitor also outputs data to a graph, which you can add to the Analytics Dashboard in the switch Web UI.

An agent might also have specific values of parameters, which can be referenced in monitors, conditions, and actions.

What NAE agents monitor

An NAE agent can monitor any state or statistic defined within the AOS-CX REST API. For example, it could monitor the number of transmitted bytes on a particular interface or the CPU utilization on a management module. A monitor can track the packets passed and dropped by control plane policing (CoPP) policies. If the NAE agent detects a surge in the number of dropped packets, it can create alerts, which tip admins off to the potential threat. Similarly you can create agents that monitor hit counts on particular ACLs. Some companies might use the application health monitoring agent to track connectivity to a critical security service for the switch such as a ClearPass server. Monitors can be defined for many other attributes on a CX switch.

In fact, companies’ developers can create their own scripts to monitor any resource attribute defined in the REST API. This approach gives you great flexibility in terms of collecting the data that is relevant for your environment. If you want to explore the types of information that the REST API exposes, you can visit the AOS-CX REST API Reference at https:///api/index.html.

How actions are triggered (no clear condition defined)

You now understand a bit about how monitors collect data and make it available for graphs and rules. Next, you will look at the rules in more detail. Rules let the agent take automatic action based on the information obtained by the monitor.

A rule must have a condition, which defines a particular state for the monitored value. At any given moment, the state is either true or false. Generally, the state being true indicates a potential issue that admins should know about. For example, an agent might monitor the number of bridge protocol data units (BPDUs) dropped by a CoPP policy on the switch. A condition in a rule might be that the monitored value is greater than 5 per second.

The agent checks the state against the condition every 5 seconds. The rule’s action executes when the condition changes from false to true. At that point, the condition becomes inactive. The agent does not re-execute actions if the condition remains true. This prevents constant alerts for the same ongoing issue. If the condition becomes false again (for example, the number of dropped BPDU is lower than 5 per second), the condition becomes active again. The agent then will execute the action if the condition becomes true again.

Figure 9-4: How actions are triggered (no clear condition defined)

The example shown in Figure 9-4 lists just one rule, but agents can customize their behavior to nuanced conditions by using multiple rules, each with a different condition and action. For example, a condition in one rule might indicate a less severe problem and a condition in another rule might indicate a more severe problem.

How actions are triggered (clear condition defined)

In some cases, a condition might toggle frequently between true and false. For example, consider a condition configured to trigger when a CoPP policy drops more than 5 BPDUs per second. The policy might drop 5 BPDUs per second over one interval and change the condition from false to true. Then it drops 4 BPDUs per second over the next interval, and the condition transitions from true to false. Then the policy drops 6 BPDUs per second over the next interval, and the agent triggers the action again.

Figure 9-5: How actions are triggered (clear condition defined)

To avoid this problem, you can define a clear condition, which must be met to free the main condition. The “clear” condition is a low threshold that the monitored attribute must fall below before the condition triggers the action again. As shown in Figure 9-5, the clear condition becomes active when the condition first transitions from false to true, and the agent begins checking the state of the clear condition every five seconds. Even if the condition becomes false again, the clear condition remains active, and the condition inactive, as long as the clear condition is also false. Only when the clear condition becomes true does the condition transition to active. In the previous example, the clear condition could be that the policy drops 0 BPDUs per second. Now the rate must fall 0 before the original condition can become active again. You can optionally define a clear action, which also executes when the clear condition changes from false to true.

Agents that use baselines to trigger actions

Often it can be difficult to determine the best value to define in a condition. For example, you might be trying to define a condition that indicates excessive traffic on an Ethernet interface. Is a rate of 500 million bytes per second excessive, or is a higher or lower value more appropriate? The answer often depends on the particular network, switch, and interface. The AOS-CX NAE can help to automate and remove the guesswork for defining conditions through the use of baselines. The agent can construct a baseline of normal values for the monitored resource attribute. A condition then triggers if the value deviates too much from the baseline. It is important that you understand, though, that agents do not create baselines by default; whoever creates the agent must specifically script the agent to create the baseline.

Figure 9-6: Agents that use baselines to trigger actions

When so configured, the agent constructs the baseline by collecting data over an initial learning period, which is configurable. The initial learning period should be long enough that all representative patterns are included. For example, it should be at least a day and maybe as much as a week. As shown in Figure 9-6, the agent then uses an algorithm to smooth the data and create the baseline. The agent next uses a configurable threshold multiplier to determine the high threshold, which indicates when a condition using the baseline changes to true and triggers an associated action. The larger the multiplier, the more deviation allowed and the smaller the multiplier, the less deviation allowed. The low multiplier lets the agent construct a low threshold, which indicates when the condition is cleared and a clear action triggered. You could create several conditions with different multipliers that trigger different actions; the condition with the larger multiplier should have a more significant action because it indicates a greater deviation from normal.

In addition to the initial learning period, the agent also uses a continuous learning period to continue to recalibrate the baseline. This lets the agent respond to gradual changes that create a new normal. However, data from a continuous learning period that includes an anomaly that triggered a condition is discarded. This lets the agent detect the anomalies, but not use them to change the baseline.

Action options

NAE supports several action types. The agent can send an alert with a critical, major, or minor level. These alerts are visible at a glance in the Analytics Dashboard, helping admins find issues quickly. The agent can also remove the alert and return to the normal level.

An agent can also execute CLI commands or shell commands. The output for the command is collected in the alert for admins to view. You should be very careful with using shell commands in an agent because mistakes can damage the switch functionality and render the switch unusable. In addition, an agent can make REST API calls to itself or remote devices and applications. This allows for interaction with all of the Aruba portfolio of applications and devices, which have their own REST interfaces. Through REST calls, the NAE can also integrate with third-party applications, including ticket generation systems like ServiceNow and TOPdesk.

An action can also send log messages to a system log, indicating information about the condition that has occurred. If the switch has log forwarding set up on it, the log is also sent to that server.

An action can also generate a custom report with multiple pieces of relevant information about the condition.

NAE agents can also implement more complex actions using “callback” actions. Callback actions permit a condition to trigger multiple actions such as setting an alert level, using CLI commands to collect information, and creating a log. They also permit the agent developers to create custom actions such as email notifications. And they let developers define more complex scripts with features such as error handling. The purpose of this study guide is not to teach you how to define such actions. However, you should be aware that NAE agents are capable of them.

Note that AOS-CX uses a safe sandbox environment to execute actions, which prevents agents from using excessive CPU or obtaining access to sensitive files such as certificates. The sandbox has access to the default VRF, not the management one. If actions need access to the Internet to execute properly, make sure that the default VRF has such access.

Deploying NAE agents

You will now learn more about installing NAE scripts on your AOS-CX switches and deploying NAE agents. You will also learn about using the Analytics Dashboard to monitor agents and check for alerts.

Relationship between NAE scripts and agents

Each NAE agent is defined by a Python script that is loaded on the AOS-CX switch. As shown in Figure 9-7, the script defines the agent, including which attributes it monitors and rules for any actions that the agent might take. The script might also define parameters, which are user configurable settings. For example, instead of specifying that an agent monitors transmitted bytes per second (Bps) on a specific interface, the script might specify that the agent monitors transmitted Bps on a variable interface parameter. Then users can choose the interface that they want when they create agents.

Figure 9-7: Relationship between NAE scripts and agents

An NAE script has no effect until it has an agent associated with it. The NAE agent is a specifically-configured, executable instance of the script. Once the agent is created from the script, the agent performs the tasks defined by the script. They monitor the resource and take actions when conditions are triggered. Note that agents run with administrator rights.

When you create an agent, you define the values that you want for the parameters. You can create different agents from the same script using different parameters. For example, if one script parameter indicates the interface to monitor, you could create multiple agents, each monitoring a different interface.

Sources for scripts (standalone switches)

There are three sources for an agent script:

Built-in (system-created)

Aruba Solutions Exchange (ASE)

User-created

Built-in scripts

Built-in scripts and agents are installed on the switch before the switch is shipped from the factory. All scripts and agents have information about their origin associated with them. Built-in scripts and agents have an origin of “system” and are marked System Created in the Web UI.

Updating the switch software updates the system-defined agents as well.

Built-in scripts and agents cannot be deleted. But you can enable, disable, and change the configuration of built-in agents. Built-in scripts are not displayed in the switch config unless you have changed and saved one or more parameters.

If you create an additional agent from a built-in script, that agent is considered a user-created agent, which can be deleted.

The current software release includes a single built-in script and agent that monitors several system resources:

Built-in script: system_resource_monitor

Built-in agent: system_resource_monitor.default

Installed from Aruba Solution Exchange (ASE)

The primary source for additional NAE scripts is Aruba Solutions Exchange (ASE). You can access this portal at https://ase.arubanetworks.com/. No login is required to browse the exchange or look at information about solutions. However, to download solutions, view solution source code, and download NAE agents, you must log in. If you do not have an existing account, register for a free Airheads Social account at: http://community.arubanetworks.com. You can also access ASE directly through the AOS-CX switch UI, as long as your browser has Internet connectivity. In this case, you don’t need to log in.

ASE provides a variety of Aruba-certified NAE agent scripts. These scripts are written by Aruba developers, and Aruba tests and validates that the scripts do what they advertise.

When you install scripts from ASE and create agents from them, you can later disable and remove these agents if you want. Before you complete a software upgrade, you may need to remove an old version of the agent and script. Then, after the upgrade, you can upload new ones.

User-created

You can also obtain agent scripts from community sources and load them on your switch using the WebUI. For example, AOS-CX scripts on GitHub can be found here: https://github.com/aruba/aos-cx-python. You should use these scripts at your own risk. You should always evaluate a script before loading it on the switch to ensure that the actions executed are what you expect.

Alternatively, you or developers in your organization can create agents on your own with Python script.

In either case, Aruba does not provide technical support for user-created scripts.

These agents are managed like the ones that you install from ASE. You can disable, remove, and update them separately from the software.

The Airheads community provides a place for members or participants to search for information, read and post about topics of interest, and learn from each other. Guests (unregistered visitors) can browse or search the community for information. Members (registered users) can post messages or comments, track discussions, and get email notifications on posting activity and other community actions. The Airheads community is the glue that holds together all the components of the NAE solutions. Airhead community members can share their expertise and tips and point each other toward relevant agents. There is now a Developer Community forum under the technology category in the Airheads with discussion forums dedicated to automation and NAE questions and support. Aruba is committed to expanding the NAE value with extensive research and development (R&D) investment in building NAE scripts and supporting the community. Within the Airheads community, there is a Developer Community group that is specific to APIs, programming, and automation. The Developer Community is the recommended place to post questions about the Aruba Network Analytics Engine (NAE). See the Developer community at: https://community.arubanetworks.com/t5/Developer-Community/bd-p/DeveloperCommunity. See the Airheads community at http://community.arubanetworks.com/.

For more information about using the Aruba Solution Exchange, see https://ase.arubanetworks.com/docs

Analytics Dashboard

It is typical to manage NAE agents and other functions in the Web UI, rather than the CLI. This approach lets you view graphs and alerts produced by agents, as well as install agents from ASE.

Figure 9-8: Analytics Dashboard

You will monitor and manage NAE from the Analytics Dashboard. You can access this dashboard in two ways: click the Analytics section in the main dashboard or select Analytics in the sidebar.

As shown in Figure 9-8, the Agents section on the Analytics Dashboard lists all of the agents on NAE and indicates whether they are operating normally. The Scripts section shows the Python scripts associated with those agents. You can click the Scripts link to go to the Scripts Management page. Look to the Alerts section to see more details on any minor, major, or critical alerts that the NAE agents have generated.

You can select the name of these sections to move to a page with details. For example, click the Agents link to go to the Agent Management and create new NAE agents. Or you can select an individual agent to move to that agent’s detail page. Or click the Scripts link to go to the Scripts Management page and view and manage your NAE scripts.

The dashboard also shows graphs created by NAE agents. You will learn more about adding and using these graphs in a moment.

You can also change the layout for the dashboard. Click this icon at the top of the bar and choose, Unlock Page Layout. Each section in the dashboard is then outlined with dashed lines. You can click a section and move it around. When you are done editing, you can click the icon again to lock the page layout.

Accessing ASE from the Analytics Dashboard

You can access ASE from the AOS-CX switch Web UI. Browse to the switch’s IP address or hostname and log in with valid credentials. (As you learned in an earlier chapter, you can set up authentication to a local list or to an external authentication server like CPPM.)

Click Analytics in the left menu to access the Analytics Dashboard as shown in Figure 9-9. Then click in the ARUBA Exchange section. Or you can click the download icon in the Scripts section.

Figure 9-9: Accessing ASE from the Analytics Ddashboard

Obtaining NAE scripts using ASE

You will be connected to ASE. You will not need to log in because you connected through the switch UI.

Figure 9-10: Obtaining NAE scripts using ASE

You can browse through the exchange using tags to narrow your search. Examples of tags include the name of the resource that you want to monitor. Tags also indicate the switch model for which a script is intended. On the Aruba Solution Exchange, Aruba-certified scripts have the following tag: nae-aruba-certified.

If you decide that you are interested in a script, you can select its check box and click View Script, as shown in Figure 9-10, to see the script. Or you can click Download to view and possibly customize the script offline. You can also select Install to immediately install the script on your switch.

Creating an NAE agent

When you install a new script, it does not yet have an agent associated with it, so the script will not yet perform any functions. To create an agent based on a script, first access the Agent Management page by selecting Agents in the Analytics Dashboard, as shown in Figure 9-11. Then select Create. You will be taken to the Create Agent page.

Figure 9-11: Creating an NAE agent

Alternatively, you can go to the Scripts Management page by selecting Scripts in the Analytics Dashboard. Then you can click the plus icon (+) next to the script. This action also takes you to the Create Agent page.

Defining and saving the new agent

When you install a new script, it does not yet have an agent associated with it. To create an agent based on a script, first access the Agent Management page by selecting Agents in the Analytics Dashboard. Then select Create (you can also select Create Agent in the Script Management page).

As shown in Figure 9-12, a window appears where you can choose the script on which you want to base the agent. Then define the agent name. Finally, customize the parameters and save.

Figure 9-12: Defining and saving the new agent

You can also select an agent in the Agent Management page and select Edit to adjust the parameters on an existing agent.

Managing agents in the Analytics Dashboard

When you create a new agent, it is automatically enabled. Each enabled agent uses its monitors to collect data and uses rules to trigger actions. You can see a list of agents on the switch in the Analytics Dashboard.

Figure 9-13: Managing agents in the Analytics Dashboard

If you want to see a graph of the data being collected by the agent, you can click the plus icon (+) next to the agent, as shown in Figure 9-13. A graph then appears in a box on the Analytics Dashboard. The graph shows one line per monitor defined by the agent. You can click a name in the legend to turn the corresponding line on and off. The graph can only show the output for up to eight monitors at a time. If an agent has more than eight monitors, you can customize the view. You can choose the specific monitors that you want to show. Or you can use the auto function, in which the graph automatically shows the lines for the eight monitors that are currently most “interesting.” Interesting can mean that the monitor is detecting changing data.

Even if you do not add the agent’s graph to the Analytics Dashboard, you can see the graph by clicking the agent name and viewing the agent details.

If an agent rule triggers an action that sets an alert level, you will see an alert in the Alerts pane. You can see more details about the alert by clicking it.

NAE agent details

As shown in Figure 9-14, the Agent Details page provides more detailed information about the agent, including its version and status. If the agent has multiple monitors, this page shows all of the graphs associated with those monitors. The parameters section shows agent settings that you can configure. You can also click icons to edit the agent or look at its script.

Check the alerts section to see information about the alerts this agent generates so that you can take the proper steps to resolve them. You can click a particular alert and then select Details to see a window with Alert details.

Figure 9-14: NAE agent details

NAE alert details

As shown in Figure 9-15, the Alert Details window shows details about when and why the alert occurred, as well as the alert level. You can view a history of the actions taken in association with the condition that triggered this alert. In this example, these actions include syslog messages and CLI commands. You can also collect any information that those actions generated. Select Output to see the output from the CLI commands. If the alert generated a custom report, you can click and view that report.

Figure 9-15: NAE alert details

You can also use the REST API to obtain information about NAE and NAE agents. Refer to the documentation and reference interface for more details.

Considering NAE maximums

As you plan which NAE scripts to install and agents to deploy, you need to keep in mind that NAE naturally consumes resources on the switch. Switches support a maximum number of scripts, agents, and monitors. The maximums apply to agents, and the monitors within those agents, even if they are not enabled. If you try to install more scripts than allowed, or create more agents than allowed, you will receive an error. Different agents include different numbers of monitors, depending on the definitions in the script. One agent might use just one monitor, while another uses dozens. If creating an agent will make the switch exceed the monitor maximum, an error will occur, and the agent will not be enabled, even if the switch has not reached its maximum number of agents.

Figure 9-16: Considering NAE maximums

Different switch models have different limitations. You can view the limitations on your switch, as well as the current consumption, with the command shown in Figure 9-16.

Use the maximums to plan which agents you want to run at all times and which you might deploy to investigate particular circumstances.

Managing agents for Central-managed switches

Up to this point you have learned how to manage NAE on a single switch. Aruba also offers tools for managing your AOS-CX switches and their NAE functions at scale. If you are managing the switches within Central, you can use Express Config to deploy NAE agents to multiple switches.

Figure 9-17: Managing agents for Central-managed switches

Go to the group level for the switches that you want to configure. Navigate to Devices > Switches and click the AOS-CX Config icon. Then enable MultiEdit mode, as shown in Figure 9-17.

When that mode is enabled you will see a list of switches in the group. You can search and filter for particular switches. Select all of the switches on which you want to deploy agents. Then click Express Config in the pop-up at the bottom right.

Within the Express Config window, you select Network Analytics Engine. You can then install scripts from the choices of scripts loaded in Central. When you install the script, it installs on all switches that you selected for Express Config. You can then create agents from the scripts, and again, the configuration applies to all of the selected switches.

Monitoring NAE with NetEdit 2.0

If you are managing your AOS-CX switches with NetEdit, you should be aware that NetEdit 2.0 provides integration with NAE. As shown in Figure 9-18, you can view the scripts installed on the AOS-CX switches from the Topology or Network view. NetEdit also shows alerts that NAE has triggered, which can help admins discover the alerts more quickly.

Figure 9-18: Monitoring NAE with NetEdit 2.0

NetEdit organizes the scripts and related alerts by tags, making the view simpler for admins to understand. These tags derive from the script tags. (Note that the tags are informational only.)

If you see an alert in NetEdit and want to follow up on it, you simply click a link from the network view. If you have logged in to the associated switch’s Web UI recently, the browser is directed straight to the switch’s Analytics Dashboard or to the alert that is showing on NetEdit. If you have not logged in recently, you will be taken to the switch’s login page. After logging in, you can proceed to the Analytics Dashboard.

Summary

Congratulations! You have completed Chapter 9.

You now understand the benefits of AOS-CX NAE and, at a high level, how NAE agents work. You also learned how to obtain NAE scripts, install them, and create agents from them. You also practiced using agents and analyzing the rich set of data and alerts that they produce.

Learning checks

What functions does an NAE agent perform? (Multiple answers can be correct.) Collects data from the current state database and records it in a time-series database

Performs authorization control of management users

Allows you to virtualize legacy switch code within an AOS-CX switch

Triggers actions based on whether a monitored attribute meets a particular condition

Which correctly describes Aruba NAE scripts? All Aruba-certified scripts are loaded on the AOS-CX switch at factory defaults.

You can find Aruba-certified scripts in Aruba Solutions Exchange (ASE) and Github.

Aruba provides support for all NAE scripts, as long as the scripts use Python code.

You are only allowed to load Aruba-certified scripts on AOS-CX switches.

Note: For answers to all learning checks, refer to the Appendix.

10

Implement WIDS/WIPS

EXAM OBJECTIVES

✓ Explain the Aruba WIPS and WIDS technology.

✓ Configure AP rogue detection and mitigation.

Assumed knowledge

Basics of managing ArubaOS mobility devices

WIDS/WIPS definition

Review Aruba WIDS/WIPS

Inherently open, the wireless medium can be vulnerable to a broad array of attacks from malicious attackers, including ones who manage to connect to the wired network as well as those who are simply in the vicinity of the network you are protecting. In this chapter, you will review how Aruba WIDS/WIPS detects all APs and clients in the area and classifies them into various categories.

Why Wireless Intrusion Detection/Protection?

Uncontrolled wireless devices, such as rogue access points (APs), can pose a large security threat to the network (see Figure 10-1). Rogue APs are unauthorized APs that connect to the wired network infrastructure and can potentially provide backdoor access into the wired LAN. Laptops acting as ad-hoc networks, or in bridge mode, are also potential security risks to the wired infrastructure.

Figure 10-1: Why Wireless Intrusion Detection/Protection?

Denial of Service (DOS), Man-In-the-Middle (MITM) attacks, and forged traffic can make the WLAN slow or unusable for legitimate users.

A Wireless Intrusion Detection System (WIDS) provides the network with a level of preventive security against any suspicious activity. The IDS achieves this objective through early warnings aimed at systems administrators. Sometimes these alerts are the best tool for the security team, helping the team to take the next steps to find and mitigate the threat. In a few cases, which you will examine in more detail later, you can enable Wireless Intrusion Prevention System (WIPS) features to mitigate threats automatically.

Wireless Threat Protection Framework

Aruba provides Wireless IDS/IPS features in wireless devices managed with Central that have Foundation or Advanced licenses. If the company is using an AOS 8 architecture, some basic rogue detection and containment features are provided with just AP licenses; however, RFProtect (RFP) licenses are required for the full feature set, including spectrum analysis.

As shown in Figure 10-2, Aruba’s Wireless Threat Protection Framework consists of four main parts: Discover, Classify, Contain, and Alert/Audit. Each process feeds into another for a seamless framework.

Figure 10-2: Wireless Threat Protection Framework

Discover provides complete 802.11 spectrum monitoring and provides continuous monitoring of wireless devices, activity, and configuration across all 802.11 channels.

This carries over into Classify, which applies the policy-based threat prioritization and automatic classification of threats and non-threats to RF security.

The Contain process automates threat mitigation and containment to block any rogue APs or intruders.

Lastly, Alert and Audit complete the compliance reporting by logging and distributing reports to ensure you are in compliance with wireless security policies and regulations.

Review AP classifications

The Aruba system classifies all AP radios detected in the RF environment. It makes its decisions based on several factors, such as if the Aruba AP is part of the enterprise solution, if the AP is visible in the air, and if the AP is visible on the wire. The Aruba system automatically handles the classification for these devices, but an administrator can override it when necessary.

Figure 10-3: Review AP classifications

As shown in Figure 10-3, an authorized AP radio belongs to an Aruba AP that is part of the enterprise solution. In an AOS 8 architecture, the AP is controlled by a mobility controller (MC). In an AOS 10 architecture, it is managed by Central. Administrators can also manually classify AP radios as authorized.

An Interfering AP radio is detected in the RF environment, but has not been detected on the wired network. All APs begin with this classification. You can classify the BSSIDs of Interfering APs as Neighbors. After you classify a radio in this way, the state does not change unless an admin changes it manually.

A suspected rogue AP radio is detected in the RF environment. There are also indications that point toward the AP being attached to the wired network. However, WIDS is not able to determine for certain whether the AP is connected to the wired network. A rogue AP is an AP that has been detected wirelessly, and has been determined with confidence to also be connected on the wired network.

A contained AP is an AP radio that WIPS is containing. An admin might have manually contained the AP, or a WIPS policy might mark the AP for containment.

Review client classifications

The network discovers clients during scanning of the wireless medium, and it classifies them into various groups. The Aruba system automatically handles the classification for these clients, but an administrator can override it when necessary.

As shown in Figure 10-4, Aruba WIDS/WIPS classifies any client that successfully authenticates with a valid AP as authorized. Clients that connect to an open WLAN are not classified as authorized, so typical guest clients do not receive this status.

Figure 10-4: Review client classifications

Admins can manually assign clients to the Contained category if they want the system to contain them (using the configured wired or wireless methods).

All other clients are classified as interfering.

Access point (AP) & Air Monitor (AM) considerations

APs primarily serve clients but can also provide WIPS/WIDS information to their management system, which might be MCs or Central. As shown in Figure 10-5, an AP can only briefly scan each channel because it must usually stay on its own channel to serve clients. Therefore, it can take an AP a while to detect a threat such as a rogue AP operating on a different channel. APs also prioritize client traffic over scanning or containment, especially voice calls and video traffic.

Air Monitors (AM) act as sensors and continuously scan the air, sending all captured information back to the controller and AirWave server. The benefit of an AM is that it can scan nonstandard channels and provide continuous scanning.

Figure 10-5: Access point (AP) & Air Monitor (AM) considerations

You should deploy AMs in extremely high-security environments or environments that require wireless containment. AMs will detect attacks and rogues faster since they are dedicated to scanning channels. AMs scan the 2.51.2-2.484 and 4.9- 5.895 GHz spectrum in 5 MHz increments. They scan the active channels more frequently than regulatory channels, and both those channels more frequently than rare channels. The exact time to cycle through all the channels varies, but generally scanning through all regulatory channels takes approximately 5 minutes.

If the company plans to use wireless containment, they should typically use AMs because APs cannot spend enough time on the contained device’s channel to operate as effectively.

Aruba recommends a 4:1 AP to AM ratio. However, it depends on the density of APs and the type of building. For example, if you deploy the APs densely for a voice deployment, a 5:1 ratio will work. Note that when you deploy AMs, WIDS/WIPS can draw on data from both AMs and APs.

To create an Air Monitor, you will need to complete the following steps:

First, create a new AP Group dedicated to Air Monitors.

Then, provision a new group as air monitors in the RF Management Profile.

Then you will need to assign appropriate access points to the new AM Group.

Lastly, confirm AM mode with show ap database and show ap active.

Review AM deployment recommendations for rogue AP detection

As shown in Figure 10-6, Aruba generally recommends deploying about one AM per four or five APs in order to obtain good WIDS/WIPS coverage.

In addition to considering RF coverage for the WIDS/WIPS solution, consider how the solution will detect whether unauthorized APs are connected on the wired network. Exactly how WIDS/WIPS detects rogue APs might differ slightly based on the AOS architecture. However, in general, WIDS/WIPS builds a list of “wired MACs” detected in the air. These are the source MAC addresses that APs transmit within 802.11 frames, which belong to clients in the wired LAN behind the AP. WIDS/WIPS compares the air-detected wired MACs against MAC addresses that it knows exist in the corporate LAN. If it finds matches or close matches, it knows that the AP is or might be connected to the corporate LAN. WIDS/WIPS can learn the corporate LAN MAC addresses in several ways, including APs/AMs reporting their default gateway MAC addresses, APs/AMs snooping ARP traffic on their VLANs, and even from MCs in an AOS 8 architecture.

Figure 10-6: Review AM deployment recommendations for rogue AP detection

To ensure rogue AP detection works correctly, make sure that the Aruba solution has at least one device in each VLAN to which rogue APs might connect. One common way to achieve this goal is to extend all the VLANs in each area to AMs in that area.

Configure WIDS/WIPS

Next, you will learn about configuring WIDS/WIPS policies, focusing on practical guidelines for which options to enable or not.

How to configure IDS/IPS

Aruba recommends the WIP Wizard when configuring IDS profiles and policies in the MM or standalone MC. Additionally, advanced users can use the CLI to configure IDS profiles.

Figure 10-7: How to configure IDS/IPS

As shown in Figure 10-7, if you are using APs, preferably managed in Central, you specify the IDS and IPS settings within the Security settings. You can select the custom option and then choose the particular options to enable and disable. Note that the Central interface shown in Figure 10-7 might look slightly different from what you see in your Central interface as versions change; however, similar concepts continue to apply. The same holds true for all Central screenshots in this study guide.

The risks of false positives

It might seem that the more IDS settings that you enable—the more possible threats that the Aruba WIDS system can detect—the more secure the system. However, the reality is different. Some settings are more prone to creating false positives than others in some environments. False positives occur when normal behavior creates a similar effect as a potential threat. False positives create risks of their own because they distract admins and train them to not believe or investigate alerts. In some cases, particular settings search for threats that no longer pose a great threat in modern networks. It is best to disable settings that are unlikely to detect real threats of concern to most customers in most environments.

When determining which IDS and IPS settings to enable, consult with the company's security team, and use their recommendations. If the team is uncertain which settings to enable and asks you for guidance, you can use the Aruba recommendations as a starting point. The rest of this section covers which settings Aruba recommends that you should enable. Disable all other IDS settings to prevent distracting false positives.

Recommended infrastructure IDS settings

Detect AP spoofing

As shown in Figure 10-8, an Aruba AP detects the AP spoofing attack when it detects another AP using its BSSID. An AP should never hear traffic from its own radio since it cannot send and receive at the same time. If it does, then an intruder is spoofing the AP. WIDS could classify the spoofing AP as an Interfering AP, if it is not connected to the LAN, or as a Rogue AP, if it is connected to the LAN.

Figure 10-8: Detect AP spoofing

This attack indicates a hacker who is attempting to deceive devices into connecting to it. Spoofing a BSSID is trivial with common software, and posing as a legitimate AP forms the foundation for many attacks. The spoofing AP can lure clients to connect to it in an attempt to obtain the users’ credentials or to launch an MITM attack. Note, however, that if clients are properly configured to use 802.1X with certificate-based authentication, as well as to validate the RADIUS server, they should be protected from some of these attacks. However, AP spoofing does indicate a hacker who is attempting to cause harm.

You can optionally enable Detect AP Impersonation if the customer is highly security minded. This feature detects much the same attack as the Detect AP Spoofing feature; however, it can be prone to false positives.

Detect Valid SSID Misuse and Detect Adhoc Using Valid SSID

The Aruba WIDS solution can detect any stray APs masquerading as valid APs and advertising one of a company’s SSIDs, although not necessarily with the same BSSID. Again, such a circumstance often indicates a hacker who is attempting to steal users’ credentials or launch other attacks. As shown in Figure 10-9, Aruba recommends enabling the “Detect Valid SSID Misuse” IDS setting to detect these APs. WIDS might classify the APs detected by this feature as either Interfering APs or Rogue APs, depending on whether the AP is connected to the LAN.

Figure 10-9: Detect Valid SSID Misuse and Detect Adhoc Using Valid SSID

As shown in Figure 10-9, Aruba also recommends enabling “Detect Adhoc Using Valid SSID.” This feature detects ad hoc networks that are using the company’s SSIDs.

However, Aruba recommends leaving the “Detect Adhoc Network” setting disabled. This setting detects all ad hoc networks regardless of the SSID. Because many devices can create these networks by default, this setting can produce many false positives.

The following are two log outputs associated with the “Detect Valid SSID Misuse” setting. The first log is for an interfering AP that is misusing the SSID, but is not connected to the wired infrastructure:

The network does not detect AP connected to wired infrastructure: (wips) #show log security all

May 17 06:15:17 :103062: |ike| Starting cryptoPOST

May 17 06:15:54 :118004: |certmgr| Received unknown message

May 17 06:16:28 :125022: |aaa| Authentication failed for User admin, Logged in from 192.168.50.248 port 49338, Connecting to 192.168.50.3 port 22 connection type SSH

May 17 06:17:58 :126005: |wms| |ids| Interfering AP: The system classified an access point (BSSID 00:1c:10:a5:5e:30 and SSID wips-test on CHANNEL 1) as interfering. Additional Info: Detector-AP-Name:WIPS-AP-7d:3c; Detector-AP-MAC:d8:c7:c8:87:d3:c0; Detector-AP-Radio:2.

May 17 06:17:58 :126007: |wms| |ids| AP(d8:c7:c8:87:d3:c0@WIPS-AP-7d:3c): Multi-tenancy SSID Violation: An AP detected an access point (BSSID 00:1c:10:a5:5e:30 and SSID wips-test on CHANNEL 1) is violating Valid SSID configuration by using a protected SSID.

AP connects wired infrastructure: (wips) # show log security all

May 17 06:38:41 :103062: |ike| Starting cryptoPOST

May 17 06:39:18 :118004: |certmgr| Received unknown message

May 17 06:43:48 :126005: |wms| |ids| Interfering AP: The system classified an access point (BSSID 00:1c:10:a5:5e:30 and SSID personal-AP on CHANNEL 1) as interfering. Additional Info: Detector-AP-Name:WIPS-AP-7d:3c; Detector-AP-MAC:d8:c7:c8:87:

d3:c0; Detector-AP-Radio:2.

May 17 06:43:49 :106000: |AP WIPS-AP-7d:3c@192.168.50.250 sapd| |ids-ap| AM d8:c7:c8:87:d3:c0: Potentially rogue AP detected BSSID 00:1c:10:a5:5e:30 SSID personal-AP MATCH MAC 00:1c:10:a5:5e:30.

May 17 06:43:49 :126002: |wms| |ids| Rogue AP: The system classified an access point(BSSID 00:1c:10:a5:5e:30 and SSID personal-AP on CHANNEL 1) as rogue. Additional Info: Detector-AP-Name:WIPS-AP-7d:3c; Detector-AP-MAC:d8:c7:c8:87:

d3:c0; Detector-AP-Radio:2.

Detect broadcast deauthentication and disassociation

A de-authentication broadcast attempts to disconnect all stations in range. Rather than sending a spoofed deauth to a specific MAC address, this attack sends the frame to a broadcast address, as shown in Figure 10-10. In a similar attack, hackers send disassociation frames to the broadcast address. Aruba recommends enabling the settings for detecting both of these threats.

Figure 10-10: Detect broadcast deauthentication and disassociation

Detect Windows bridge

Many endpoints with both wired and wireless interfaces, including Windows clients, are capable of bridging between the interfaces. When a Windows client is connected to the corporate LAN and bridges between its wireless and Ethernet NIC, it can open a backdoor into the corporate LAN. A hacker who gains temporary access to the corporate LAN might set up such a client to provide remote access later. Or, a user might implement this setting without realizing the risks. Hackers can then use the client’s insecure wireless network to gain internal access to the corporate network, perhaps even from outside the building. In either case, the Windows bridge poses a risk to the network.

Figure 10-11: Detect Windows bridge

As shown in Figure 10-11, the “Detect Windows Bridge” setting enables the Aruba solution to detect this situation. Aruba recommends enabling this setting, as it produces few false positives and can alert admins to issues.

Log output for this function:

(wips) #show log security all

May 17 11:28:44 :103062: |ike| Starting cryptoPOST

May 17 11:29:15 :118004: |certmgr| Received unknown message

May 17 11:37:46 :126042: |wms| |ids| AP(d8:c7:c8:87:d3:c0@WIPS-AP-7d:3c): Windows Bridge: An AP detected a bridge on CHANNEL 6 between access point (BSSID d8:c7:c8:87:d3:c0 and SSID and a node 24:77:03:2a:70:20.

Detect Wireless Bridge

A wireless bridge establishes a point-to-point link between two 802.11 radios. If a hacker manages to connect a rogue AP to the LAN, the hacker might establish a wireless bridge from that AP to a second AP outside the corporate office. In this way, the hacker can obtain access into the network from an external location. Aruba recommends enabling the “Detect Wireless Bridge” IDS setting to alert admins to potential security holes.

Figure 10-12: Detect Wireless Bridge

If the Aruba mobility solution includes Aruba wireless meshes, those meshes will not trigger the “Detect Wireless Bridge” feature. If the company is using authorized third-party wireless bridges, however, you must mark those bridges as valid manually, as shown in Figure 10-12.

Recommended client IDS settings

Aruba recommends enabling three client IDS settings.

With “Detect Valid Client Misassociation,” the Aruba solution detects whenever an authorized client connects to any unauthorized AP. WIDS might classify that unauthorized AP as a Rogue AP, Interfering AP, or Neighbor AP. Misassociations can indicate that a hacker has successfully lured the client to connecting to the hacker’s AP, which could be the first step in another attack.

Figure 10-13: Recommended client IDS settings

As shown in Figure 10-13, Aruba also recommends enabling “Detect Omerta Attack.” The Omerta attack is a DoS attack in which the hacker device sends dissociation frames on all channels.

You should also enable the “Detect Unencrypted Valid” setting, which will alert admins when authorized clients are connected to open WLANs. Many clients connect to open WLANs without the users’ awareness. Hackers can take advantage of that fact to connect to clients and attempt to install malware or launch an MITM attack. However, if the Aruba solution itself includes an open WLAN, do not enable this setting, as it will lead to many false positives. In addition, you should be aware that Apple devices often create open WLANs by default, so, if the environment includes these devices, you will receive many false positives.

Possible IDS settings for highest security environments: tuning required

Aruba WIDS can detect a variety of issues that might indicate DoS attacks, such as floods of various types of frames. However, these settings are also prone to triggering many false positives. For example, issues with client drivers or drivers on neighboring APs can cause the devices to send many RTS or CTS frames. Many clients also save power aggressively, which can look like a power save attack. The same holds true for all of these settings; they might indicate a DoS attack, but are also likely to trigger false positives:

Infrastructure

Detect AP Flood

Detect RTS Rate Anomaly

Detect CTS Rate Anomaly

Detect Client Flood

Clients

Detect Power Save DoS Attack

Detect Disconnect Station

Detect Block ACK Attack

Detect Rate Anomalies

Detect EAP Rate Anomalies

You should leave these settings disabled in many circumstances. However, some highly security conscious customers will want to enable these settings. As shown in Figure 10-14, you should enable the settings only if you also tune them.

These settings all come with thresholds. For example, the RTS Rate Anomaly triggers when a wireless device sends more RTS frames within a certain time period than the configured threshold allows. You should not leave the default thresholds, as doing so is likely to trigger many false positives. Instead you must analyze the customer’s particular environment over a period of time to create baselines. How many frames of each type do wireless devices normally send over various time periods, such as one minute and five minutes? What is truly anomalous? You can then set the thresholds based on these baselines.

Figure 10-14: Possible IDS settings for highest security environments: Tuning required

Possible IDS settings for highest security environments

The “Detect Overflow EAPOL key,” “Detect Overflow IE,” “Detect Malformed Frame Association Request,” “Detect Malformed Frame Auth,” and “Detect Malformed Frame-HT IE” settings detect various malformed frames. These frames might indicate DoS attacks, but can also occur due to driver issues such as on third-party APs. As shown in Figure 10-15, Aruba recommends leaving these settings disabled unless a highly security minded company requires them. In that case, only enable them if the Aruba WIPS solution is monitoring an Aruba WLAN solution.

Figure 10-15: Possible IDS settings for highest security environments: Settings for

higly security minded companies

The “Detect Invalid Address Combination” triggers when wireless frames have invalid addresses such as a broadcast or multicast address for the source. While an invalid address combination can indicate a DoS attack, it much more often occurs innocently due to bad drivers. Only enable this setting if required by the company and if the company manages, tests, and tracks all client devices.

Optional client IDS settings for particular use cases

The settings shown in Figure 10-16 are for specific use cases.

“Detect FataJack” detects attacks from FATA-Jack, an 802.11 client DoS tool. This tool disconnects targeted stations using spoofed authentication frames that contain an invalid authentication algorithm number. Aruba recommends enabling this setting only if you are monitoring open WLANs in a public setting.

Figure 10-16: Optional client IDS settings for particular use cases

The TKIP replay attack only affects WLANs that are using TKIP, which is an outmoded encryption method. It is best to remove TKIP and use AES instead. However, if legacy devices require retaining support for TKIP, you can enable the “Detect TKIP Replay Attack” feature.

The “Signature ASLEAP” feature detects attacks on ASLEAP, which is a Cisco protocol. Only enable this setting if you are using Aruba WIDS/WIPS to monitor a Cisco WLAN.

If you are using an AOS 8 architecture, WIDS has a “Detect Misconfigured AP” setting. This feature checks whether authorized APs are using the settings indicated with a parameter list. Because the Aruba solution handles configuring APs correctly, you would only enable this setting if you are using Aruba WIPS to monitor a third-party WLAN solution.

Review intrusion prevention mechanisms

Aruba WIPS supports methods for containing detected threats from APs or clients. You can enable wired containment, wireless containment, or both.

Wired containment

As shown in Figure 10-17, wired containment uses ARP cache poisoning for each IP address of the contained device (AP or station) at the rate of one per second. Specifically, the hybrid AP/AM sends an ARP response that claims to be from the contained device’s default gateway, but has an incorrect MAC address. As a result, the contained device cannot forward traffic out of the subnet. For wired containment to work, the hybrid AP/AM must be able to transmit traffic on the VLAN on which the contained device is connected. You should deploy AMs on trunk ports that allow all VLANs to which devices might connect.

Figure 10-17: Wired containment

Be aware of the settings on the switch to which the Aruba AP/AM implementing wired containment connects. If the switch implements dynamic ARP inspection on this port, the switch will drop the AP/AM’s message. (It is an ARP poisoning attack.) Make sure the AP/AM’s switch port is configured as a trusted port for ARP inspection.

Wireless containment

If you choose to enable wireless containment, you can choose between deauthentication only or tarpit containment. As shown in Figure 10-18, wireless containment of an AP attempts to disconnect all clients from that AP. Wireless containment of a client attempts to disconnect just that client.

Figure 10-18: Wireless containment

You should be aware of the legal implications of both of wireless containment methods. Wireless containment in certain circumstances is prohibited by the FCC. You must always consult with a company’s security and legal teams before enabling these mechanisms.

Deauthentication only

With this method, the Aruba hybrid AP/AM sends de-authorization messages to disconnect a client from the rogue AP. The AP impersonates the MAC address of the rogue APs when it sends the de-authorization messages to the client. The AP also impersonates the MAC address of the client when it sends de-authorization messages to the rogue AP.

Though this procedure is effective, it is also disruptive to the nearby stations. Each of these de-­authorization messages requires airtime to transmit. Unlike with tarpitting, the client will detect that it disconnected from the rogue AP and probably attempt to reconnect automatically. Thereover, the Aruba AP/AM must continuously send wireless de-authorizations.

Tarpit

With tarpit shielding, the AP/AM deauthorizes clients from the contained AP. (Or if containing a client, it deauthorizes that one client.) But tarpit involves further steps to prevent clients from trying to continually reconnect to the contained device. The AP/AM copies the contained AP’s probe response, but with a different BSSID, different channel, or both. This probe response gets clients to connect to the AP/AM instead of the contained AP. The AP/AM then ignores the traffic from that client. When a client is successfully tarpitted, most client drivers report that the client is “connected.” Users can see that their device did not get an IP address and cannot pass data, so they may attempt to reconnect to the rogue network. However, without user intervention, the client remains in the tarpit.

The client eventually stops trying to send data to the AP/AM. If the user tries to connect to the contained AP again, the client is lured into the tarpit again. This method is very efficient, because each AP, or AM, near the client can participate without spending much time on the channel. The network can also spread containment across multiple nearby APs or AMs, so that whichever is available to handle the containment can do so.

For tarpit containment of an AP, you can choose to have APs/AMs tarpit all clients that attempt to connect to the contained AP, or just non-authorized clients.

Recommended IPS settings: Use wired containment against rogue APs

As shown in Figure 10-19, Aruba recommends that among the Protection > Infrastructure options, you enable only “rogue containment.” Aruba also strongly recommends that you leave wireless containment disabled and enable wired containment instead. Wired containment poses fewer legal risks than wireless containment because the wired network belongs to the organization in question. However, you should still consult with the security and legal teams for authorization to use wired containment.

Figure 10-19: Recommended IPS settings: Use wired containment against rogue APs

If you are using only wired containment, you might also enable the “Protect Windows Bridge” setting under Protection > Clients Protection. This would disconnect the bridging client from the wired network and leave it connected to the wireless network only. However, you would need to investigate the situation. Get the client properly configured so that it no longer bridges and can safely connect to the wired network.

Aruba 8.0 architectures support several more Infrastructure Protection mechanisms. Aruba strongly recommends disabling these options for several reasons:

Risks of disruption and large amounts of hybrid AP/AM time spent protecting against false positives: – Protecting 40MHz 802.11 High Throughput Devices

– Protecting 802.11n High Throughput Devices

– Protecting Against Ad hoc Networks

Risks of regulatory fines: – Protecting SSIDs

– Protection Against Misconfigured APs

– Protection Against Wireless Hosted Networks

– Suspected rogue containment at any confidence level

Considerations for Protect Valid Stations

For some highly security-minded customers, you can enable the “Protect Valid Stations” option for Clients Protection as shown in Figure 10-20. This setting deauthenticates authorized clients from unauthorized APs, guarding the clients from malicious APs set up by hackers. For this setting to work, you must enable wireless containment, as the containment is applied to the wireless client. But, because this setting targets only authorized clients, which presumably belong to the company, it comes with fewer legal considerations than some of the other protection options.

However, you must keep several caveats in mind. First, carefully consider the customer environment. Is the corporate environment relatively isolated? If not, this feature could pose problems. Authorized clients might attempt to connect to hotspots at nearby restaurants, coffee shops, and similar locations. If legitimate hotspot APs are within range of the Aruba WIDS/WIPS solution, you should not enable this setting.

Figure 10-20: Considerations for Protect Valid Stations

Also consider whether the company allows BYOD. If users are bringing their own devices into the corporate LAN, those devices belong to the users, but are marked as authorized clients. The company has less legal standing to control whether the BYOD devices connect to non-authorized APs.

Finally, consider the following situation. You have enabled “rogue containment” and “wired containment,” as suggested in the “Recommended IPS settings: Use wired containment against rogue APs” section. You then enable “protect valid stations” and a wireless containment option. Now Aruba WIPS will also target Rogue APs with wireless containment because the containment methods apply to all enabled protection options. You must consult with both the company’s security team and legal team before you can enable wireless containment for any of the Infrastructure Protection options.

Investigation rather than automatic containment

When you follow Aruba recommendations, WIDS will detect more threats than WIPS automatically contains. This behavior is desired because it enables you to investigate and mitigate threats with fewer risks. For example, rather than enable automatic protection against APs impersonating valid APs, you should investigate such APs as you are alerted to them.

As shown in Figure 10-21, you should make a list of the APs/AMs that detected the threat and triangulate between them to find the likely area for the threat. Search the area for unauthorized devices. Question employees about possible unauthorized people in the area at the time the alert was triggered. Is there a legitimate explanation for the threat, or is this a likely instance of a hacker attempting to impersonate an authorized AP?

Figure 10-21: Investigation rather than automatic containment

Only after a thorough investigation and approval from the security and legal team, you might choose to manually mark the AP that triggered the alert as Contained. However, containing is not always the right approach. Consider an AP that is spoofing an authorized AP’s BSSID. Attempting to contain that AP could cause a DoS against the legitimate network. Instead you should remove the interfering AP manually. In addition, you generally want to remove rogue APs rather than contain them over the long term.

Remember that you can implement 802.1X on all Ethernet ports to reduce the risks of unauthorized devices connecting to the network in the future.

Summary

Congratulations! You have completed Chapter 10.

You now have a better understanding of how to formulate and implement WIDS/WIPS policies for particular environments. You have seen how Aruba WIDS can alert you to threats, and you can take next steps to investigate those threats.

Learning checks

What distinguishes a Rogue AP from an Interfering AP? A Rogue AP has launched a DoS attack.

A Rogue AP is connected to the corporate LAN.

A Rogue AP uses unauthorized security settings.

A Rogue AP is connected to Interfering clients.

What are some Aruba recommendations for IPS and IDS settings to enable? (Select two.) Enable all IDS settings.

Enable all IPS settings.

Enable IDS settings that are unlikely to produce false positives.

If automatic containment is required, enable rogue AP containment with wireless deauthentication.

If automatic containment is required, enable rogue AP containment with wired containment.

Note: For answers to all learning checks, refer to the Appendix.

11

Use CPPM and Third-Party Integration to Mitigate Threats

EXAM OBJECTIVES

✓ Describe log types and levels and use the Aruba ClearPass Policy Manager (CPPM) Ingress Event Engine to integrate with third-party logging solutions.

✓ Set up integration between the Aruba infrastructure and CPPM, allowing CPPM to take action in response to events.

Assumed knowledge

Fundamental CPPM components, such as services, roles, enforcement profiles, and enforcement policies Syslog basics

Syslog basics

CPPM ingress event engine

By integrating with third-party security solutions in Aruba 360 Security Exchange, Aruba ClearPass Policy Manager (CPPM) enables companies to respond to threats more quickly and comprehensively.

This chapter explains how to use the CPPM Ingress Event Engine to interpret messages from event sources such as firewalls and other security appliances. You will examine Ingress Event Dictionaries and see how they enable CPPM to parse Syslog messages and extract meaningful attributes from them.

Review of Aruba ClearPass 360 Security Exchange

Aruba solutions integrate with more than 150 third-party solutions in the ClearPass 360 Security Exchange. Through Exchange, Aruba solutions, including CPPM, can share information with the security appliances of companies’ choice. The solutions operate in a mutually beneficial partnership, in which they provide information of interest to each other and enhance each other’s abilities. As you will see, for example, an IDS can inform CPPM that an endpoint is generating an attack. CPPM can then order the network infrastructure to lock the endpoint out of the network.

Figure 11-1: Review of Aruba ClearPass 360 Security Exchange

You can see some of the 360 Security Exchange partners listed in Figure 11-1. For a more comprehensive and up-to-date list, visit the Aruba Technology Partner Finder (which can be found at: https://www.arubanetworks.com/partners/technology-partners/partner-finder) and search for 360 Security Exchange partners in categories of interest to you.

Categories of third-party integration

CPPM can integrate with third-party security appliances in many ways—all based on the third-party solutions’ capabilities and what the company wants to achieve. But you can start to think about the capabilities in two broad categories: context servers and event sources.

Figure 11-2: Categories of third-party integration

Context servers

CPPM can integrate with “context servers,” which include mobility device management (MDM) solutions, enterprise mobility management (EMM) solutions, device management solutions, and security solutions. As shown in Figure 11-2, these solutions can send CPPM information about endpoints, which CPPM can use as context in role mapping and enforcement policies. For example, you learned how CPPM can learn about endpoints’ security posture from third-party devices in a previous chapter.

CPPM also collects a broad array of information about clients, using its authentication and authorization capabilities, as well as the device profiling abilities that you will learn about in the next chapter. CPPM can send this information to third-party solutions, which are called “context servers.” Those solutions can then use that information to enhance their insight into clients and users and take more informed actions.

CPPM can also send requests to the context server to perform particular actions using the API of the particular context server in question.

Event sources

As shown in Figure 11-2, CPPM can also receive Syslog messages from third-party solutions set up as event sources. It can use its Ingress Event Engine to parse those messages and take actions. You will focus on this second category of integration for the rest of this chapter.

Ingress Event Engine overview

Event sources, such as third-party firewalls, send Syslog messages to CPPM. In the example shown in Figure 11-3, a firewall has detected an attack that originates with client A. The firewall is configured to log attacks of this type to CPPM.

CPPM’s Ingress Event Engine receives the message and determines whether it comes from a defined source. If so, it processes it using an Ingress Event Dictionary. Assuming that a valid dictionary exists for the message, CPPM generates an event.

Figure 11-3: Ingress Event Engine overview

As shown in Figure 11-3, CPPM can then process the event with an event service. Like all services on CPPM, this enforcement service can take various actions based on the policies you define within it.

Review Syslog

Syslog is an open standard used by many devices. Syslog uses a client-server framework. For the use case on which you are focusing, the Syslog client is the security appliance. It sends log messages to a Syslog server, which is CPPM in this use case.

Figure 11-4: Review Syslog

Syslog messages include a severity rating. As shown in Figure 11-4, the categories range from debugging at the lowest level of severity through emergency. Individual vendors decide how they assign severity levels to logs for various events. Generally the levels are understood to mean:

Debugging—Very detailed logs about processes, intended only for troubleshooting or debugging a function

Information—Logs about routine events and processes

Notification—Logs about normal occurrences, but ones that might require notice (such as an interface coming up)

Warning—Logs about events that might cause issues

Error—Logs about events that are very likely to cause issues

Critical—Logs about critical issues on a system

Alert—Logs about critical issues that need immediate attention

Emergency—Logs about issues that are causing widespread issues and need immediate attention

Syslog messages also include a facility, which indicates the general type of source that creates the log. For example, facility 13 is for security programs.

Considering the effects of ingress event processing

Using the Ingress Event Engine can be CPU-intensive. You need to consider how you use it to avoid overwhelming a ClearPass server and preventing it from responding to other requests.

Figure 11-5: Considering the effects of ingress event processing

As shown in Figure 11-5, you can safely enable ingress event engine processing on a CPPM server that will only receive a few Syslog messages per hour. This is the scenario you would expect if security appliances are just sending logs when threats occur.

CPPM is not intended for processing bulk Syslog messages. If you need a server to receive and process many Syslog messages per hour, you should add another server to the cluster and dedicate it to ingress event processing.

Enabling ingress event processing and insight

After you have determined which servers you want to process ingress events, you can enable ingress event processing on them. To enable ingress event processing, use the left menu in the CPPM UI to navigate to Administration > Server Manager > Server Configuration. Select the server that you want to use, as shown in Figure 11-6.

In the page that appears, make sure you are in the System tab. Click the Enable Ingress Events Processing check box, and save the new configuration. You will see a warning related to the CPU intensity, as previously mentioned. Click Yes to dismiss the warning.

Figure 11-6: Enabling ingress event processing and insight

You must also enable Insight, which enables CPPM to perform tasks like correlating IP addresses and MAC addresses. In that way, it helps CPPM figure out which endpoint is associated with an event.

Repeat this step on any other ClearPass servers in the cluster that you want to process ingress events.

Examples of event sources

The event sources from which CPPM receives Syslog messages are third-party security appliances. CPPM v6.10 comes loaded with dictionaries for interpreting Syslog messages for several third-party devices, including:

Check Point firewalls

Palo Alto Next Generation Firewalls (NGFWs)

Juniper SRX firewalls

Infoblox platform, which provides network device management, as well as detection of malware

You can also create and add your own custom dictionaries to enable CPPM to process Syslog messages from any system set up as a Syslog client. However, creating custom dictionaries is an advanced topic beyond the scope of this study guide.

Defining an event source

Even when a ClearPass server has ingress event processing enabled on it, CPPM only accepts and processes Syslog messages from a defined event source. If a Syslog message comes from an unknown source, CPPM will not act on the message.

Figure 11-7: Defining an event source

To define an event source, use the left-hand menu in CPPM’s interface to navigate to Configuration > Network > Event Sources. Click Add. Then fill in the information as shown in Figure 11-7. Click Add in the pop up window to confirm the new event source.

Avoiding spoofed event sources

Ironically, the Syslog messages that are meant to alert CPPM to threats can also become an attack vector. By spoofing their IP address, bad actors can pose as a legitimate event source.

As shown in Figure 11-8, a hacker could launch a DoS attack by sending a high volume of Syslog messages to CPPM. Processing the Syslog messages could compromise the ClearPass server’s ability to respond to other service requests, which could cause authentication issues throughout the network.

Figure 11-8: Avoiding spoofed event sources

As shown in Figure 11-8, a hacker could also poison CPPM by sending a message that designates a legitimate client as a threat, thereby causing CPPM to deny or restrict access to that legitimate client.

To prevent both of these attacks, you need to take steps within the network infrastructure to prevent IP spoofing. You learned about such measures in a previous chapter.

Ingress Event Dictionaries

While Syslog severity and facility have defined values, the message content itself is simply a string, meant to be human readable. Because the content has no fixed fields or attribute value pairs (AVPs), interpreting logs can pose a challenge for automation. How can you automate interpreting the message and triggering a response based on the content?

Figure 11-9: Ingress Event Dictionaries

This is where CPPM’s Event Ingress Dictionaries come in. As shown in Figure 11-9, these dictionaries enable CPPM to interpret Syslog messages from supported event sources and parse them into events with AVPs. You can then use the known attribute names to create profiles and policies to automate responses.

How the Ingress Event Dictionary works

When CPPM receives a Syslog message from an event source, its Ingress Event Engine finds an Ingress Event Dictionary for that source type that can parse the message. The dictionary breaks the message into pieces and defines an attribute with which each piece is associated.

Figure 11-10: How the Ingress Event Dictionary works

For example, this dictionary indicates that the first element in a particular type of log is the time. The second element is the hostname of the firewall. And the third element is the application name.

As shown in Figure 11-10, the Ingress Event Engine can use the dictionary to transform a log into an event with a list of attributes. You can now reference the time attribute for the event and receive the time at which the event occurred. Similarly, you can reference any of the attributes compiled for the event using the dictionary. Later you will see how to reference the application-name attribute, for example, to output the name of the threat detected by the firewall.

This parsing is a crucial step in processing network events, because it bridges the detection of events to the ability to respond to them.

Enabling Ingress Event Dictionaries

Ingress Event Dictionaries are disabled by default. To make use of them, you must first determine which Syslog messages your event sources will send. Work with the security appliance admins to coordinate. Then navigate to Administration > Dictionaries > Ingress Events. As shown in Figure 11-11, you can then locate the dictionaries associated with your appliance vendor and enable them.

Figure 11-11: Enabling Ingress Event Dictionaries

Using Ingress Events to respond to threats

Next, you will learn about using ingress events to respond to threats. You will see how CPPM can “read” a Syslog message about a particular endpoint and use an event service to update the endpoint profile. You will further learn how you can configure your existing services to take the new information into account and block endpoints that pose a threat to your system.

Overview of using events to mitigate threats

After the Ingress Event Engine has generated an event based on the Syslog message, CPPM can use that event to perform actions. You will now look at an example of this process in more detail.

When CPPM receives an event from an event source, it processes the event with an event service. This service includes an event policy with a rule that matches an attribute in the event. This rule applies a post-authentication profile to the client in question. In the example shown in Figure 11-12, the post-authentication profile updates the client’s endpoint profile on CPPM, marking the client as being compromised.

Figure 11-12: Overview of using events to mitigate threats

The policy rule also applies a second profile, which terminates the client session. CPPM sends a change of authorization (CoA) to the network device to which the client is connected. The network device then disconnects the client, and the client is forced to re-authenticate.

The client reauthenticates against an 802.1X service. This service has an enforcement policy with a rule that selects compromised clients. This rule denies the client access. Or it might apply a profile that sets the Aruba-User-Role to a remediation role set up in the network infrastructure. That remediation role would provide very limited access.

Remember the importance of tuning the CoA delay if you have a cluster deployment, as you learned when enforcing posture and health checks. One ClearPass Subscriber might process the event and issue the CoA while another Subscriber reauthenthicates the client. Make sure that the first Subscriber delays the CoA long enough for the endpoint’s attributes to be updated across the cluster.

Event service configuration overview

To set up CPPM to function as illustrated in Figure 11-12, you need to configure an event service, which references an event enforcement policy. The event enforcement policy matches attributes in an event with the enforcement profiles that CPPM should apply when that event occurs.

Typically, you should associate each condition with several enforcement profiles. A post-authentication profile updates endpoint attributes with information delivered by the event source. The other profiles are RADIUS CoA profiles such as “Aruba OS-Wireless Terminate Session” and “AOS-CX Disconnect;” these profiles ensure that CPPM forces the client to reauthenticate and receive a new access level based on its new attributes.

Figure 11-13: Event service configuration overview

Begin by creating the post-authentication profiles, as shown in Figure 11-13. Then create the event enforcement policy, which maps events to the profiles to apply. Finally, create an event service and reference the event enforcement policy in that service.

Defining a post-authentication enforcement profile to update endpoint attributes

Now you will look at the enforcement profile that CPPM will use to update the endpoint profile.

In this study guide, you have concentrated primarily on RADIUS and TACACS+ enforcement profiles, which CPPM applies while enforcing 802.1X or other authentication services. A post-authentication profile, on the other hand, applies to clients after they have authenticated.

Figure 11-14: Defining a post-authentication enforcement profile to update endpoint attributes

CPPM supports several types of post-authentication profiles. For the scenario shown in Figure 11-14, you want to update a client’s endpoint attributes based on AVPs within the event being processed by the event service. The correct type is “ClearPass Entity Update Enforcement,” which updates the information and attributes in an endpoint’s profile. Figure 11-14 shows where you set this type when you create the profile.

Click the Attributes tab to configure the attributes that you want to add to the endpoint profile. For this scenario, you want to add the “Compromised” attribute and set it to true. Set the Type to Endpoint and the Name to Compromised in this example. Then specify the value. For “true”/”false” values, selecting the checkbox sets the value to true. Click Save once you finish.

CPPM supports several other types of post-authentication profiles as well, including:

Session Notification Enforcement—This type of profile sends information to an external context server, such as a firewall.

Session Restrictions Enforcement—This type of profile enables CPPM to enforce restrictions on the resources that clients consume.

Gathering additional attributes for the post-authentication profile

Often you will also want to record additional information about the threat in the endpoint profile. This information is also recorded in endpoint attributes.

Valid attributes for endpoint profiles are defined in CPPM’s Dictionary Attributes. Examples include Threat Category, Threat Name, Threat Timestamp, and several others. You can find the names of all the attributes on your ClearPass cluster in the Administration > Dictionaries > Dictionary Attributes page; look for attributes with “Endpoint” as the Entity. You can also define your own attributes on this page.

Figure 11-15: Gathering additional attributes for the post-authentication profile

After you have selected each attribute that you want to add to the profile, you need to determine how CPPM will derive the value for that attribute. Typically these values come from information within the security appliance’s Syslog message. Remember that an Ingress Event Dictionary parses a Syslog message into an event with a series of AVPs. You can look in the Ingress Event Dictionary to find the names of all of the attributes for events generated by this dictionary.

The bottom of the list can give you a good place to start looking. As shown in Figure 11-15, a few of the attributes are additionally mapped to “Generic Name” attributes, which are used by multiple event types. In the example, a Juniper-SRX-TS Ingress Event Dictionary creates a “Juniper-SRX-TS:attack-type” AVP from the Syslog message and also creates a generic “Threat-Name” AVP with the same value.

Now you can put this information together to define an attribute for the post-authentication profile. Suppose you want to add the Threat Name attribute to an endpoint profile, as triggered by Juniper-SRX-TS events. Within the post-authentication enforcement profile, set the attribute type to Endpoint and the Name to Threat Name, as shown in Figure 11-15. For the value, specify a variable: %{Event:Threat-Name}.

You can also reference an event’s non-generic attributes in variables. In this case, you include the prefix in the variable. The format is: %{Event:prefix:attribute}.

Sometimes it might not be obvious to you which non-generic attributes for an event correspond to which type of information. You can meet with security appliance admins to get help. For example, you could tell the admins that you want to extract the threat category from a log from a Juniper SRX firewall. The admins could point out the piece of the log that provides this information. You can then look in the corresponding Ingress Event Dictionary’s Format section to find the attribute that corresponds with the pinpointed piece of the log. In the example shown in Figure 11-16, that is the “message-type” attribute.

Figure 11-16: Another example of attributes for the post-authentication profile

Therefore, when you define the Endpoint Threat Category attribute in the post-authentication profile, you use this value: %{Event:Juniper-SRX-TS:message-type}, as shown in Figure 11-16.

You can also work with security admins to perform test runs of the solution. Access Tracker will show the event processed by the event service. You can look in the Access Tracker record to find the event attributes. Then you can copy the attribute name from there to avoid making mistakes.

Defining an event enforcement policy

You next need to create an event enforcement policy in which you define the rules to trigger the post-authentication profiles. Navigate to Configuration > Enforcement > Policies and add a new policy. Set the Enforcement Type to Event.

Then click the Rules tab. You can then define the condition that the event must match in order for CPPM to apply the post-authentication profile.

Figure 11-17: Defining an event enforcement policy

For this scenario, you want your post-authentication profile to apply whenever CPPM receives a particular type of Syslog message. So you create a condition that sets the Type to Event: and the prefix associated with the Ingress Event dictionary that you enabled. Because you want the event to trigger the rule for any Syslog message of this type, you simply choose an attribute that this type of message always produces and specify that this attribute must exist. In the example shown in Figure 11-17, you use the “attack-name” attribute.

Then select your post-authentication profile. Also select profiles for terminating wireless and wired sessions. Remember that you want CPPM to terminate the session so that it can take the endpoint’s compromised status into account when the endpoint authenticates again.

If you wanted to create more complex policies, in which you apply different actions based on the threat type, you could define multiple rules. Each rule would have a condition that specifies a different value for “attack-name” and a different post-authentication profile. However, for this scenario, you want to apply the same actions for all events of this type, so one rule suffices.

Defining an event service

An event service processes events as they occur. You can create multiple event services with service rules for processing different types of events, or for processing events from different sources. For this example, however, you are creating one service, which processes all events.

Figure 11-18: Defining an event service

You then click the Enforcement tab and select your event enforcement policy as shown in Figure 11-18.

Editing the enforcement policies for 802.1X services

When CPPM terminates a client’s session due to a security event, the client will try to re-authenticate. To ensure that CPPM responds correctly based on the client’s compromised status, you need to edit the enforcement policy that you are using for authenticating clients. For example, as shown in Figure 11-19, you could create a rule that selects endpoints with a Compromised attribute set to “true” and applies a profile that sets Aruba-User-Role to a value like “remediation.” In this example, that rule also specifies a second enforcement profile, which tells the Network Access Server (NAS) the client’s username if the client uses TEAP to authenticate.

Figure 11-19: Editing the enforcement policies for 802.1X services

Whatever rule you decide to use, make sure to move it to the top of the list, so it applies to all compromised clients.

As always, you will need to set up the Aruba network infrastructure devices to enforce the proper privileges to clients assigned to a role through an Aruba-User-Role VSA. Often the rights include access to DHCP and DNS. You can then use a captive portal rule to direct the clients to a ClearPass Guest page that has been set up with a quarantine message and links. For example, the page might link users to a site at which the users can update the client’s antivirus application. The “remediation” role would also need to permit access to those links.

Summary

You began this chapter by learning about the CPPM Ingress Event Engine. You saw how the Ingress Event Engine enables CPPM to process Syslogs from security appliances and generate events from them.

Then you learned about how to use the events to respond to threats. You took a high-level look at the solution before learning in greater detail about each of its components and how to configure those components.

Learning checks

What is an event source on CPPM? An MDM from which CPPM receives information about endpoint posture

A security appliance to which CPPM provides user information

A device from which CPPM will accept and process Syslog messages

An endpoint on which malware or another threat has been detected

What purpose does the Ingress Event Dictionary serve? It lists the valid event sources from which CPPM is allowed to process events.

It transforms Syslog content into an event with attributes that can be referenced.

It specifies the actions that CPPM should take in response to an event.

It defines the Syslog message that CPPM should send in response to specific requests.

Match the definition to the component. _ Defines which attributes to update in the endpoint profile

_ Processes events

_ Defines the condition that triggers applying the post-authentication profile

ClearPass Entity Update Enforcement profile

Event enforcement policy

Event service

Note: For answers to all learning checks, refer to the Appendix.

12

Implement Device Profiling with CPPM

EXAM OBJECTIVES

✓ Explain the benefits and methods of endpoint classification on ClearPass Policy Manager (CPPM), including active and passive methods.

✓ Deploy and apply endpoint classification to devices.

✓ Analyze endpoint classification data on CPPM to identify risks.

Assumed knowledge

Fundamental CPPM components, such as services, roles, enforcement profiles, and enforcement policies

Definition of device profiling and basic understanding of profiling methods

Authentication, Authorization, and Accounting (AAA) framework and basics of protocols such as RADIUS and TACACS+

Forms of Layer 2 authentication such as 802.1X

Overview

Aruba ClearPass Policy Manager (CPPM) can collect information about endpoints and use that information to profile the endpoint type. CPPM can then use that information as part of the rich context that it uses to make access decisions.

In this chapter, you will review what you should already know about endpoint classification from your Aruba Certified Network Security Associate (ACNSA) certification. You will then learn more about how to set up device profiling on CPPM using several types of collectors and both passive and active methods.

Next you will look at ways to analyze and use the device information. You will then learn how to use device profiling information within CPPM services so that you can assign different access levels to users on different types of devices. You will also learn how you can use device profiling and Conflict attributes to mitigate threats.

Review endpoint classification

You will now review endpoint classification.

Why profile endpoints?

Since the modern network hosts so many types of devices, you need a way to classify devices based on their type and place different device types into different security roles.

In a typical network a single user may bring a corporate issued laptop, smart phone, and tablet or lightweight device (such as a chrome book) onto the network. It is not uncommon for a single user to have between three and five devices on the business network. More than five devices is common in settings like universities. These devices often do not serve the same functions on the network, and therefore don’t need the same security access. A Zero Trust Security (ZTS) strategy dictates that you grant access to each device based on the needs of users on that device. You should also consider the vulnerability of the device type. For example, smartphones might not be as secure as corporate-managed laptops. Providing users on smartphones the same level of access on a smartphone as on a laptop could potentially expose the network to threats.

Device profiling is also useful for detecting specialized devices such as IoT devices. ClearPass Policy Manager (CPPM) can then take the device type into account when determining the device’s access level. Because IoT devices often support lower levels of security, you want to limit their access and the extent of damage that a compromised device can do.

Collecting information about device types can also be helpful from a management standpoint. IT admins then have greater insight into the types of devices they need to support. This can be helpful when a particular device proves to be problematic on the network or requires a patch or upgrade. The administrator can look and quickly begin to assess the impact of a change to that type of device.

Using device profiling to control devices

Throughout this study guide, you have learned about using 802.1X authentication and a variety of contextual information to implement granular access control policies for users on various devices. Now consider the broad range of devices available today and how companies might want to apply access control policies to them.

Many companies have many of these devices, including building access systems, badge scanners, multi-function printers, cameras and security systems, VoIP phones, and even vending machines. The network needs to support and control IoT devices based on their type. Most of these devices are not actually user inhabited, but require access to the network to do their job. You need to consider how best to implement different access controls for each type.

One traditional method could be to create a different network for each device type and configure the device to connect to its own network. However, this approach is incredibly inefficient. Imagine how many wireless networks you would need to support just the short list in this example.

The better solution is to configure a single wireless network. Aruba CPPM or, as you will learn later, ClearPass Device Insight (CPDI) implements profiling to dynamically discover the type for each device. CPPM can then use role mapping and enforcement policies to apply the correct profile to each client. As you have learned, these profiles often place devices in an ArubaOS or ArubaOS-CX (AOS-CX) role, and the Aruba infrastructure devices will then enforce the correct role-based policies for the client.

Consideration questions

Consider the following questions, which you should answer based on your associate-level knowledge of security. Answers are provided for your reference in the appendix.

What is the difference between passive and active profiling?

How can DHCP packets help CPPM determine the device type?

What useful information can CPPM find in clients’ HTTP/HTTPS traffic?

CPPM collectors

CPPM collects information about endpoints from a variety of sources, or collectors. It can listen in on DHCP and HTTP/HTTPS traffic passively, and it can also collect clients' MAC OUIs from this traffic. CPPM can also receive traffic on a SPAN port, although this feature is less commonly used, or by receiving NetFlow or sFlow traffic samples from network infrastructure devices. Other ClearPass applications, such as OnGuard and Onboard, can also deliver information to CPPM, and CPPM can even receive information from third-party applications such as Mobility Device Management (MDM) solutions. CPPM can also actively scan endpoints using SNMP, SSH, WMI, and Nmap. You will learn about many of these mechanisms in the next topic.

Set up device profiling on CPPM

You will now look at recommendations for setting up device profiling on CPPM.

Review the Endpoints Repository

Whenever CPPM learns about a client device on the network, it will create an entry for it in the Endpoints Repository and attempt to profile the device.

As shown in Figure 12-1, CPPM can learn about a client in several ways. The client might authenticate, or it might access the ClearPass Guest or Onboard portal. If you have set up CPPM as an IP helper for DHCP relay, then CPPM will learn about all devices that obtain DHCP addresses. You can also set up active scans, about which you will learn more later. By using a combination of active and passive profiling methods, CPPM can build a complete list of every device on your network.

To view the endpoints in CPPM, navigate to Menu > Configuration > Identities > Endpoints.

Figure 12-1: Review the Endpoints Repository

Endpoint profile

As shown in Figure 12-2, an endpoint profile includes a hierarchy of information about the device:

Device Category, which identifies the device type such as Computer, Smart Device, or Printer

Device Family, which further classifies the device by OS or vendor; for example, a Computer might be in the Windows, Linux, or Mac OS family

Device Name, which further segments the family; for example, an Apple Mac computer might have Mac OS X for its Device Name

Figure 12-2: Endpoint profile

Other information in the profile includes:

IP address

Hostname

MAC Vendor

Timestamp when the device was first discovered

Timestamp when the device was last seen

Overview of how CPPM profiles devices

To categorize endpoints, CPPM collects information as attributes that it knows about the device. As shown in Figure 12-3, it then profiles the device in two phases.

Figure 12-3: Overview of how CPPM profiles devices

In the first phase, CPPM matches attributes against device fingerprint dictionaries. These dictionaries list multiple attributes characteristic of devices of a particular type. Sometimes the device attributes might point in different directions. CPPM also assigns a reliability and score to each attribute type, which enables CPPM to choose the most likely dictionary.

CPPM refines the match in phase 2 using rules such as requiring the device to have a particular MAC OUI.

CPPM Device Fingerprints Dictionary

CPPM comes with hundreds of device fingerprint dictionaries. Each one lists known fingerprints and attributes for a specific device category, family, or name. As shown in Figure 12-4, you can find the built-in fingerprints dictionaries in Menu > Administration > Dictionaries > Device Fingerprints. You can also add custom fingerprints here.

Figure 12-4: CPPM Device Fingerprints Dictionary

Example Device Fingerprint Dictionary Attributes

An example of a device fingerprint dictionary is shown in Figure 12-5. As you see, it lists several attributes, as well as a list of values for those attributes, which devices of this type are known to have. These attributes act as identifying characteristics by which CPPM can match a client to the dictionary.

As indicated previously, the dictionary might have rules, as well, which enable CPPM to refine a match.

Some devices, like the Mac OS X computer shown in Figure 12-5, have a large number of attributes and rules while other devices have a smaller list.

Figure 12-5: Example Device Fingerprint Dictionary Attributes

Updating Fingerprints separate from the software

When you update the ClearPass software, CPPM receives the latest set of device fingerprints. However, Aruba also makes new device fingerprints available separate from a complete software update. Using these updates, you can enable CPPM to profile new types of devices more accurately without waiting for a software upgrade.

Figure 12-6: Updating Fingerprints separate from the software

If you want your servers to receive these updates automatically, you can enable the Automatically download Endpoint Profiler Fingerprints setting in your standalone server’s or cluster’s cluster-wide parameters (as shown in Figure 12-6). Click Cluster-wide parameters in the Administration > Server Manager > Server Configuration page. Then find the setting in the General tab.

You can check the status of updates in the Administration > Agents and Software Updates > Software Updates page.

In that page, you can also manually update the endpoint profiles fingerprints by uploading a file. Click Import Updates in the Posture & Profiler Data Updates section. Manual installs work for offline servers.

Ensuring CPPM receives DHCP packets (Layer 3)

Enabling CPPM to collect DHCP information is simple. As shown in Figure 12-7, you add CPPM’s IP address to the IP helper list on your DHCP relays for each of the endpoint subnets. The DHCP relay will then send DHCP discover requests to both the DHCP server and CPPM, and CPPM can use those requests to obtain DHCP fingerprints. The DHCP traffic will also contain MAC addresses for the client, so CPPM can learn the MAC OUI.

CPPM can also learn the MAC OUI from the authentication process if clients authenticate to it.

Figure 12-7: Ensuring CPPM receives DHCP packets (Layer 3)

Note that CPPM profiles devices with DHCP Discovers. In typical networks, clients come up and send out Discovers to obtain their IP addresses. However, if you are demonstrating CPPM's profiling feature, you might be templated to simply renew DHCP addresses, which causes the client to send out a DHCP Request instead of a Discover. For the best results, when you want to demonstrate re-profiling a device, you should fully shut down the device's connection and then bring the connection back up.

Ensuring CPPM receives DHCP packets (Layer 2)

Occasionally a company might have some endpoints that receive DHCP addresses from a server on the same subnet without a DHCP relay being involved. As shown in Figure 12-8, you can still enable CPPM to receive the DHCP traffic by sending that traffic to a ClearPass server’s Span Port.

Figure 12-8: Ensuring CPPM receives DHCP packets (Layer 2)

Span Port configuration on ClearPass Server

First, you need to select the port to act as the Span Port.

If you are using only the Management Port on your ClearPass server, you can use the Data Port as the Span Port. Otherwise, you must use one of the unused ports on the appliance. If you are using a VM-based appliance, you must add additional virtual NICs to the VM.

To enable the Span Port, you must go to CPPM’s Administration > Server Manager > Server Configuration page. Select the ClearPass server in question. In the System tab, select the port that you choose as the Span Port. Make sure to leave the Enable TCP/ARP Fingerprinting check box unselected. Aruba generally recommends against using this feature because it is processor intensive.

Switch configuration

For the simplest setup, directly connect the ClearPass server’s Span Port to the switch that supports the devices receiving DHCP addresses without DHCP relay. Then make that port a member of those devices’ VLAN. If you are using DHCP snooping, you must also make this port a DHCP snooping trusted port.

How CPPM receives HTTP User-Agent strings

As mentioned earlier, HTTP User-Agent strings can help CPPM distinguish between different types of devices that might share a DHCP fingerprint, such as an Apple tablet versus an Apple smartphone. As shown in Figure 12-9, CPPM will automatically receive the HTTP User-Agent information if clients connect to ClearPass Onboard or ClearPass Guest portals, which unmanaged clients often do as part of their initial connection process. For clients that you are not already directing to those portal, you might decide that CPPM can collect enough profiling information from other sources. Or, you might set up the Aruba infrastructure to redirect all clients that need to be profiled to a page on ClearPass guest until the profiling is complete; you will learn more about that setup later.

Figure 12-9: How CPPM receives HTTP User-Agent strings

Use cases for network/subnet scanning

You will now learn about setting up active scanning on CPPM using network or subnet scans.

Active scanning is also useful for detecting and profiling clients that have static IP addresses, so CPPM receives no DHCP packets from them.

When CPPM uses WMI or SSH as part of the scan, it can also collect more information about endpoints with both dynamic and static IP addresses. It can learn which ports and services are enabled on the client and other such information.

You can specifically use network scans, sometimes called discovery scans, to discover network devices and then add them as RADIUS/TACACS+ clients on CPPM. Some companies like this approach for quickly discovering network devices when they first deploy CPPM. Other companies prefer methods such as adding the devices manually or importing XML files.

Scan methods

As shown in Figure 12-10, CPPM supports three methods for scanning devices: SNMP, WMI, and SSH.

Figure 12-10: Scan methods

It uses SNMP to discover network devices. Specifically, it collects each device’s system name, system location, system contact, and system description. As you will learn in more detail later, CPPM also uses SNMP to collect various information about the device’s neighbors so that it can expand the scan.

CPPM uses WMI to discover information about Windows domain computers.

It uses SSH to discover information about servers and Linux endpoints.

Setting up external credentials

To prepare for active scans, you must set up the external credentials that CPPM will use to perform the scan.

To create an external account, navigate to Administration > External Accounts. Then click Add to create a single account or Import to import many accounts from a spreadsheet.

For each account, you specify the type as SNMP, SSH, or Domain/WMI. As shown in Figure 12-11, you can create multiple accounts of each type to hold the specific credentials for different types of devices or devices in different locations.

Figure 12-11: Setting up external credentials

SNMP

If your network devices use SNMPv1/v2c, you should specify “SNMPv1 with community strings” or “SNMPv2 with community strings” for the Version. Then set the community name to match a read-only community on the network device.

If the network devices require SNMPv3, you must choose of the SNMPv3 options, matching the requirements and algorithms with those used on the network device. The network device admins should tell you the credentials, security levels, and algorithms used for an account that has read-only (or read-write) access. Under the version, you specify whether authentication is required, the algorithm used for authentication if required, and whether privacy is required in addition to authentication. If you select privacy, you choose the privacy protocol in a separate field. After choosing an SNMPv3 version, you specify the username and keys for the read-only account. You will also see key fields for the particular types of security that are required. (In other words, if you choose a version that requires authentication, you must set an authentication key. If the version further requires privacy, you must set a privacy key.) The network admins should tell you the key values as part of the credentials for the account.

SSH

When you choose “SSH” for the Type, you must specify a valid username and password for SSH access to the device.

Domain/WMI

For “Domain/WMI” accounts, you specify the domain name, the username, and the password. CPPM will use this format when logging into a device with these credentials: domain_name\username. Choose a user account that has administrative access to the domain computers.

Setting up Profiler Subnet Mappings

After you create the external accounts, you must map them to the subnets that contain devices using those accounts. Still within the Administration > External Accounts page, select Profiler Subnet Mappings.

You can then add multiple mappings. For each mapping, define one or more subnets. Then choose the account type. You can then select one or more accounts of that type.

CPPM uses these mappings when it needs to scan devices. The mappings determine which protocols CPPM can use for scanning devices within that subnet. In the example shown in Figure 12-12, CPPM cannot use WMI to scan an IP address at 10.2.4.4 because it has no WMI credentials mapped to that subnet. Instead CPPM would use SSH to scan this device. CPPM can use WMI to scan 10.1.11.28, however, because it has a WMI mapping that applies to this device’s subnet. More specifically, CPPM uses the “WMI-mydomain” account to run the WMI scan.

This is because the mappings further determine which account or accounts to use for the scan.

For example, you can create a mapping that includes the subnets for your AOS-CX switches—

10.1.10.0/24 and 10.2.10.0/2, in the example shown in Figure 12-12. You can then select SNMP for the scan type and the particular SNMP account with the credentials used by your AOS-CX switches. In this scenario the AOS devices use different SNMP credentials, so you create a different subnet mapping for the AOS network device subnets and select the “SNMP-AOS” account for that mapping.

Figure 12-12: Setting up Profiler Subnet Mappings

You can create multiple mappings for the same subnets, or for overlapping subnets, with different types of accounts, if you want to apply multiple scan methods to the same subnet.

You can also create a subnet mapping with a more specific subnet that overrides a mapping to a larger subnet for that specific subnet only. In the example configuration shown in Figure 12-12, CPPM uses the “MySSH” account to scan devices in 10.2.6.0/24, but “YourSSH” to scan all other devices in 10.2.0.0/16.

Network (discovery) scan

A network, or discovery, scan uses seed devices. CPPM begins by sending an SNMP Get message to each seed, asking for three pieces of information: the LLDP neighbors, the CDP neighbors, and the ARP table. You should generally select the default router or routers in your network as the seed. Selecting multiple seeds can be a good idea, too. For example, you might specify multiple routing switches. A default router maintains an ARP entry for every device for which it is routing traffic, so its ARP table can yield the IP address and MAC address for every active device in its subnets (as long as the device is sending and receiving routed traffic).

Figure 12-13: Network (discovery) scan

The CDP and LLDP tables provide CPPM with a list of devices connected to the seed at Layer 2. CPPM adds these devices to its list of discovered devices. If you want CPPM to send SNMP Get messages to discovered devices, you must set the scan depth greater than 1. As shown in Figure 12-13, the scan depth dictates how many times CPPM repeats the scanning process. If the scan depth is 1, CPPM scans the seeds and then stops. If you set the depth to 2, CPPM scans the seeds and the devices discovered in the seeds’ CDP and LLDP tables. If you set the depth to 3, it scans the seeds, the devices discovered in the seeds’ CDP and LLDP tables, and the devices discovered in the second devices’ CDP and LLDP tables, and so on.

CPPM scans devices with probes. A probe is an SNMP Get message.

As mentioned earlier, CPPM also obtains the ARP table from every device that it scans with SNMP. CPPM uses the ARP table to correlate discovered IP addresses and MAC addresses. You can also enable probing ARP entries, which means that, when conducting the next layer of the scan (as dictated by the scan depth), CPPM sends out probes to devices discovered in the ARP table, as well as the LLDP and CDP tables. Enabling this option could make the scan much longer because the ARP table is typically so much larger than the LLDP and CDP tables, as it includes many client devices as well as network infrastructure devices. If you leave the ARP probe setting disabled, CPPM still uses the ARP table information to correlate IP and MAC addresses. However, it does not send probes to the IP addresses in the table.

Subnet scan

CPPM can also run subnet scans. In this case, CPPM scans every device within the subnet or subnets defined in the scan. As shown in Figure 12-14, if you specify 10.1.11.0/24 in the scan, CPPM scans devices 10.1.11.1 through 10.1.11.255.

CPPM uses WMI, SSH, and SNMP to scan the subnets, depending on the external accounts mapped to the subnet. For example, if you have mapped a WMI account to 10.1.11.0/24, or a larger subnet such as 10.1.0.0/16, CPPM uses WMI and the credentials in that account to scan devices in 10.1.11.0/24. Port 135 must be open for the WMI scan to succeed. If 10.1.11.0/24 also has SSH or SNMP credentials associated with it, CPPM uses those protocols for the scan too. But if it does not have credentials of a particular type for the IP addresses, it simply skips scanning those addresses with that protocol.

Figure 12-14: Subnet scan

If you enable Nmap scanning in the cluster-wide settings, CPPM scans devices with Nmap as well. Nmap detects endpoints and scans which application ports are open on those endpoints. It can also figure out endpoints' OS by sending TCP traffic and analyzing how the endpoints respond. Nmap scans are more intensive. You might choose to use this tool in smaller subnets (such as /24), rather than across large subnets (such as /16). You should also be aware that, because hackers also use Nmap for network reconnaissance, the company's security appliances might flag the Nmap scans as a threat. You should discuss the use of this method with the company's security team members, and, if they decide you should use it, they should allow list CPPM.

Guidelines for running scans

You can run a scan “on-demand,” which means that CPPM runs the scan directly after you create it. You might run an initial on-demand network (discovery) scan after you first install CPPM to obtain a list of network devices. You can then add those network devices as RADIUS/TACACS+ clients. The initial network scan can also discover endpoints and information about them if you have enabled WMI probes.

You can also schedule periodic scans to enable CPPM to discover new endpoints and collect refreshed information. Aruba recommends that you schedule the periodic scans at quiet times during which the network is relatively inactive. Subnet scans can be particularly intensive, so take care to schedule them when they will not interfere with normal operations.

Figure 12-15: Guidelines for running scans

Also note that CPPM might discover devices during subnets scans, but not have the MAC address information for the device. CPPM needs to be able to read network devices’ ARP tables to learn the MAC address that correlates to each IP address. CPPM sends out periodic SNMP polls to network devices to collect this information. To ensure CPPM can run the polls on network devices, edit network device entries (find the list in Configuration > Network > Device). Click the SNMP Read Settings tab as shown in Figure 12-15. Select the Allow SNMP Read check box. Configure the credentials to match those on the network devices in question. Then select the Read ARP table from this device check box and save the settings.

Obtaining profiling information from third-party devices

You can also set up third-party MDM solutions as Endpoint Context Servers. Some examples include Citrix XenMobile and MobileIron Core.

As shown in Figure 12-16, CPPM polls the server on a periodic basis for information about endpoints that the MDM manages. CPPM adds this information as attributes within the endpoints’ profiles. In an earlier chapter, you learned about how MDMs can inform CPPM of attributes related to endpoints’ posture, but MDMs can also provide attributes relevant to profiling the devices such as the device type and OS version.

Figure 12-16: Obtaining profiling information from third-party devices

Using device information

Next, you will learn some strategies for analyzing CPPM's device information and device profiles for security purposes.

CPPM Endpoint Profiler Dashboard

CPPM consolidates the information that it has collected about endpoints in the Endpoint Profiler Dashboard, available in Monitoring > Profile and Network Scan > Endpoint Profiler. As shown in Figure 12-17, this page provides a breakdown of devices by category, family, and name. You can find a list of all endpoints, which you can filter based on Device Category, OS Family, and Status.

Figure 12-17: CPPM Endpoint Profiler Dashboard

ClearPass Insight

ClearPass Insight (not to be confused with ClearPass Device Insight) compiles information across ClearPass servers, analyzes the information, and makes that information available to admins in a Dashboard.

Customizable dashboard “widgets” allow you to view the specific kinds of information you need to monitor and understand what is occurring on the network. You can create customized dashboards to track detailed authentication records, audit trails, and details on network-access trends. As shown in Figure 12-18, you can view endpoints in an inventory. And the Insight Search feature allows you to search for clients, users, Policy Manager servers, and network access devices. You can also run customized reports that compile information over the time period that you select and present the data in an easily readable format. Alerts allow you to receive near-real-time messages regarding anomalous network activity. Alerts can be delivered via SMS or email notification to multiple recipients.

Figure 12-18: ClearPass Insight

For this chapter, your focus is on ClearPass Insight’s capabilities as they relate to inventorying and reporting on endpoints.

Enabling Insight

To use Insight, you must enable it on the ClearPass servers in your cluster. Go to Administration > Server Manager > Server Configuration. Then click a server. In the System tab select the Enable Insight check box, as shown in Figure 12-19. Choose one server to act as the primary server and select the Enable as Insight primary server check box for that server. Note that an Insight primary server is always required, even if you do not have multiple servers in a cluster running Insight.

Figure 12-19: Enabling Insight

You should also enable logging of accounting interim update packets. This setting allows the server to log the accounting information that it receives from network devices, making that information available for Insight. Of course, you must also set up the network devices to send the accounting interim updates in the first place, which you learned how to do in an earlier chapter. Go to the Service Parameters tab to enable this setting.

Save the settings.

Then repeat these steps on other servers in the cluster. But only make one server act as the Insight Conductor.

Configuring Insight Database

You can alter the database retention settings at the Insight Administration page. This parameter defines how long Insight retains data for the endpoint inventory and reports. As shown in Figure 12-20, the default retention period is 30 days. Aruba recommends increasing this size to at least 90 days. If possible, increase the size even more. Scope the size of the ClearPass server’s disk and retain as much data as possible.

Figure 12-20: Configuring Insight Database

Using Insight Endpoint Reports

Insight offers reports in many categories, which you can run to analyze information, archive that information, and present the information in a useful format to other teams and stakeholders.

Figure 12-21: Using Insight Endpoint Reports

To create a report, select Reports in Insight’s left menu. Click Create a Report. A wizard will guide you through creating the report.

As one option, you will choose the report type. As shown in Figure 12-21, you will focus on reports within the Endpoint Category. This category includes these report types:

Active Endpoint Security—This report provides information about endpoints detected by CPPM with an emphasis on potential security issues. In addition to endpoints’ status and category, the report indicates issues such as MAC spoofing attempts and profiling issues.

Endpoint Auth Overview—This report summarizes the number of endpoints with various Device Categories, Device OS Families, and Device Types. It also adds user information to the endpoint information, indicating, for example, how many devices the average user is associated with.

Endpoint Overview—This report also summarizes the number of endpoints with various Device Categories, Device OS Families, and Device Types. It provides an overview of the most common categories, families, and names.

Guest—Endpoint Overview—This report is similar to the Endpoint Overview report, but reports on endpoints associated with guest users.

Idle Endpoint Security—This report shows how many known endpoints have not had their profile updated within the time period of the report.

RADIUS Endpoint Overview—This report is similar to the Endpoint Overview, but reports on endpoints that have authenticated with some form of RADIUS (including 802.1X, MAC-Auth, and others).

The wizard will guide you through further options. You can choose to send the report by email, SMS, or both. This setting requires CPPM to have the corresponding notification settings already configured on it.

You can also choose whether to include a CSV file with the raw data used to generate the report. This file can be useful when you want to dive deeper. For example, the Active Endpoint Security report indicates how many endpoints have the “Generic” Device Category. But if you want a complete list of those endpoints, you need the raw data in a CSV file.

You select the time period that the report analyzes. This can be a relative period such as the previous day, week, or month. Or it can be an absolute period, which you set.

The report type itself filters the output. You can also apply optional filters of your own to further limit the output.

Analyzing an Active Endpoint Security Report

After you create the report, you can view and download it.

You will now look at some of the information that you can obtain from an Active endpoint Security Report and consider how you can use that information.

As shown in Figure 12-22, you can look for devices with a Disabled status. If devices should be disabled, why are they still connected to the network? The main report simply indicates the number of endpoints with this status, but you can get the full list of devices from the report’s raw data in the CSV file. Sort the columns for status, and you can quickly get a list of clients with the “Disabled” status. You can use other columns in the row to track down the endpoint. By checking the Network Access Server (NAS) to which the endpoint is connected, for example, you can start to track down the endpoint’s location. If your investigation reveals illegitimate endpoints, you should take steps to remove them. If there is a legitimate reason for the endpoints to be connected, you can leave them.

Figure 12-22: Analyzing an Active Endpoint Security Report

This report also shows how many clients have a “Known” status or an “Unknown” status. Before you draw conclusions about whether the Unknown endpoints pose a security risk, stop to consider what ‘Unknown’ means in your environment.

More on Unknown versus Known Status

CPPM tracks a status for every endpoint, which is either “Unknown” or “Known.” As shown in Figure 12-23, when CPPM first discovers the endpoint, the status is “Unknown.” The status can become “Known” in several ways. You can manually change the status to “Known,” or you use a default enforcement profile, “[Update Endpoint Known].” You can add that enforcement profile to the profile list of an enforcement policy rule to have CPPM automatically update the status for clients to which that rule applies. You can also add or import endpoints on CPPM, rather than rely on CPPM to discover the endpoints itself. In that case, you can set the status to “Known” in the records that you add or import.

Your company can use the “Unknown” versus “Known” status in whatever way makes sense to your company. One common use is for MAC-Auth, which is a less secure form of authentication typically reserved for clients that are incapable of 802.1X. You give clients that need to pass MAC-Auth a Known status, which you might do by importing the clients to the Endpoints Repository with a Known status.

Many companies also use MAC-Auth together with captive portal authentication to enable guests to log into a captive portal once and then become automatically authenticated for a certain period of time. In that case, the guest client first fails MAC-Auth and undergoes captive portal authentication. The enforcement policy rules that grant guests access through the captive portal also include the [Update Status Known] enforcement profile, which enables the client to pass MAC-Auth on the next attempt. You will learn more about using MAC-Auth later in this chapter. This study guide does not cover guest access; you can learn more about those features by taking Aruba ClearPass training.

Figure 12-23: More on Unknown versus Known Status

For now, you should be aware of how your company wants to use the Unknown versus Known status so that you can explain the report to the recipients. If you are using the Known status for MAC-Auth, you want clients that should undergo the more secure 802.1X to have the Unknown status. In that case, it would be perfectly normal for most endpoints in your network to have the Unknown status.

Analyzing an Active Endpoint Security Report

You will now examine some of the information the Active Endpoint Security Report provides in more detail.

Endpoints MAC spoofing

As shown in Figure 12-24, the report also shows you how many spoofing attempts have occurred. Spoofs are indicated when a single MAC address has an initial device fingerprint, which then changes to another fingerprint. A MAC address is typically tied to hardware, so normally the device fingerprint for a MAC address should never change. If it does, hackers are likely spoofing the MAC address with their own devices.

Figure 12-24: Endpoints MAC spoofing in an Active Endpoint Security Report

You should document this threat and check into it. For example, you can find the current NAS to which the endpoint, likely a spoofing endpoint, is connected and track down the threat that way.

You will learn more about preventing MAC spoofing in a later topic.

Address Schemes

As shown in Figure 12-25, another section of the report shows how many endpoints have dynamic IP addresses and how many have static IP addresses. If you see endpoints with static IP addresses, investigate further. Are these truly endpoints with static IP addresses? Or is CPPM missing some DHCP packets? Perhaps network admins missed adding CPPM’s IP address to the helper address list in one of the VLANs. Without DHCP packets, CPPM is missing valuable information for fingerprinting, so follow up on this potential clue to an issue.

Figure 12-25: Address Schemes in an Active Endpoint Security Report

Typically, all endpoints should have an IP address and a MAC address. If you see endpoints listed with IP address only, CPPM discovered the device during a subnet scan, but could not find an IP address related to the MAC address. CPPM can obtain the MAC-to-IP binding by probing ARP tables, so you should investigate whether your network device entries. Have you enabled SNMP and ARP probes on network devices? Are the SNMP credentials correct? You can see errors with SNMP polls in the CPPM Event Viewer. If CPPM is authenticating most endpoints, it should also be receiving this information from network devices in RADIUS accounting messages. Make sure that you have enabled accounting to CPPM on all your network infrastructure devices and set up interim updates. Another reason that might see endpoints without MAC addresses could be that you accidentally scanned a subnet that is not really under the company's control.

Similarly, ARP probing or RADIUS accounting might be an issue if you see endpoints with a MAC address and no IP address.

Endpoints with Profile Issues

As shown in Figure 12-26, you will also see a section labeled “Endpoints with Profile Issues.”

Figure 12-26: Endpoints with Profiles Issues in an Active Endpoint Security Report

Unprofiled endpoints indicate that CPPM has learned about the endpoint, typically through the endpoint authenticating, but CPPM has not learned any profiling information about it. Often this means that CPPM is not receiving these endpoints’ DHCP Discover packets. Again, you should check the network’s DHCP relay settings. If DHCP relay is not used, make sure that you set up CPPM to receive DHCP packets on a Span Port as discussed earlier. If the endpoints have static IP addresses, of course, CPPM cannot profile the devices with DHCP. Instead it should be running active scans to collect this information. In this case, check the scanning settings.

If CPPM has collected profiling attributes about a client, but cannot determine a device category for it, CPPM categorizes the device as “Generic.” You should identify these devices and add custom fingerprints for them. (You will learn how in a moment.) If the company has many generic category endpoints, it might be best for the company to deploy ClearPass Device Insight instead of using CPPM’s device profiling capabilities, as CPDI has more extensive capabilities in this area.

Typically you should not see endpoints with an OUI Fingerprint Only status. This status means that CPPM has scanned the endpoint, but received no fingerprint during the scan. You will need to check into the scanning and credentials setting for an error. Similarly, if you see the “Fingerprint with Null Component” error, you probably have an issue with the SNMP, WMI, or SSH credentials used to scan that endpoint. Find the IP address for the endpoint in question in the full CSV file for the report. Then look in CPPM’s Profiler Subnet Mappings for that endpoint’s subnet. Find the associated accounts and double-check the credentials.

Creating Custom Fingerprints

As just mentioned, if you have some devices with a generic category, you should figure out yourself what the device type is and create a custom fingerprint that can apply to that device and all similar devices.

As shown in Figure 12-27, you first add a new fingerprint in Administration > Dictionaries > Device Fingerprints. You can choose any meaningful values to you and other administrators for the Category, Family, and Name. At this point the dictionary has no attributes or rules associated with it yet. You must add rules from a device that CPPM has discovered; you cannot add the rules manually.

To add the rules, make sure that a representative device for this type is connected to the network and detected by CPPM.

Figure 12-27: Creating Custom Fingerprints

Then find the device’s MAC address in CPPM’s Endpoint Repository (Configuration > Identity > Endpoints). Select the endpoint and click Update Fingerprint, as shown in Figure 12-27.

Figure 12-28: Creating Custom Fingerprints (cont.)

You will see a window similar to the one shown in Figure 12-28. Manually adjust the Device Category, Device OS Family, and Device Name to match those in the new fingerprint that you previously added. Make sure that the Update Type is set to Add fingerprint rule. Select all of the device fingerprints and click Save.

CPPM then takes the fingerprints from this endpoint’s device profile and adds them to the Device Fingerprint that you added previously. Now CPPM can profile other devices of this type with the custom device fingerprint.

Use profiling in CPPM Services

You can use CPPM's device profiles to add context to CPPM's policies. For example, you can set up policies to assign different Aruba-User-Role VSAs to users based on the type of device that they are using. Or you can set up policies to assign different firewall roles and access levels to different types of headless devices such as printers, cameras, and various IoT devices. You will now learn more about setting up CPPM policies and services for these use cases.

Example L2 authentication process with device profiling

You will now learn how to use device profiling information as additional context that CPPM can use in access control decisions. When you are using Layer 2 authentication (802.1X or MAC-Auth) to authenticate clients, the high-level process shown in Figure 12-29 occurs.

Figure 12-29: Example L2 authentication process with device profiling

The first time that the client authenticates, CPPM does not have a profile for it and does not know the device category. The enforcement policy within the L2 authentication service has a rule for devices without a device category. This rule assigns the client a profile that provides very limited access.

The client is now connected and requests a DHCP address. CPPM receives the DHCP Discover and profiles the device. Even if CPPM does not have all the information that it might eventually collect for the profile, it should be able to pinpoint the device category. In the example shown in Figure 12-29, CPPM profiles the client as a computer.

The change in profile signals CPPM to send a CoA to the network device to which the client is connected.

The client reauthenticates. The L2 authentication service’s policies have rules that assign a particular AOS role to users on computers. CPPM informs the network device of the client’s new role, and the client is now fully connected with appropriate privileges.

Adding the Profiler to the Service

For this use case you need to enable the Profile Endpoints option on the L2 authentication service.

As shown in Figure 12-30, you can find the Profile Endpoints option in the Service tab of the service. After you select it, CPPM will monitor the profile status for all clients that authenticate through the service, even after the clients have completed authentication. CPPM can then modify the client's access level after the client's device profile changes using the settings that you configure in the Profile tab.

Figure 12-30: Adding the Profiler to the Service

Selecting the Profile Endpoints option adds the Profiler tab to the service.

Note that you also often need to select Authorization for the service. Then you can add the Endpoints Repository to the Authorization sources. The Endpoints Repository must be either an authentication source or an authorization source for you to include device category, family, or name as conditions in rules.

The profiler functionality is extremely helpful in weaker authentication methods such as MAC authentication where IoT devices could possibly be spoofed on the network. A MAC address is easy to spoof but hardware profiles are much harder to fake.

Configure the Profiler Action

CPPM watches the profile data status for all clients that authenticate with this service. Go to the Profiler tab to configure how CPPM responds to changes in the status.

Figure 12-31: Configure the Profiler Action

If a client’s classification changes to one of the categories, OS Families, or Names listed in the Endpoint Classification section, CPPM executes a CoA action. As shown in Figure 12-31, typically you should select Any Category/OS Family/Name for the Endpoint Classification section. Then CPPM will force the client to reauthenticate if its profile changes in any way.

Also set the desired RADIUS CoA action to an action that is valid for the network devices sending requests to this service.

The profiler action ensures that CPPM issues a CoA after an unprofiled device is profiled. It also helps to protect against spoofing. For example, think of a camera that authenticates and is profiled as a camera. If someone were to try and spoof the camera’s MAC address with a Macbook Pro®, ClearPass will notice the change in category, and the service will execute a CoA. When the client re-authenticates the enforcement policy can deny the client access.

You can alternatively configure CPPM to watch for specific changes, such as any change related to the camera category. This means if a device is profiled as a camera and the profile changes to something else, or if a device that is not a camera changes to a camera, both conditions will trigger the CoA action. However, if a device is profiled as a smartphone and changes to profiled as a computer no CoA action will happen.

Example of incorporating device profile information in a role mapping policy

You need to determine how the company wants to incorporate device profile information in enforcement policies.

In the example shown in Figure 12-32, a company has a role mapping policy that assigns clients roles based on their AD security group. It also checks the client’s account status, which is important for services using EAP-TLS, or TEAP with EAP-TLS, as the authentication method.

Now the company also wants to include device profile context. So you add a couple more rules, which assign roles based on device category. In this example, you assign clients with a category of Computer to a “computers” role and clients with a category of SmartDevice to a “smartphones” role, as shown in Figure 12-32. If you wanted to allow other types of devices to connect, you would simply add more rules and roles for those devices.

Figure 12-32: Example of incorporating device profile information in a role mapping policy

You also add a rule for devices that do not have a category. These devices require further profiling so that CPPM can assign them to a category.

More detailed guidelines on the rule for devices that need further profiling

Take a moment to consider in more detail why the example role mapping policy used the following condition to select devices that need further profiling: “Authorization:[Endpoint Repository] Category NOT_EXISTS.”

The best way to select devices that need further profiling is to determine which data point you are using in other rules and evaluate whether it exists. In this scenario you are assigning clients to roles based on Category. As shown in Figure 12-33, you should create a rule that selects clients that have no Category and assign them to the “profiling” role.

Figure 12-33: More detailed guidelines on the rule for devices that need further profiling

Avoid using “IsProfiled EQUALS false” for your rule. Different profiling collectors expose different data points. As long as CPPM knows one data point about the client, it classifies the client as profiled. But CPPM might not actually know the data point that you want to use in rules (Category in the example shown in Figure 12-33). To avoid issues, use a rule that evaluates whether the specific data point that you want to use exists.

Example enforcement policy that incorporates device profiles

You will now explore how you can use the Device-Category-based roles in an enforcement policy.

This example enforcement policy is already distinguishing between employees on domain computers and employees on BYOD devices. The first three rules apply to domain computers, as identified by the fact that the client has passed machine authentication. (It might have passed user authentication too.) You might decide not to include the device-category-based roles as conditions in these rules, as you already know that these clients are domain computers.

However, the company might want to distinguish between employees on BYOD laptops and employees on BYOD smartphones. Rules 4 and 5, which are shown in Figure 12-34, demonstrate how you can achieve this goal. The conditions include the [User Authenticated] and “AD User Enabled” roles, verifying that the user is legitimate. The rule further specifies a role associated with a particular device category. Users on computers are assigned to the “employee-byod-computer” enforcement profile and users on smartphones to the “employee-byod-smartphone” enforcement profile. These enforcement profiles use the Aruba-User-Role VSA to assign clients to roles named “employee-byod-computer” and “employee-byod-smartphone.” As always, the network devices need matching roles that are configured with the proper firewall policies to enforce the company’s security policies.

Figure 12-34: Example enforcement policy that incorporates device profiles

As shown in Figure 12-34, the final rule applies to clients that receive the “profiling” role. It assigns a profile named “profiling-access” to the client. This profile sends an Aruba-User-Role VSA for a “profiling-access” AOS role, and that role provides very limited access.

Note that users on domain computers could receive the “profiling” CPPM role, in addition to other roles, the first time that the computer authenticates to the network. However, because the “Tips:Role EQUALS profiling” rule is at the bottom of the list, users on domain computers will be initially assigned to their full access profile, even before CPPM finishes profiling them. You might decide to take this approach to give the clients faster initial access, relying on the machine authentication to prove that the clients are domain computers. If, however, you wanted to profile all devices before permitting full access, you would need to move this rule to the top of the list.

Services for the clients that need to be profiled

As always the AOS or AOS-CX devices must have roles with the names of those assigned in the Aruba-User-Role VSA.You should lockdown the role assigned to clients that need to be profiled. Provide only as much access as is required for CPPM to profile the device. You might provide just DHCP address. However, you might also want to add a few more services to ensure that CPPM receives all relevant data. As shown in Figure 12-35, you might use a captive portal policy to redirect clients to a page on ClearPass Guest. The page would explain that CPPM is profiling the client and the user will receive access soon. The web traffic between the client and this page will help CPPM complete that profiling process. (When you set up a captive portal rule on an Aruba AP, it automatically allows the DHCP and DNS services required to get the client to the captive portal.)

Figure 12-35: Services for the clients that need to be profiled

Use device profiling to protect against spoofing

You will next learn how to use CPPM’s device profiling information to offer greater protection against spoofing when CPPM authenticates devices with MAC-Auth.

MAC-Auth

Up to this point you have focused on 802.1X authentication on WLANs and switch ports and for good reason—802.1X is the most secure option. However, some clients are not capable of 802.1X. “Headless” devices such as cameras, printers, and other devices with limited user interfaces also cannot perform web authentication. MAC authentication (MAC-Auth) provides the network a way to authenticate these clients.

Figure 12-36: MAC-Auth

A client does not need to be configured with any special settings for the network to authenticate it with MAC-Auth. It simply sends its normal traffic, which includes its MAC address. The NAS (which might be a switch such as the one shown in Figurer 12-36 or an AP, gateway, or MC) sends a RADIUS request to its RADIUS server. This request uses the client’s MAC address as the User name and password.

CPPM uses a MAC-Auth service to authenticate the client. It simply checks whether the MAC address is authorized using the selected authentication source. No further credentials are required. At the end of the process CPPM sends a response to the NAS, indicating whether the client is permitted access.

How MAC-Auth and 802.1X interact on AOS-CX switches

Typically you want to keep 802.1X, as the most secure option, enabled on all of a switch’s edge ports. However, you also want MAC-Auth as a failsafe for clients incapable of 802.1X. You can meet both requirements by enabling both port-access methods on all edge ports.

Authentication priority and authentication precedence

Two port-access settings dictate how the methods work together on the port when both are enabled.

Authentication precedence determines which method the switch implements first. By default, 802.1X takes precedence over MAC-Auth. So the switch first attempts to authenticate a client with 802.1X. Only if the 802.1X authentication times out, the switch implements MAC-Auth. If you change the precedence to MAC-Auth, then 802.1X, the switch first implements MAC-Auth. Because all devices are capable of MAC-Auth, the client either passes or fails MAC-Auth. The client can initiate 802.1X later, though, and achieve an 802.1X authentication status as well.

Authentication priority determines which method’s status takes priority over the other when the client has undergone both methods. In other words, if the client has a MAC-Auth authentication status and role, and an 802.1X authentication status and role, which does the switch use as the client’s actual status and role on the port? By default, the authentication priority is taken from the authentication precedence. However, you can set the authentication priority to a different order from the precedence.

Figure 12-37: Authentication priority and authentication precedence

You will usually configure these settings in one of two combinations.

As shown in Figure 12-37, the default settings are aaa authentication port-access auth-precedence dot1x mac-auth and the priority following precedence. You would use this combination when you want to authenticate most clients with 802.1X, but a few clients are entirely incapable of 802.1X, so you will use MAC-Auth for them. When the port comes up, the switch attempts 802.1X. If the client completes 802.1X, and either succeeds or fails, the switch uses the 802.1X status and role to determine the client's access and does not use MAC-Auth. However, if 802.1X times out, the switch implements MAC-Auth. It then uses the role assigned by that method to control the client.

Alternatively, the company might have a lot of devices that are 802.1X capable, but initially start without the 802.1X configuration. They must connect, download that configuration, and then undergo 802.1X. Examples of such devices are APs. The company might not want the APs and other similar devices to wait several minutes for 802.1X to time out. However, it does want the device’s eventual 802.1X role to take priority over the MAC-Auth one. As shown in Figure 12-37, specify these two commands:

aaa authentication port-access auth-precedence mac-auth dot1x

aaa authentication port-access auth-priority dot1x mac-auth

Timers and retries

The length of time that it takes for 802.1X to time out depends on three settings, which are configured under the port’s aaa port-access dot1x authenticator context:

discovery-period—The amount of time that the switch waits between sending EAP/Request Identity packets when no clients are authenticated on the port. The default is 30 seconds.

max-eapol-requests—The number of EAP/Request Identity packets that the switch sends before considering the authentication session over. The default is 5.

max-retries—The number of retries to authenticate a client that is not responding, before considering 802.1X to have timed out. The default is 2.

eapol-timeout—The amount of time that the switch waits for a response after sending an EAP packet in an ongoing EAP transaction before retransmitting the packet. By default, the switch uses the RFC standard of 3 seconds, then doubling for each timeout up to a maximum of 20 seconds.

MAC-Auth vulnerabilities

MAC-Auth does not provide rigorous security because it is easily spoofed. Hackers can often discover valid MAC addresses relatively easily. As shown in Figure 12-38, if the hacker is trying to connect to an Ethernet port, the hacker has access to the site. This means that the hacker is probably able to examine devices like printers, and many of those devices have their MAC addresses labeled on them, or will print out their MAC addresses. If the company has a WLAN that uses MAC-Auth, finding a valid MAC address is even easier. The hacker simply needs to sniff the 802.11 frames.

Once hackers know a valid MAC address, it is trivial for them to change their own device’s MAC address to match. They can then pass MAC-Auth.

Figure 12-38: MAC-Auth vulnerabilities

Using device profiling to enhance MAC-Auth

Using endpoint classification and device categories within CPPM policies can help you to enhance the security of the MAC-Auth solution.

Figure 12-39: Using device profiling to enhance MAC-Auth

As shown in Figure 12-39, one example scenario is wired IP cameras authenticating by MAC address alone. Without some added form of intelligent access control to identify the device as a valid camera, your network will grant access to any device with a camera MAC address.

An attacker might remove the camera. It can be relatively simple for attackers to find the camera’s MAC address and configure their laptop to use the same MAC address. What would happen then?

The laptop would also be granted access to the network if no other way existed to determine that the MAC address being presented was spoofed.

However, what if you had a way of telling which type of device was presenting the MAC address? Using the CPPM profiler, you can get a deeper understanding of the real client device type and use that information to govern access to the network.

You can add endpoint context to rules in CPPM policies. You might set up the rules to allow devices with the proper MAC addresses only if they are cameras. As shown in Figure 12-39, if CPPM identifies the device as something other than a camera, it will send an Access-Reject message to the switch, even if the client passed MAC authentication.

Example CPPM 802.1X MAC-Auth service that uses profiling

To provide MAC-Auth with profiling, you would set up a service using the MAC authentication template. This template creates service rules that select MAC-Auth requests (the username is the same as the called station ID). You can choose between two default methods for MAC-Auth:

[MAC-Auth]—CPPM authenticates a client if its MAC addresses matches an entry in the Endpoints Repository that has a Known status. Admins would need to import the authorized clients’ MAC addresses into the Endpoints Repository as Known clients in advance.

[MAC-Auth Allow All]—CPPM authenticates all clients and uses rules in the enforcement policy exclusively to decide how to handle each client.

You should use the Endpoints Repository for the authentication source for both types of MAC-Auth. For [MAC-Auth Allow All], you do not technically need an authentication source, but you are still required to specify one. Specifying the Endpoints Repository lets you use it as an authorization source.

Figure 12-40: Example CPPM 802.1X MAC-Auth service that uses profiling

The role mapping policy and enforcement profile assign clients to CPPM roles and enforcement profiles based on their category. As shown in Figure 12-40, this company has a couple categories of headless devices that need to use MAC-Auth including printers and cameras. The role mapping policies assign clients profiled as printers to the “printers-cppm” role and clients profiles as cameras to the “cameras-cppm” role. Clients without a device category receive a “profiling-cppm” role. All other clients receive the [Other] role.

The enforcement policy maps those CPPM roles to appropriate enforcement profiles. Clients that do not match a rule are assigned to a quarantine role, which essentially locks the client out but stops MAC-Auth from running again and again.

Example process of denying access to spoofing device

Figure 12-41 shows a more detailed process of how CPPM locks out the spoofing device.

Figure 12-41: Example process of denying access to spoofing device

In the example shown in Figure 12-41, CPPM has an existing profile for a printer in its Endpoint Repository. Now a hacker connects a computer which is spoofing the printer’s MAC address. Initially, CPPM grants access to the computer based on the spoofed MAC address.

However, as soon as the computer requests an IP address, CPPM reprofiles the client and detects the conflict. Based on the changed category, CPPM sends a CoA to the network device.

The computer is disconnected and then attempts to reconnect. Now the client no longer matches a role in the enforcement policy rule because this particular policy does not permit access to endpoints with the Computer category. CPPM applies the default profile, which is a quarantine profile in this example (as shown in Figure 12-41).

If you want to demonstrate this feature to a customer, be aware that CPPM caches the MAC-Auth client’s enforcement profile for five minutes after the client’s initial connection and automatically reassigns the profile if the client re-connects during that period. After you connect the legitimate device, you should wait for the profile to time out before you connect the spoofing device. (Typically a device like a printer will have been connected for a period of time before a hacker tries to spoof the device.)

Endpoints Repository: Conflict attribute

You can add additional layers of security to the service using the Conflict attribute in the endpoint profile. You should be aware that CPPM continues to profile a device after it has already profiled it, using new information. This helps CPPM to keep track of changes to an endpoint’s Device Category and to flag potential issues with spoofing.

Figure 12-42: Endpoints Repository: Conflict attribute

As shown in Figure 12-42, the first time that CPPM profiles an endpoint, it sets the Conflict attribute to false. For example, a printer connects to the network, completes MAC authentication, and is profiled as a printer. The Conflict attribute is currently false. In the normal course of events, an endpoint’s Device Category should not change.

Suppose that hackers spoof the printer’s MAC address on their computer. As shown in Figure 12-42, CPPM detects the “same” MAC address, but now profiles it as a Computer. Because the Device Category changed, the Conflict attribute becomes true. This alerts you to the spoofing. You can configure enforcement policies to select any clients with a “Conflict” true flag and apply appropriate actions, such as deny access to the network or sending the helpdesk a message with the endpoint’s information.

To identify clients that are spoofing in enforcement policy rules, you should use the “[Endpoints Repository]: Conflict” attribute. This attribute acts as a flag and will only be set to true when ClearPass recognizes a change in Device Category. This flag will not be set when an endpoint changes from not profiled to profiled.

If you are demonstrating use of the conflict attribute for a proof of concept (POC), you should keep some guidelines in mind. In the real world, a hacker would connect their own spoofing device. However, in a POC, you might be using the same endpoint to simulate the legitimate device and the hacker device. To re-profile an existing device, CPPM needs to receive a DHCP Discover packet from the device, rather than a DHCP renewal request. Therefore, you should make sure that you force your demonstration device to fully drop its IP address and send out a new DHCP Discover. You might use Access Tracker to send a “bounce port” CoA for the client, which holds the connection down for several seconds.

Adding conflict detection to the enforcement policy

To mitigate MAC spoofing, you need to complete several steps.

Enable Authorization and add the Endpoints Repository to the Authorization sources list. As shown in Figure 12-43, add the following rule to the enforcement policy rules: [Authorization: Endpoint Repository] Conflict EQUALS true -> [RADIUS Deny Access]. Make sure to move the rule to the top of the list. Then CPPM will deny any client for which the endpoint profile has a Conflict attribute set to true.

You also need to enable the Profiler on this service and set the CoA action to occur whenever the category, family, or type changes. This step is necessary because the Conflict attribute does not become true until a little after the spoofing client has connected. You need the Profiler to trigger a CoA so that the spoofing client is forced to reauthenticate and can then be denied.

Figure 12-43: Adding conflict detection to the enforcement policy

This configuration will meet the requirements of the scenario. Note that you could enhance the service more, though. You could change the role mapping policy to assign CPPM roles based on Device Category, rather than AD group, for example.

Ignoring conflict flags on devices using PXE

Some devices use Preboot Execution Environment (PXE), which allows them to boot an OS image from a location on the network rather than a local disk. VMs often use PXE, but IoT devices and other clients can as well. When PXE is running and before the device has received its OS, CPPM profiles the client for Device OS Family and Device Name. After the client finishes booting, CPPM reclassifies it as whatever OS type it ends up running.

Figure 12-44: Ignoring conflict flags on devices using PXE

This change in category triggers a conflict flag. However, typically you do not want this situation to trigger that flag because it does not represent a security issue, but simply normal operation. As shown in Figure 12-44, you can set the value of Ignore Conflict (Network Boot Agents) as TRUE under Administration > Server Manager > Server Configuration > Cluster-Wide Parameters > Profiler. In such cases, when a device is imaged by using PXE boot, no profiler conflict is triggered.

Summary

You now know all about setting up and using endpoint classification on CPPM. You can collect information to classify devices. You can analyze the collected information and take steps to audit the environment.

You can also use device categories in role mapping and enforcement policies to ensure that each type of device receives the correct level of access. And you can use device profiling as part of a system for enhancing the security of MAC-Auth and preventing MAC spoofing.

Learning checks

How do you enable CPPM to receive device fingerprint updates from Aruba? Integrate CPPM with CPDI.

Integrate CPPM with Central.

Enable auto endpoint profiler fingerprint updates in the cluster-wide parameters.

Import an XML file from the Administration > Dictionaries > Device Fingerprints page.

What steps do you complete to scan endpoints with SSH? (Select two.) Define SSH credentials and map them to the endpoints’ subnet.

Run a Discovery scan on the network.

Run a periodic poll on the endpoints’ NADs.

Run a Subnet scan on the endpoints.

How can you create a custom device fingerprint on CPPM? Import the new device fingerprint from an XML file.

Create the new device fingerprint and then import rules from a discovered device.

Create the new device fingerprint and then define rules for it manually.

Import the new device fingerprint from a third-party solution.

You want to configure the profiling action for a CPPM service, but you do not see the Profiler tab. What should you do? Recreate the service, selecting a template that includes “Profiling” in the name.

In the Service tab, change the template to one that includes “Profiling” in the name.

In the Service tab, select the Profile Endpoints check box.

Add a rule that uses the “IsProfiled” attribute to a role mapping or enforcement policy.

In which of these circumstances does CPPM set an endpoint’s Conflict attribute to true? When the endpoint first connects before it is profiled

When the endpoint category changes from unknown to “Computer”

When the endpoint category changes from “Cameras” to “Computer”

When the endpoint has fingerprints that match multiple device fingerprint entries

Note: For answers to all learning checks, refer to the Appendix.

13

Overview of Device Profiling with Central Applications

EXAM OBJECTIVES

✓ Define ClearPass Device Insight (CPDI).

✓ Understand client profiling integrated in Central Network Operations.

Assumed knowledge

Definition of device profiling and basic understanding of profiling methods

CPDI overview

With the proliferation of Internet of Things (IoT), companies need a specialized solution that can identify the many different types of devices that users are adding to the network. ClearPass Device Insight (CPDI) delivers the sophisticated device profiling companies need to gain insight and control over their ever-evolving device ecosystem.

You will begin this chapter by examining the CPDI solution and architecture. You will learn how CPDI supports some of the same profiling methods as ClearPass Policy Manager (CPPM), but it augments profiling with additional methods such as machine learning.

You will then look at another way customers can obtain client profiling information: client profiles integrated directly in Central Network Operations.

Why CPDI

Device profiling solutions should discover every device that touches the network and then identify the device type and OS. But most solutions struggle with IoT devices, as shown in Figure 13-1, calling many different types of smart devices generic Windows or Linux devices, for example.

Figure 13-1: Why CPDI

Not CPDI. This cloud-enabled solution provides automatic, comprehensive device discovery and profiling for the many types of devices that exist out in the wild today. It uses a broad range of techniques,including deep packet inspection (DPI) and machine learning, to characterize device traffic and match characteristics to fingerprints of known device types. In this way, Device Insight can tell admins that our example generic Windows device is actually a specific vendor’s security camera. If Device Insight detects any devices that it cannot identify, it groups those devices together in clusters based on similar attributes so that IT can easily classify them.Device Insight can also create custom device fingerprints so that it can correctly identify those IoT devices in the future.

Device profiling with CPPM vs CPDI

As you learned earlier, companies can get started with device profiling using ClearPass Policy Manager (CPPM). However, CPDI provides a richer feature set.

Figure 13-2: Device Profiling with CPPM vs CPDI

As shown in Figure 13-2, both CPPM and CPDI support device discovery scans, as well as passive fingerprinting methods such as DHCP, HTTP User-Agent strings, NetFlow, and sFlow. (CPPM and CPDI obtain the HTTP User-Agent string in different ways, but both can find it.)

However, CPPM is optimized as an authentication server and policy engine,while CPDI is dedicated and optimized to device profiling. It can use DPI to inspect traffic at a deep level. It further applies machine learning to look for patterns and cluster devices together based on these characteristics. It can detect patterns in device behavior and the types of applications and application categories that the device uses. It can also analyze communication patterns such as where the device tends to send traffic and at what bandwidth levels. CPDI can also track a device’s IP history, creating a consistent profile for the same client regardless of the IP changes. And it can look at the device’s DNS queries to see the hostnames it is accessing,not just the IP addresses. By analyzing all of this information and applying rules and machine learning to it, CPDI can accurately categorize endpoints and create rich endpoint profiles.

CPPM does have a few capabilities that CPDI lacks. CPPM can draw on information from the OnGuard agent (if used), as well as third-party servers. Because CPPM also authenticates clients, it can combine endpoint information with information about the user on that endpoint. Often companies will see the best results from integrating CPPM and CPDI. CPPM can then provide authentication information from CPDI, as well as draw on information delivered by CPDI in its policies.

CPDI architecture

CPDI consists of a hybrid on-prem and cloud architecture, which combines the advantages of on-prem data collection with cloud intelligence.

Figure 13-3: CPDI architecture

On-prem Data Collectors collect data about a company’s devices. CPDI Data Collectors are hardware appliances or VMs that are dedicated to collecting network data. They support several passive and active methods for gathering data. They start to process that data,extracting, for example, DHCP fingerprints from DHCP Messages and TCP fingerprints from traffic received on a SPAN port. The Collectors send metadata about what they have found to the CPDI Analyzer.

As shown in Figure 13-3, the Analyzer takes the information submitted by the Collectors to categorize devices using machine learning. Customers receive a complete inventory of their environment with rich information about each device. Each company has its own account on the CPDI Analyzer, connected to the company’s Aruba Central account. Aruba uses multi-tenancy to maintain boundaries between customers’ deployments so that each organization can only view information about its own devices.

CPDI licensing

To use the CPDI application, a company requires an Aruba ClearPass Device Insight subscription. Customers can choose from 1-, 3-, and 5-year subscriptions. The subscription entitles CPDI to profile a specific number of endpoint devices. Aruba offers subscriptions for many different numbers of devices: 100, 500, 1000, 2500, 5000, 10,000, 25,000, 50,000, and 100,000. Note, however, that the CPDI stand-alone application is not supported in MSP mode as of the release of this study guide.

A valid ClearPass Device Insight subscription entitles the organization to download as many copies of the virtual Data Collector image as desired. IT staff members can then deploy the virtual Data Collectors on their choice of hardware that meets the requirements specified by Aruba. The company must purchase hardware appliances separately, but they do not require separate licensing.

Data Collector collection mechanisms

You will now examine in more detail the Data Collectors, which are deployed together with the CPDI application. Data Collectors support several mechanisms for collecting information about devices. These mechanisms should be familiar to you, as they resemble those used by CPPM.

DHCP

The DHCP mechanism should be familiar to you, as it resembles the fingerprinting used by CPPM.

At each site you should add that site’s Data Collector as an additional IP helper on DHCP relays. Then Data Collectors can receive clients’ DHCP Discover messages and extract the DHCP fingerprints to send to the Analyzer, as shown in Figure 13-4. DHCP options collected include options 55, 60, and others.

SPAN

You should connect each Data Collector’s SPAN port to a port on a core network infrastructure. That switch should mirror traffic to the SPAN port. The Data Collector analyzes packets to discover information about clients’ conversations and applications. The information includes static attributes about devices, their IP addresses, and HTTP User-Agents. Data Collectors can also analyze traffic flows and learn the destination hosts and ports that each device is accessing. Based on that and other information, the Data Collector can determine which applications and protocols a device is using. By listening to DNS traffic on the SPAN port, the Data Collector can also discover domain names associated with IP addresses.

In short, collecting and analyzing SPAN gives CPDI insight into device behavior.

Figure 13-4: Data Collector collection methods—DHCP and SPAN

NetFlow/IPFIX/sFlow

NetFlow is Cisco traffic collection technology. NetFlow clients, which are typically Cisco switches, gather data about conversations, or flows, passing through them. They send the flow information to a collector for analysis. IP Flow Information Export (IPFIX) is based on NetFlow v9, but it is an open standard. Aruba Mobility Controllers (MCs) support IPFIX.

Another open standard alternative to NetFlow, sFlow, provides traffic sampling. Network infrastructure devices act as sFlow clients, which periodically select packets from the traffic flow and send those packets to a collector for analysis. The sFlow clients can also send interface statistics to the collector. AOS-CX switches support sFlow.

An Aruba Data Collector can act as a collector for all of these technologies. In this way, CPDI can gain insight into the destination hosts and ports with which each device is communicating, as well as the applications and protocols that the device is using. These technologies give CPDI some insight into device behavior, although less so than with SPAN.

Scans

Data Collectors support active scanning with SNMP, WMI, SSH, and Nmap. As you learned with CPPM, these scans give insight into devices’ MAC addresses, IP addresses, and device location, as shown in Figure 13-5. The Data Collector might also be able to determine the devices’ OS, open ports, and processes running on it.

Figure 13-5: Data Collector collection methods—NetFlow/IPFIX/sFlow and Scans

Initial classification workflow—With no user input

Now that you understand how the CPDI application collects data about devices, you will learn about how it classifies devices. You will look first at the classification workflow when CPDI users have not added any rules or taken any other actions.

Figure 13-6: Initial classification workflow—With no user input

As shown in Figure 13-6, CPDI Analyzer first checks the device attributes against system rules to see if it finds a match. System rules are built into the application without any action required from users. These rules include attributes such as DHCP fingerprints, open ports, and OS information.

If CPDI Analyzer finds a match with a rule, the device is added to the classified devices.

If no match exists for the device within the system rules, CPDI checks its MAC range classifiers. If it finds a match there, the device again becomes classified.

All devices that cannot be classified with system rules or MAC range classifiers become generic devices. In many solutions, users would be left with a pool of unclassified generic devices and not much help moving on from that point. CPDI distinguishes itself by taking a further step. CPDI Analyzer applies ML clustering to all of the generic devices. Instead of seeing a vast list of jumbled “generic” devices, users see a few clusters of similar devices, which they can more easily understand and address.

What data are system rules based on?

System rules can draw on multiple device attributes. You should understand where CPDI obtains these attributes so that you can make sure that your solution furnishes the necessary information.

System rules often use DHCP fingerprints, which CPDI can receive from Data Collectors, as shown in Figure 13-7, as long as those Data Collectors are properly set up as DHCP helpers.

System rules might also reference the destinations and destination ports that the client is using. CPDI Analyzer can receive this information from Data Collectors using scanning, the SPAN port, or Netflow/IPFIX. BGW telemetry can also furnish this information to the client profiling feature in Network Operations. Scanning, SPAN, and Netflow/IPFIX can also provide application information, which system rules can also use.

System rules can also reference a device’s open ports, SNMP information, and OS information—all of which can be discovered by Data Collector scans.

Figure 13-7: What data are system rules based on?

ML-based MAC range classification

If the system rules do not find a match for the device, CPDI can classify the device using MAC ranges. Often CPDI knows a device’s MAC address even before it collects additional information, so this method can be useful for giving the device a classification without having to wait for ML clustering to run.

Figure 13-8: ML-based MAC range classification

This classification method differs from a simple rule looking at the MAC OUIs assigned to various vendors. Just looking at the blocks assigned to vendors does not always show the true device type because many vendors make multiple types of devices. CPDI Analyzer, on the other hand, uses crowdsourcing and ML to make the MAC-based classification more useful and accurate. On the order of every few weeks, CPDI Analyzer looks across all tenants at rule-based classifications that meet various criteria (such as applying to at least 20 devices). It uses those rules to train itself to understand the MAC address ranges that are associated with various device types. As you see in Figure 13-8, the ML algorithm enables CPDI to filter out the “noise” of outlying MAC address-to-type correspondences. It can zero in on the range that indicates the device type with confidence.

ML clustering

CPDI applies ML clustering to generic devices with no classification every 12 hours at 0 UTC and 12 UTC. It runs for all tenants at the same time. If you check your generic devices in the time between when they are discovered and the next clustering process, you will see the generic devices labeled as clustering pending.

CPDI 2.0.1 supports three mechanisms for clustering. As shown in Figure 13-9, it first applies Latent Dirichlet Allocation (LDA) clustering to devices that have known MAC addresses and DHCP fingerprints. LDA clustering can also use label seeding. CPDI then applies TCP clustering to the devices that are still left unclustered, including ones without MAC addresses.

Figure 13-9: ML clustering

Latent Dirichlet Allocation (LDA) clustering

LDA is an ML algorithm for topic modeling. It analyzes documents and places them in topic-based sets, based on terms that the algorithm discovers are characteristic of the topic. A particular document might have characteristics of multiple topics, as shown in Figure 13-10, but LDA can look across all the terms and determine the most likely topic for the document.

When CPDI Analyzer uses LDA, a “document” is a device, and a “term” is an attribute like a DHCP fingerprint. LDA considers a device’s fingerprints, including DHCP fingerprint, MAC vendor, and HTTP User-Agent string. It also considers the flow data, such as the applications that device uses, the destination IP addresses that the device accesses, and the bandwidth that the device consumes. The device’s DNS domain also comes into play. Using LDA, CPDI Analyzer assesses the “distance” between devices’ sets of attributes in order to cluster similar devices (devices with smaller distances between their attributes). In other words, it finds devices that have attributes in common and also have attributes that distinguish them from other clusters.

Figure 13-10: Latent Dirichlet Allocation (LDA) clustering

Cluster recommendations

While CPDI only shows users the generic devices in a cluster, it actually applies the clustering algorithm across all of a tenant’s devices, including both classified and generic devices. In this way, CPDI can discover classified devices with similar attributes to a generic device cluster. CPDI can then use the classified devices to provide users with a recommendation for classifying the generic device cluster.

For example, a retailer might have several Symbol barcode scanners, as shown in Figure 13-11. CPDI might have succeeded in classifying some of these devices. Other devices do not quite match the rules or ML-based MAC classification and remain unclassified. However, when CPDI Analyzer runs the clustering, it discovers that the classified scanners and the unclassified devices have many attributes in common. It creates a cluster of the unclassified devices and presents a recommendation that these might be Symbol Scanner devices.

Figure 13-11: Cluster recommendations

If the cluster includes classified devices of multiple types, CPDI will present multiple recommendations. It will accompany each recommendation with a percentage, based on the percentage of classified devices in the cluster of that type.

Classification recommendations and label seeding

But sometimes LDA produces a cluster without any classified devices, which means that CPDI cannot provide a recommendation. This is most likely to occur with smaller customers or with less popular and less frequently used devices. To address this issue, Aruba adds label seeding to LDA. Aruba creates a “seed set,” which consists of the LDA output of the less popular classified devices from across all tenants. CPDI Analyzer can then use that seed set to maximize the chances that every cluster will have at least one classified device in it.

Figure 13-12: Classification recommendations and label seeding

For example, Tenant A might have just a few temperature readers deployed, as shown in Figure 13-12. None of these devices are classified by system rules. Without label seeding, Tenant A users would see a cluster with no recommendation. But Tenant B has similar devices that were classified as a temperature reader. Using the seed set, CPDI Analyzer recognizes that Tenant A’s device cluster has attributes similar to Tenant B’s readers. It recommends to Tenant A that its device cluster might be temperature readers.

Note that this process occurs in the background, and Tenant A users do not receive any information about Tenant B’s devices.

Auto-classification through cluster recommendations

Typically, CPDI Analyzer leaves the generic devices in the generic device cluster and waits for a user to accept the recommended classification or apply a different classification. However, CPDI automatically classifies the generic devices itself if the top recommendation meets two criteria. First, the percentage must be 95% or above. Second, the number of classified devices associated with this recommendation must be 10 or more.

Figure 13-13: Auto-classification through cluster recommendations

In the example shown in Figure 13-13, LDA creates a cluster that includes several generic devices, as well as 10 devices classified as point of sale (PoS) devices. Because all of the classified devices are the same type, CPDI automatically classifies the generic devices as the same type.

User classifications and user rules

Using CPDI recommendations as well as your own investigations, you can determine the correct classification for a cluster. You apply that classification to the cluster as a whole. All the devices in the cluster then move to the classified devices list. If other devices of a similar type are added later, and no rules can classify them either, CPDI will run ML clustering on them. CPDI will likely find that the new devices belong to the same cluster as the already classified devices and recommend a classification for them. You can then classify the new devices.

However, you can make this entire process faster and easier by also adding user rules, as shown in Figure 13-14, which will classify the new devices immediately. You can define user rules from scratch based on a broad variety of attributes. But CPDI makes it easier for you to define these rules. You can select a generic device or a user-classified device and choose to create a rule from it. Then simply select the attributes characteristic of the device and make a rule. When you save the user rule, you can optionally apply it to existing devices then. No matter what your choice, the user rule will apply to devices that are discovered later.

Figure 13-14: User classifications and user rules

You can combine the two forms of classification to easily classify your devices. You can select a cluster and classify it based on the recommendation. Then you can go to the user-classified devices, choose one of the devices, and create a user rule from it. Then new devices will be classified based on that rule without having to go through ML clustering. Or you can first create the rule based on a generic device and then classify the cluster. The choice is yours, but the end result is much the same.

Classification workflow—With user input

In Figure 13-15, you see a summary of how CPDI classifies devices after users have classified clusters and created rules. As you see, CPDI applies the user rules first before any system rules or MAC Range Classifiers.

Figure 13-15: Classification workflowßžWith user input

Users can delete rules or cluster assignments. This action affects already classified devices as well as devices discovered later. The devices that were earlier classified by that rule or cluster assignment are returned to the generic devices pool, and CPDI applies ML clustering to them.

Use client profile information integrated in Central

In the next chapter, you will dive deeper into how to actually deploy and use the CPDI application. First, however, you will briefly look at similar client profiling capabilities that are integrated directly in Central Network Operations without the need for deploying the CPDI application. (These capabilities were added in Central 2.5.3 and above.)

Client profiling integrated in Central Network Operations

Central Network Operations provides integrated client profiling capabilities.

Central uses telemetry from network devices that are managed by Central, as shown in Figure 13-16. Network telemetry consists of data that the network devices extract from traffic flowing through them and that they stream in real time to Central. For example, network infrastructure devices can track the MAC addresses in traffic and inform Central of those MAC addresses.

Figure 13-16: Client profiling integrated in Central Network Operations

Using the telemetry information, Central can learn a variety of attributes about each client. It can then use those attributes to categorize clients. Client profiling in Network Operations relies on system rules and MAC range classification. Network Operations even supports auto-rules, which use ML to automatically create new rules to classify devices, focusing on the most important features and filtering out the noise.

In addition to viewing a client’s category, family, and type within the Central client profile, admins can see all of the client’s attributes, as well as track the client’s network activity.

Data collected by telemetry for client profiling

You will now examine the telemetry information provided by Aruba network devices, which is summarized in Figure 13-17.

Figure 13-17: Data collected by telemetry for client profiling

To deliver telemetry data to Central, the Aruba InstantOS version must be 8.7.0.0 or above. APs can provide MAC information, DHCP information, and HTTP User-Agents.

Gateways submit the same telemetry information as APs, but also much more. They can discover the device OS. Additionally, they can collect information about traffic flows, including applications, protocols, destination connections, and domain names. An SD-Branch Gateway must run Aruba OS version 8.7.0.0-2.3.0.0 or above. Gateways of any type support telemetry with AOS10.2 or above.

Central 2.5.4 can also receive MAC addresses from AOS-CX switches; the switches must run AOS-CX version 10.8 or above.

Note that these particular capabilities might change with software updates, so check the latest release notes.

Client profiling included in Network Operations license

The company does not require a separate license to use the client profiling features in Central Network Operations; these features are included with Foundation or above licenses. (In the future, additional features might require Advanced licenses.)

Prerequisites for ensuring client profiles display

Central Network Operations’ client profiling can automatically begin collecting information about all clients in gateways’ and APs’ user tables. However, to ensure that Central can collect all relevant attributes, you should check a couple of settings. Make sure that the gateways or APs apply DPI and application visibility to the clients. You must enable these settings globally. For example, on gateways, go to the Security > Applications settings, as shown in Figure 13-18. Then enable firewall visibility and DPI. When you enable these features, you must reboot the devices. For DPI to apply to a client, it must be enabled globally and on the client’s role. However, DPI is enabled on the role by default, so it should take effect on all clients after you enable it globally (unless you have manually disabled the feature on the role).

Figure 13-18: Prerequisites for ensuring client profiles display

View client profiles

You can see the client profiles and classifications within the Network Operations application. Go to the Clients page within the Global or Sites view. Then click the Clients Profile. Note that the Clients Profile tab is not available for the Clients pages in a Group view.

The Clients Profile page shows all of the clients known by Central, for the Global view, or all the clients at the site, for the Sites view. Clients are grouped by type. Central automatically assigns this type based on the network device telemetry and system rules. You do not need to take any further steps. You can click any of the client type cards and see the clients assigned to that type.

An example is provided in Figure 13-19. The view and capabilities might change in the future.

Figure 13-19: View client profiles

View client profile details

When you click a client in the client list, you will drill down into a view of that client. Central collects a variety of information about clients, including client profiling data, available in a Profile tab. Here you see the device’s category, family, and type (or OS), as shown in Figure 13-20. You can also see all the attributes collected through telemetry.

Figure 13-20: View client profile details

View device network activity

Scroll down and examine the Network Activity section to answer questions about the device’s network activity and behavior. As shown in Figure 13-21, the left of the display shows each application that the device is using while the right shows the destinations. A bar forms between each application and the destination on which the device is accessing that application. If a device is accessing that application on more than one destination, the application bar splits into multiple smaller bars, as you see for “dns” in the example. By default, the application splits into at most five destinations, which are the top five for that application. But you can adjust the graph to show different numbers of destinations. If a device is accessing multiple applications on the same destination, you will see the application bars merge onto that destination, as shown for 10.1.141.255 in Figure 13-21.

Figure 13-21: View device network activity

The width of each bar corresponds to the relative number of packets for that application/destination versus others. You can hover over the bar to see more details such as the bandwidth associated with that application and destination pair.

You can use this information to see at a glance the general patterns for this device’s traffic. If you have reason to suspect that a client has been compromised, the network activity can provide a clue. Many clients send the bulk of their traffic to a few destinations. Does a client suddenly start to send traffic to many destinations? This could be a sign of a hacker scanning the network or attempting to spread.

You can also adjust the time range for the Network Activity graph. You might use this feature to investigate potential issues. For example, if you see that the application/destination list looks quite different over the past 4 hours as opposed to the past two weeks, this might be a clue that a device has been compromised

Tags

A tag is a descriptive string that is applied to a client based on whether the client meets the conditions defined in a tag. These conditions include the client category, family, and type, as well as attributes such as user name, DHCP options, destination connections, and many more.

You can apply a tag to filter the client profile view and see only clients with that tag. You also see all the tags that apply to a client when you view the client profile.

Figure 13-22: View device network activity:Tags

Two types of tags are supported, as shown in Figure 13-22.

System tags are predefined for you. They mostly filter devices by category such as printers, medical devices, or point of sales devices. To apply a system tag, click the Tags button in the Client Profile page. Select System tag and choose the desired tag. CPDI will then show only the devices that match that tag.

Users can create their own tags. Click the Tags button and select Create a tag. You can then name the tag and specify the desired conditions. You can then apply the tag to filter the display by clicking the Tags button and selecting User tag. You can also see that tag in the detailed client profile for any client that matches the tag.

System tags in Central 2.5.4 include:

Expected transition

Suspected transition

Library update transition

Point of Sale devices

Collaboration and communication

Networking and switching

Computers and servers

Audio and video

Mobile and gadgets

Facilities and building automation

Printers

Medical devices

IOT

Summary

Congratulations! You have completed Chapter 13. You should now understand how Aruba CPDI provides companies with richer visibility into their network devices. You also took a look at client profile information that is integrated within Central Network Operations. In the next chapter, you will dive into more detail about the stand-alone CPDI application, learning more about deploying and using it.

Learning checks

When CPDI applies LDA clustering to generic devices, how does it produce recommendations for the cluster classification? It sends the cluster to Aruba experts who make the recommendation.

It uses the MAC address ranges assigned to vendors by IEEE.

It looks for classified devices that exhibit similar attributes.

It uses system rules to create the recommendations.

Note: For answers to all learning checks, refer to the Appendix.

14

Deploy ClearPass Device Insight

EXAM OBJECTIVES

✓ Define and deploy Aruba ClearPass Device Insight (CPDI).

✓ Analyze endpoint classification data on CPDI.

Assumed knowledge

Definition of device profiling and basic understanding of profiling methods

Fundamental ClearPass Device Insight concepts

Deploy the CPDI stand-alone application and Data Collectors

ClearPass Device Insight (CPDI) delivers the sophisticated device profiling companies need to gain insight and control over their ever-evolving device ecosystem. In this chapter, you will learn how to provision the CPDI application within Aruba Central and add Data Collectors. You will further learn how to set up data collection mechanisms to get the solution running.

Select ClearPass Device Insight for the Central account

You will now learn how to deploy the CPDI application.

First, the company requires an Aruba Central account. Customers can access the arubanetworks.com site and click a link to register for a Central account; this link automatically redirects customers to the correct signup URL for the customers’ region.

Customers should follow the instructions for registering for the account. When they reach the Interested Apps section, they should make sure to select ClearPass Device Insight, as shown in Figure 14-1. (Customers can select both Network Operations and ClearPass Device Insight if they want to use Central to manage the network, too.)

Figure 14-1: Select ClearPass Device Insight for the Central account

After customers complete the registration process, Aruba sends an email to the account entered during the registration process. Customers should then follow the instructions in that email to activate the account.

Provision CPDI in Central

When ClearPass Device Insight is selected as an Interested App, it appears in the Central Account home page. To start using CPDI, you must provision the app. First click Get Started, as shown in Figure 14-2. The Aruba cloud then sets up a CPDI account for the organization.

Figure 14-2: Provision CPDI in Central

After this process completes, you can click Launch to access the CPDI Dashboard for the account.

Deploy Data Collectors

Next, you will learn how to deploy Data Collectors. Data Collectors are not strictly required for the CPDI solution because CPDI can also draw on telemetry information. However, many companies will want to use Data Collectors in order to obtain the maximum amount of information possible about devices. If the company chooses to use Data Collectors, you should generally deploy one Data Collector at each campus, site, or data center with endpoints you want to profile. Following this guideline prevents too much traffic from flowing over WAN links.

Figure 14-3: Deploy Data Collectors

As shown in Figure 14-3, you will begin by installing the physical or virtual Data Collectors. Next, you must obtain a Data Collector Registration Token from within the CPDI application. You will reference that token when you run the Data Collector CLI on your Data Collectors. You will also configure several other settings in the CLI to get the Data Collector connected to the network and detected in CPDI.

Finally, you will add the detected Data Collector to CPDI’s list of Data Collectors.

The sections that follow provide more information about each step in this process.

Data Collector options

Customers have several options for the Data Collectors that they install.

As mentioned earlier, they can download the virtual appliance and run as many instances as they want. As shown in Figure 14-4, a virtual Data Collector appliance must be deployed on VMware vSphere 6.0 or later. You should then size the VM for the appliance based on the size of the site that the appliance will support. Aruba also recommends an Intel Ivy Bridge CPU or later.

Figure 14-4: Data Collector options

Alternatively, the company can purchase hardware Data Collectors from Aruba. Aruba currently provides one model type, which supports 20,000 devices.

Neither the virtual nor the hardware Data Collectors require licensing separate from the Aruba ClearPass Device Insight subscription.

Ports on Data Collectors

To understand how to install the Data Collector,you need to be familiar with its ports. As shown in Figure 14-5, the Data Collector Appliance has one Management port, one Data port, and multiple SPAN ports, some of which support 1GbE and some of which support 10GbE.

Figure 14-5: Ports on Data Collectors

As shown in Figure 14-5, virtual Data Collectors have four ports, but only the Management port is required. If you want to use multiple ports, the VMware admins will need to create multiple virtual NICs for the VM and connect each to the correct network. Inside the VM, the Management port corresponds with the eth0 interface, and the Data port corresponds with the eth1 interface. However, this numbering does not necessarily correspond with the numbering for the connected virtual network adapter. The virtualization platform admins can determine the virtual network adapter for the Management port by finding the adapter with the lowest numbered MAC address. The adapter for the Data port will have the second lowest MAC address. The two SPAN ports have the highest MAC addresses.

In practice, these NICs might be sharing the ESXi host’s physical NICs with other VMs. You should ensure that the SPAN ports can send and receive at least 1Gbps.

Guidelines for the Data Collector’s Management and Data ports

You must always connect the Data Collector’s Management port and ensure that it receives an IP address. You can set the IP address statically, or the port can obtain an address with DHCP. The Data Collector uses this port to communicate with Central and CPDI.Typically, the collector also uses this port to receive passive profiling information, including DHCP traffic and NetFlow/IPFIX/sFlow packets. It also uses this port to run active scans, as shown in Figure 14-6.

Figure 14-6: Guidelines for the Data Collector’s Management and Data ports

The Data Collector also supports an optional Data port. If you choose to connect the Data port, it requires its own IP address. The Data Collector then uses the Data port to receive passive profiling information and run active scans. You generally only use this port if the corporate policy mandates separating the management and profiling data.

Summary of network services required for Data Collectors

You should make sure that the perimeter firewall permits the Data Collector to access Central/CPDI. It must permit outbound TCP 443. As shown in Figure 14-7, if you want the Data Collector to use an external NTP or DNS server, the firewall must also permit the Data Collector to access these servers.

Figure 14-7: Summary of network services required for Data Collectors

If the internal network infrastructure is implementing ACLs to restrict devices’ access, make sure to permit the Data Collector sufficient access for it to perform its responsibilities. As shown in Figure 14-7, you should allow the Data Collector to communicate with endpoints on all UDP and TCP ports so that it can perform WMI and Nmap scanning. ICMP is also required. Remember that the Data Collector uses its Data port IP address for these scans unless its Data port is unconnected, in which case it uses the Management port IP address. TCP 22 is required for SSH scans; however, if you are enabling full TCP access for other scans, you do not need to permit this port specifically. You should also permit the Data port IP address (or, if none, Management port) to send traffic to network devices on UDP 161 and to receive traffic on UDP 162. Then the Data Collector can scan network devices with SNMP. If the Data Collector is using internal NTP and DNS services, make sure to permit the Management port IP address to communicate with these servers on UDP 123 (NTP) and TCP/UDP 53 (DNS).

Guidelines for Data Collector Span ports

The Span ports are optional, but recommended. These ports have no IP addresses. The Data Collector listens for traffic on these ports and analyzes the traffic to determine device behavior.

Figure 14-8: Guidelines for Data Collector Span ports

Wherever possible, choose a SPAN location where you can capture all north/south traffic between the endpoints and the Internet. In the example shown in Figure 14-8, Internet traffic for all clients passes through the core switch. You can connect the Data Collector SPAN port to a port on the core routing switch. You then create a mirror on this switch, which monitors the port that connects to the Internet and has as its destination the port that connects to the Data Collector SPAN port.

If a site is architected such that you cannot mirror all Internet traffic to the Data Collectors SPAN port, give priority to ensuring that the port receives IoT devices’ Internet traffic.

Installing a virtual Data Collector

Keeping these guidelines in mind, you are almost ready to install the Data Collector. For a physical appliance, follow the steps in the installation guide to connect the device to the network and power it up.

To install virtual Data Collectors, first download the virtual appliance by going to the Central Account Home > Data Collectors page. In the Get Started card, click get a virtual appliance, as shown in Figure 14-9. The OVA file for the appliance downloads.

Figure 14-9: Installing a virtual Data Collector

Give the file to VMware admins to use to deploy the Data Collector as a VM. Communicate a few guidelines. They should use a thick-provisioned, lazy-zeroed disk. They should also reserve resources specifically for the VM. The VM will have four network adapters. They should connect the network adapters based on the plan and guidelines discussed earlier. For example, if they are using a Management port but no Data port and one SPAN port, they can use the design shown in Figure 14-9. The network adapter with the lowest MAC address is placed in the VLAN in which the company wants to place the controller’s Management port. The adapter with the third lowest MAC address is placed in a network dedicated to SPAN. The network infrastructure often mirrors untagged traffic and tagged traffic in multiple VLANs to this port. VMware admins should configure the network for the SPAN port to use VLAN 4095, which means that the virtual switch simply passes all untagged and tagged traffic.

Obtain registration tokens

You are almost ready to set up the installed Data Collector. Part of the setup process involves inputting a registration token on the Data Collector.

Figure 14-10: Obtain registration tokens

To obtain this token, go to the CDPI Account home > Global Settings > Data Collectors page, as shown in Figure 14-10. If the CPDI account does not have any Data Collectors yet, you should use the Get started wizard. Otherwise, you can go to the Data Collectors page.

In either case, click Registration Token and copy the token. Paste the output into a file so that you are ready to upload it on your Data Collectors.

Perform the initial setup in the Data Collector CLI

Power on the Data Collector and connect to its console. You will be presented with the Collector CLI, as shown in Figure 14-11. Enter aruba as the default username and password.

Figure 14-11: Perform the initial setup in the Data Collector CLI

You will be presented with a menu of options. Use these options to compete the initial configuration for the Data Collector.

Set a hostname. Then configure the networking settings. The eth0 interface is the Management port. Configure the IP settings for this port, including the DNS server and any routes and proxy settings required to enable the Data Collector to reach the Internet on this port.

Again using the menu, set the timezone and point the Data Collector to an NTP server.

Test connectivity with the Aruba cloud using the menu option. You can then register the appliance using the code that you previously collected. After you see the message that the registration was successful, it will take about 20 to 30 minutes for the Data Collector to establish a connection to the Aruba cloud and update its software.

Add Data Collectors in Central

Registering the appliance automatically directs it to your account in Central. The appliance is added to a list of appliances that can be created as Data Collectors in your CPDI deployment.

Figure 14-12: Add Data Collectors in Central

Return to the “Get started” or “Data Collectors” page by going to your Central Account and selecting Data Collectors. Now select the Create Collector option.

As shown in Figure 14-12, you will see a list of detected appliances. Select all the appliances that you want to add and click Create.The Data Collectors will be added to the Data Collectors page. You can now manage the collectors and configure settings such as active scans on them.

Set up CPDI users

You need to create users who are allowed to manage the stand-alone CPDI application. Go to your Central Account Home and click Users and Roles. As shown in Figure 14-13, you can then add a new user by clicking Add User. Or you can edit one of the existing users.

Figure 14-13: Set up CPDI users

If you are adding a user, fill out the user’s email address. Whether you are adding a user or editing a user, you will see several drop-down menus for the user’s role.

Account Home—This drop-down menu controls rights to the Account Home and global settings within it. A user with “admin” rights to Account Home also has full rights to any application enabled through the account, including CPDI.

Network Operations—This drop-down menu controls rights to the Network Operations portion of Central. However, this is not your focus for this study guide.

ClearPass Device Insight—This drop-down menu controls rights to CPDI. Assign the “admin” role to any user who should be able to view and configure settings within CPDI. Assign the “read-only” role to users who can view discovered devices. These users can also view settings, but not change them. Assign the “deny-access” role to any users who are added to the account, but whom you do not want to be able to use the stand-alone CPDI app.

Obtain data on the Data Collectors

You will next learn how to set up the network infrastructure and the ClearPass Device Insight application to ensure that the Data Collectors obtain data about devices.

Figure 14-14: Obtain data on the Data Collectors

As shown in Figure 14-14, you will first learn about setting up the network infrastructure to send the data necessary for passive profiling, including configuring the necessary DHCP relay settings,as well as mirroring traffic to Data Collectors SPAN ports. You can optionally set up NetFlow and sFlow as well.

You will then learn how to configure active scanning on Data Collectors. When you first log in to CPDI, you will be prompted to accept or edit the Catch All Subnets segment configuration. After you do so, you can create your own subnet segments. You can then create augmentation methods and attach those methods to subnet segments. As you will learn in more detail in a moment, the subnet segments and augmentation methods control what scanning methods Data Collectors apply to what IP addresses. After you have configured these components, you can schedule discovery and subnet scans.

Configure DHCP helper settings

Most corporate LANs use DHCP relay to direct clients’ DHCP requests to a “helper address,” which is the corporation’s centralized DHCP server. The default router for a subnet typically acts as the DHCP relay for that subnet. In most two-tier networks, a core routing switch (or VSX pair) acts as the default router; in most three-tier networks, aggregation switches (or VSX pairs) act as the default router.

Figure 14-15: Configure DHCP helper settings

To copy DHCP information to the Data Collector, configure whatever device is already acting as DHCP relay. Add the Data Collector’s Data Port IP address to the list of IP helper addresses for every subnet on which you want to enable device profiling. Or, if the Data Collector is not using the Data Port, as in the example shown in Figure 14-15, add the collector’s Management Port IP address as an IP helper. Be careful to leave the current IP helper address as well, so that clients continue to receive dynamic addresses from the DHCP server.

Usually APs forward traffic into the LAN at Layer 2, so they do not need to act as DHCP relays. If your APs are acting as the DHCP relay for any subnets, though, you would add the Data Collector as an IP helper in those APs’ settings.

Set up mirroring to Span Ports

As discussed earlier, it is important for the Data Collector to be able to gather a broad range of traffic from clients across the site. Typically you should deploy the Data Collector at a point where it can receive all inbound and outbound traffic on the site’s Internet connection.

Figure 14-16: Set up mirroring to Span Ports

Often the core network infrastructure device is actually a pair of switches using a virtualization technology such as VSX and the uplink to the Internet is a multi-chassis link aggregation group (M-LAG). To minimize traffic flowing over the inter-switch link (ISL) between the VSX switches, you can connect both switches to one of the SPAN ports on the Data Collector. Then configure both switches to mirror traffic from the M-LAG (lag1 in the example shown in Figure 14-16) to the port connected to the Data Collector. From the point of view of the Data Collector, it simply receives some conversations on one port and some on another. (Or for a virtual Data Collector, you might connect the two VSX switches to two ports on an ESXi host that hosts the collector VM. These ports would be uplinks on a virtual switch, which has a network to which the collector’s SPAN network adapter is connected.)

Also pay attention to the bandwidth on the Internet link. While it is possible to connect multiple 10Gb SPAN interfaces on the Data Collector, the Data Collector cannot process the full 20Gbps. If the physical SPAN interfaces will be receiving more than the supported throughput for your appliance, you should use class-based mirroring to select only specific traffic for mirroring. The hardware appliance suports a maximum of 2Gbps throughput. For virtual appliances, the throughput depends on the sizing for the ESXi host and VM resources. The most helpful protocols to include in the class are: DHCP, ARP, HTTP, HTTPS, DNS, and SSH. The same applies for sending traffic from a packet broker such as Gigamon.

Use these commands to configure a mirror for this scenario on AOS-CX switches in a VSX pair:

VSX-1(config)# mirror session 1

VSX-1(config-mirror-1)# source interface lag1 both

VSX-1(config-mirror-1)# destination interface 1/1/10

VSX-1(config-mirror-1)# enable

VSX-2(config)# mirror session 1

VSX-2(config-mirror-1)# source interface lag1 both

VSX-2(config-mirror-1)# destination interface 1/1/10

VSX-2(config-mirror-1)# enable

If you need to use class-based mirroring and the network uses IPv4, use these commands:

VSX-1(config)# class ip span

VSX-1(config-class-ip)# 10 match udp any any eq 67

VSX-1(config-class-ip)# 20 match tcp any any eq 80

VSX-1(config-class-ip)# 30 match tcp any any eq 443

VSX-1(config-class-ip)# 40 match tcp any any eq 53

VSX-1(config-class-ip)# 50 match udp any any eq 53

VSX-1(config-class-ip)# 60 match tcp any any eq 22

VSX-1(config-class-ip)# exit

VSX-1(config)# mirror session 1

VSX-1(config-mirror-1)# destination interface 1/1/10

VSX-1(config-mirror-1)# enable

VSX-1(config-mirror-1)# exit

VSX-1(config)# policy mirror_span

VSX-1(config-policy)# 10 class ip span action mirror 1

VSX-1(config-policy)# exit

VSX-1(config)# interface lag1

VSX-1(config-if-lag1)# apply policy mirror_span out

VSX-1(config-if-lag1)# apply policy mirror_span in

VSX-1(config-if-lag1)# exit

You would repeat the same steps on the other switch in the VSX pair.

Initial login to ClearPass Device Insight

After you set up the network infrastructure, you are ready to log in to CPDI and set up active scanning.

Figure 14-17: Initial login to ClearPass Device Insight

When you first log in, you will be prompted to access or edit the configuration for the “Catch All Subnets” segment. As shown in Figure 14-17, this segment includes all private subnets by default:

10.0.0.0/8

192.168.0.0/16

172.16.0.0/12

While you can technically have Data Collectors run subnet scans on “Catch All Subnets,” such a scan would take much longer to run than a targeted scan on the subnets that you know the company is actually using. Typically you should accept the default “Catch All Subnets” config and simply plan to create your own subnet segments, which you will actually use, later.

After you accept the config, you will be placed in the Classified Devices - Dashboard page. The Data Collectors that you added earlier will be activated with DHCP and SPAN enabled on them.

Understand subnet segments

When you run a subnet scan, you must select a segment or segments on which to run the scan. The segment definition specifies the IP addresses to be scanned, as well as controls the augmentation methods for the scanning.

When you create a segment, you define these settings for it:

Which Data Collector or Collectors are responsible for that subnet—If a company has multiple sites, Aruba recommends that each site has at least one local Data Collector. You should set up at least one segment for each site and then associate the segment or segments with the Data Collector deployed at that site.

Figure 14-18: Understand subnet segments

Which augmentation methods are enabled on that subnet—An augmentation method indicates a scanning type and credentials for using that type of scanning. Rather than create one segment subnet per site, you might create multiple segments per site, as shown Figure 14-18. You can then set up different augmentation methods on different types of devices. For example, you might create segments just for your network devices, which use the SNMP augmentation method. As another example, the company has main building, B1, at site 2 with many printers, cameras, and domain computers. It also has a lab with Linux devices. You could create separate subnet segments for each type of device and assign different augmentations to each segment. Specifying different subnet segments with different augmentation methods also enables you to specify different credentials for different subnets. In short, you can flexibly assign whatever augmentation methods make sense for any particular use case.

You should not specify overlapping subnets in different segments. If you do, you will see a message about the overlap and be encouraged to fix it.

Create subnet segments

To create a subnet, go to the Discovery Settings page. Click New Subnet Segment.

Name the segment and assign it to the Data Collector at the site with that subnet. To specify the subnet itself, you can click Add and type in the subnet address and description manually. You can click Add multiple times to add multiple subnets to the segment. Alternatively, you can click Browse and import a CSV file with the subnet addresses and descriptions, as shown in Figure 14-19.

Figure 14-19: Create subnet segments

Create augmentation methods

Still in the Discovery Settings page you can add the augmentation methods. Click New Aug method and define the method type. Then specify the settings particular to that type, as shown in Figure 14-20. The settings for SNMP, SSH, and WMI are very similar to those about which you learned for CPPM External Accounts. Nmap does not require any particular credentials. You simply create the method so that you can attach it to a subnet segment and indicate that you want to run Nmap on that segment.

Figure 14-20: Create augmentation methods

As part of creating the augmentation method, you can choose existing subnet segments to which to attach that method. Alternatively, after you create the method, you can edit a subnet segment and attach the desired methods to it.

The following sections provide more information about augmentation methods.

SNMP

If your network devices use SNMPv1/v2c, you should specify “SNMPv1 with community strings” or “SNMPv2 with community strings” for the Version. Then set the community name to match a read-only community on the network device.

If the network devices require SNMPv3, you must choose of the SNMPv3 options, matching the requirements and algorithms with those used on the network device. The network device admins should tell you the credentials, security levels, and algorithms used for an account that has read-only (or read-write) access. Under the version, you specify whether authentication is required, the algorithm used for authentication if required, and whether privacy is required in addition to authentication. If you select privacy, you choose the privacy protocol in a separate field. After choosing an SNMPv3 version, you specify the username and keys for the read-only account. You will also see key fields for the particular types of security that are required. (In other words, if you choose a version that requires authentication, you must set an authentication key. If the version further requires privacy, you must set a privacy key.) The network admins should tell you the key values as part of the credentials for the account.

SSH

When you choose “SSH” for the Type, you must specify a valid username and password for SSH access to the device.

Domain/WMI

For “Domain/WMI” accounts, you specify the domain name, the username, and the password. CPPM will use this format when logging into a device with these credentials: domain_name\

username. Choose a user account that has administrative access to the domain computers.

Schedule a Discovery scan to discover NADs

Typically, you should run an initial Discovery scan next. This scan, similar to CPPM’s Discovery scan, is usually intended to discover network access devices (NADs), such as switches and APs, for Data Collectors to probe. The Discovery scan works with the SNMP augmentation method. Before you schedule the scan, create a subnet segment that includes the NADs’ IP addresses and make sure to attach an SNMP augmentation method to that subnet. That method should, of course, specify SNMP credentials that match those on the NADs.

Schedule the scan by going to the Edit Collector page for the Data Collector that you want to run the scan (go to Menu > Discovery Settings > All Collectors and click the Edit icon in the desired collector’s card). Then click the Add icon in the Device Discovery card.

When you schedule the scan, you specify one or more seed devices. You should generally select the core routing switch or switches at the site as the seed. The Data Collector begins by sending an SNMP Get message to each seed, asking for several pieces of information: the device’s sysObjectID (its system name), its bridge MIB, its interface list, its LLDP neighbors, its CDP neighbors, and the ARP table.

The CDP and LLDP tables provide the Data Collector with a list of devices connected to the seed at Layer 2. The Data Collector uses the System type (such as bridge) to determine which LLDP and CDP neighbors to add as Network Access Devices (NADs) on this Data Collector.

Figure 14-21: Schedule a Discovery scan to discover NADs

If you want the Data Collector to send SNMP Get messages to the devices discovered in the seeds’ CDP and LLDP tables, you must set a scan depth greater than 1. The scan depth dictates how many times the Data Collector repeats the scanning process. In the example network shown in Figure 14-21, a scan depth of 3 takes the scan to the AP level.

As mentioned earlier, the Data Collector also collects information about device’s ARP tables. It uses this information to correlate discovered MAC addresses and IP addresses. By default, the Data Collector does not scan the IP addresses that it discovers in the ARP table. But if you enable probing ARP entries, the Data Collector sends SNMP Get requests to all of the devices in the ARP table. However, enabling this option could make the scan much longer as the ARP table typically includes many client devices as well as network infrastructure devices. In addition, you usually do not want client devices potentially getting added as NADs if they respond to the SNMP messages.

After scanning with SNMP out to the scan depth, the Data Collector scans all discovered devices with any other augmentation methods that you configured for the subnet associated with the device.

NAD management

The Discovery scan adds the network infrastructure devices in your network to CPDI. You can view them in the All NADs page. Each NAD is associated with the Data Collector that discovered it. (Hardware Data Collectors can support up to 500 NADs.) Initially, all NADs are disabled. You can then choose which discovered devices are actually NADs that you want to poll. You can select a NAD and enable it individually. Or, you can select the Action menu, select Bulk Changes, and enable multiple NADs.

Figure 14-22: NAD management

As shown in Figure 14-22, the Data Collectors periodically poll the devices. They use SNMP to ask for the Bridge MIB and ARP table. This information helps CPDI to determine which detected devices are still active, as well as to correlate IP addresses with MAC addresses. If the NAD’s subnet has any other augmentation methods attached to it, the Data Collector also periodically scans the NAD with those methods. You can adjust the poll frequency in the All NADs page.

Sometimes the Discovery scan might miss some NADs. As shown in Figure 14-22, you can add these devices manually with their individual IP addresses. Select Add New NAD in the All NADs page and specify the NAD IP address as well as the Data Collector to which the NAD is assigned. The NAD is then added, and the Data Collector uses SNMP to scan the device and collect its sysObjectID, Bridge-MIB, interface table, LLDP table, CDP table, and ARP table.

Alternatively, you can add all the switches in a subnet through auto discovery. Select Add New NAD and then select Discover NADs from Subnet and select a subnet segment. Then the Data Collector scans that subnet and adds any device on which UDP 161, the port for SNMP, is open. You must configure SNMP augmentation for the subnet on which you want to discover the NADs. This method lets you add a subnet if your discovery scan failed to add some of the devices that you expected.

Schedule subnet scans for endpoints

You should generally use subnet scans to collect information about endpoints.

Figure 14-23: Schedule subnet scans for endpoints

You schedule subnet scans on Data Collectors in much the same way that you schedule discovery scans. From the Discovery Settings page, select a Data Collector. Then add a Device Discovery. Select Subnet for the scan type. Then select one of the segments attached to that Data Collector. When the scan runs, the Data Collector scans each device in the subnet segment using the augmentation methods associated with the selected segment, as shown in Figure 14-23.

As part of the scan configuration, specify a schedule. For example, you might choose to run a daily scan in the middle of the night. However, you need to keep in mind when devices are present, as well as the particular requirements of the organization.

Analyze CPDI data (standalone application)

You are now ready to view and use the information presented by CPDI. You will learn how to navigate through the interface and complete common tasks such as classifying device clusters, creating user rules, and apply tags. You will also explore reports and strategies for furnishing stakeholders with relevant information.

ClearPass Device Insight dashboard

When you access the ClearPass Device Insight application, you see the dashboard, as shown in Figure 14-24. This highly interactive dashboard is designed to provide a modern, easy-to-use view of all devices discovered by CPDI.

Figure 14-24: ClearPass Device Insight dashboard

You can click devices to drill down into more details about them and easily move from one view to another. You can easily search through the devices or apply filters to view just the devices you want. To make the view simpler to understand at a glance, you can upload icons for your custom devices. You can export information about the devices in CSV files. You can also run reports to analyze the data and present it to stakeholders. By storing data over the long term, CPDI ensures that companies can access all relevant data about their devices and their history. However, CPDI might clean up data for devices that have been inactive for 30 or more days.

View Device List and Access Device details

In the Classified Devices or User-Classified Devices dashboards, you can click the Devices tab to see a list of the devices. From this view, you can filter and sort the devices according to various attributes. You can also perform bulk actions such as deleting attributes from all devices. CPDI gathers detailed context about each device. As shown in Figure 14-25, you can access this profile by hovering over a device and clicking the details icon that appears.

Figure 14-25: View Device List and Access Device details

View Device Profile details

In Figure 14-26, you see an example of the detailed view for a device. The top of the window displays the device’s risk score if you are using the security context features, the online or offline status, the hostname (if known), and the device type.

Figure 14-26: View Device Profile details

The Profile tab provides additional information about the device category, family, and type, as well as the device MAC address and vendor. If you integrate CPDI with CPPM, you can further see the username for the user on the device.

Check the Classification section to discover why the device was classified with this category, family, and type. In this example, ML clustering placed the device in cluster with classified devices. The number of classified and percentage of classified devices of the same type met the threshold for auto-classification, so the device was automatically classified. Other classifications include system rules, user rules, and MAC address ranges. The classification might also show that the device was clustered and a user then accepted a recommended classification. The conditions listed in the Classification section show the attributes that contributed to the device being classified in this way.

You can scroll down further in the profile to see all of the static attributes and flow attributes collected for this device.

View device network activity

Click the Network tab to view more details about the device location and network activity.

The Network Information section can help you to locate the device based on NAD IP and port, as well as the segment to which the device belongs.

Figure 14-27: View device network activity

Look through the Network Activity to answer questions about the device’s network activity and behavior. As shown in Figure 14-27, you will see a bar for each application that the device is using. If the device is accessing that application on more than one destination, the bar splits into multiple smaller bars, as you see for “udp” and “apple_location” in the example. By default the application splits into at most five destinations, which are the top five for that application. But you can use the Show settings to make the graph show the top 10 destinations or all destinations. The width of each bar corresponds to the relative number of packets for that application/destination versus others. You can hover over the bar to see more details such as the bandwidth associated with that application and destination pair.

You can also adjust the time range for the Network Activity graph. You might use this feature to investigate potential issues. For example, if you see that the application/destination list looks quite different over the past 4 hours as opposed to the past two weeks, this might be a clue that a device has been compromised.

As shown in Figure 14-27, the Network tab also includes additional tabs for authentication and accounting information. If you want CPDI to display this information, you will need to integrate it with CPPM.

Device History

As shown in Figure 14-28, the Device History tab gives you insight into the device’s activity and status over a longer period. A history gives you deeper insight into the client. Instead of just seeing that a device has an unhealthy posture, for example, you can see all of the context around the posture assignment. You can also detect patterns. If client often changes between healthy and unhealthy posture, what is happening? Does the user not understand the security policies? Is the user acting in a way that can expose the company to exploit? You might need to help educate users.

Figure 14-28: Device History

Being able to see a client’s IP changes is also useful. Some solutions track devices by IP address, which can make a single device look like multiple devices if the IP address changes. CPDI’s approach helps you to detect patterns even if a client’s IP address changes.

View generic clusters

Now that you have seen how to use some of the information that CPPM collects about devices, you will look at ways to classify devices that are currently in the generic devices list. As you recall, CPDI classifies as many devices as it can and then uses ML to group the remaining devices in clusters. As shown in Figure 14-29, you can find the clusters in the Generic Devices page. Click one of the clusters to see more details and classify the cluster.

Figure 14-29: View generic clusters

Classify a Cluster with a Recommendation

When you click a cluster, you see the Cluster Details page, as shown in Figure 14-30. If CPDI Analyzer was able to determine any recommendations for the cluster, you will see a Classification Recommendations section. In the example shown in Figure 14-30, the cluster was formed with LDA, and the recommendations derive from classified devices in the same cluster. You can see the percentage of classified devices of each type, as compared to all the classified devices in the cluster. Generally, the higher the percentage, the more likely the classification.

Figure 14-30: Classify a Cluster with a Recommendation

If none of the recommendations is correct, you can click Other and fill in your own Device Category, Device Family, and Device Type settings. For each of these settings, you can specify an existing value or create your own to describe a device type that does not yet exist in CPDI.

When you are ready, click Assign Classification. All of the generic devices in this cluster are moved to the User Classified section of the Classified Devices with the selected classification.

If you create your own Device Category, Device Family, or Device Type, the name can use upper and lower case alpha-numeric characters and these special characters: - (dash), _ (underscore), / (forward slash), & (ampersand), and () (right and left parenthesis).

Create User Rules

In addition to classifying clusters, you might want to create user rules, which will immediately apply to new devices as they are discovered.

Figure 14-31: Create User Rules

As shown in Figure 14-31, you can create a rule from scratch. Simply click the Create Rule button. You will see the Classify Devices using Rule dialog, in which you can specify conditions and rules. The conditions are attributes that the device needs to match. The rule is the category, family, and type that you want to assign to matching devices.

It can be very challenging to pinpoint exactly which attributes match a particular device type. It is often easiest to create the rule based on an existing device of that type because this method auto-populates conditions for you. The next sections explain how to follow this procedure.

Defining the User Rule

Choose the Conditions You Want

In Figure 14-32, you see an example of an Edit Conditions section, which has been auto-populated because you created the rule from a device page.In this section, you can select check boxes to choose which attributes to use as conditions in your rule.

Figure 14-32: Choose the Conditions You Want

As shown in Figure 14-32, you can include multiple types of conditions such as combinations of services, MAC vendors, and ports. For each type of condition, you specify an operator, which dictates how CPDI matches devices' attributes to the specified values. If you select Contains (All) for example, the device's attributes of that type must contain all of the values listed. Contains or Equals (Any), on the other hand, establishes an “or” logic. The device only needs to match one of the values.

Name the rule and set the device info

In Figure 14-33, you see an example of an Edit Conditions section, which has been auto-populated because you created the rule from a device page. Here you can select check boxes to choose which attributes to use as conditions in your rule.

Figure 14-33: Name the rule and set the device info

Then move to the Create Rule section. You will see if any of the rules that you selected overlap with other rules. If they do, you should typically adjust the rules to avoid overlap. In this example, rather than select just one of the ports, you could select the complete port list used by the device. Within the Create Rule section, you also set the rule name. Then choose the Device Category, Device Family, and Device Type. Again, you can use an existing category, family, and type, or specify your own. If you specify a new type, the Browse button will appear, and you can select an image for the type, which will appear in the dashboard. The image should be a .png, .jpg, or .jpeg file.

When you have finished defining the rule, you can choose between clicking Save or Save & Reclassify. Click Save if you only want the new rule to apply to new devices discovered later. Click Save & Reclassify if you want the rule to apply to existing devices, as well as new devices.

The device category, family, and type and its image will be emailed to Aruba. Aruba might replace the image with one that it has that better reflects that type. If so, the image in your tenant’s dashboard will be updated with Aruba’s image.

Using filters

Next, you will look at ways that you can use the CPDI data. From the Classified Devices, User-Classified Devices, and Generic Devices dashboards, you can apply filters to search for devices that meet specific criteria. You can search for all the devices of a category,family, or type. You can find devices that are using specific applications or accessing specific destinations. As shown in Figure 14-34, you can see all the devices at a particular location. You can also fulfill many other use cases.

Figure 14-34: Using filters

To create the filter, click the filter icon in the dashboard. In the example shown in Figure 14-34, you are filtering the classified devices, but you can apply similar filters in the User-Classified Devices and Generic Devices dashboards.

Filters have three main categories of criteria. For any of these criteria, you can choose to include or exclude the specified value.

What—Use the What category to filter devices by category, family, or type.

Where—You have a few different options for how you specify the device’s location. You can specify multiple options: – NAD IP—Specify the IP address of the NAD to which the device is connected. You can specify multiple IP addresses to find devices connected to any of those NADs.

– Subnet—Specify the subnet to which the device’s IP address belongs. You can specify multiple subnets.

– Segment—Specify the subnet segment to which the device’s IP address belongs. Again you can specify multiple subnet segments.

Others—Here you can filter by other device attributes: – Open Port—Specify one or more ports that are open on the device.

– Service—Specify one or services used by the device.

– Destination Host—Specify one or more destination IP addresses that the device has accessed.

– Posture Status—Specify Healthy, Unhealthy, or Unknown. You will learn more about these statuses later in this chapter.

– Risk Score—Specify a score, and the filter will show devices with that score or higher. You will learn more about risk scores later is this chapter.

– There are several other attributes which you can use if CPDI is integrated with CPPM. These include Authentication Method, Authentication Source, Access Type, Username, MDM Server Name, and MDM Server Type.

You can specify as many criteria as you want. Devices must match all criteria of different types for the filter to apply to them. This example filter finds all Windows 8/10 devices that are connected to the NAD at 10.10.22.251 and have port 137 open. However, if you include more than one option for the same condition type, those options are applied as “or.” For example, if you include 10.10.22.251 and 10.10.22.252 for NAD IP, the filter finds devices that are connected to 10.10.22.251 or 10.10.22.252.

Creating tags

You can save any filter that you create as a tag by clicking the Filter Actions dots and selecting Save as tag, as shown in Figure 14-35.

Figure 14-35: Creating tags

Saving the tag makes it easy to apply commonly used filters whenever required. When users select the Filter icon, they see a list of User Tags and can select the tag that they want to use to filter the device list.

In addition, CPDI dynamically adds the tag to all devices that meet the filter criteria. As soon as you save the tag, it applies the tag to any existing devices that meet the criteria. And if a device is later discovered to meet the criteria, CPDI adds the tag to it then. Users can see the tags applied to a device in the Device Details page at the Profile tab.

Example use cases for tags

You can use tags however you want to mark important information about devices.

You can use tags to identify sub-groups of devices within a device type. For example, a healthcare organization might have many medical devices of the same type. You can use tags to identify the specific medical devices at a particular location or accessing specific destination hosts.

You can also use tags to flag potentially vulnerable devices. You might want to track which devices have a particular open port. Then if a vulnerability is discovered for that port, it will be easy for admins to find all the potentially affected devices. Similarly, the company might want to track devices with legacy OS versions. In the “Use CPDI Security” section, you will learn more about CPDI security context capabilities, which produce a risk score for devices. You can use tags to track devices with a particular score or higher.

These are just some use cases. You can come up with other ones based on the company’s particular needs. No matter what the use case, within CPDI, tags help you to find and track devices that meet particular criteria. When you integrate CPDI with CPPM, the tags become even more powerful. CPPM can use the CPDI tags in role mapping and enforcement policies to affect a device’s access rights. You will learn more about this use case in the next chapter.

Creating reports

You can create reports to export and archive information that CPDI has collected. To begin creating the report, click the Create Report button, which is available from many pages within CPDI. For example, you can find this button on any of the device dashboards.

Figure 14-36: Creating reports

When you click the button, you will see the Create Report dialog, as shown in Figure 14-36. The template for the report is auto-filled in based on where you clicked the button. For example, if you clicked the button in the Classified Devices dashboard, the report is automatically set to report on classified devices. If you clicked the button from the Classified Devices list (Devices tab) view, though, the template would be for Classified Devices List. Similarly the templates will be different if you click the button in the User-Classified Devices dashboard or Devices list, or the Generic Devices dashboard or Devices list.

For Frequency, choose whether you want to run the report immediately and only once (On Demand) or periodically. If you choose a periodic option, you will be prompted to specify the time, weekday, or date on which the report should run.

Specify the recipients for the report. The valid format for the report depends on the type. Dashboard reports require the PDF format and List reports require the CSV format.

Finish the report by clicking Export (for an On Demand report) or Save (for a periodic report).

Use CPDI security

The standalone CPDI application, version 2.0.1, provides security context capabilities. You will now learn about those capabilities.

CPDI security context capabilities

As shown in Figure 14-37, using agentless scanning CPDI collects information about a device’s vulnerabilities and posture. Based on these assessments, CPDI generates a risk score for the device.

Figure 14-37: CPDI security context capabilities

CPDI agentless scanning

CPDI uses agentless scanning to assess devices’ vulnerability and posture. CPDI suports vulnerability and posture scanning for 64-bit Windows OS of the following versions:

Windows 8, 8.1, 10

Windows Server 2012, 2016, 2019

As shown in Figure 14-38, agentless scanning uses WMI, so you must attach a WMI augmentation method to the segment or segments with the devices that you want to scan. This method must have, as its credentials, a domain account that is part of the local Administrators’ group on the Windows devices.

Figure 14-38: CPDI agentless scanning

You must also make sure that the devices to be scanned meet several requirements. They must be joined to the domain. They must have SMBv2 and Administrative Shares enabled on them (check the Windows features). Their firewalls must permit TCP ports 135, 139, and 445.You can configure the Windows Firewall to permit these ports by enabling these rules:

File and Print Sharing (SMB-In)

File and Print Sharing (SMB-Out)

Windows Management Instrumentation (WMI-In)

Windows Management Instrumentation (WMI-Out)

The WMI augmentation method can alternatively reference a local user account on the Windows devices. However, this setup is less commonly used. If you do use a local user account, it must be an Administrator on the devices. It must also be permitted to run psexec scripts,which could require a registry edit.

Edit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps: – Select New, and then click DWORD Value.

– Type LocalAccountTokenFilterPolicy, and then press ENTER.

– Right-click LocalAccountTokenFilterPolicy, and then click Modify.

– Set the Value data to 1.

Enabling CPDI vulnerability and posture assessments

To configure the enable CPDI vulnerability and posture assessments, select Security in the CPDI menu.

First, toggle the Security Analysis setting to On, as shown in Figure 14-39. Enabling this setting tells CPDI to run agentless scanning and scan for vulnerabilities.

Next choose the Data Source. If you have integrated CPPM with CPDI, which is covered in the next chapter, you can select ClearPass Device Insight or ClearPass Policy Manager (CPPM). However, the focus for this chapter is using ClearPass Device Insight.

You then choose whether to enable posture assessments or not. You must enable security analysis and vulnerabilities in order to enable posture assessments.

Figure 14-39: Enabling CPDI vulnerability and posture assessments

When agentless scanning runs

When you have enabled security analysis and set up a WMI augmentation method for devices’ subnets, CPDI initiates agentless scanning on those devices automatically. The Data Collector responsible for the device runs the scan when the device is first detected—for example, when its DHCP fingerprint is received. After that, the Data Collector runs the scan every four hours on active devices. It also runs when a device first becomes active again after more than four hours of inactivity.

You do not need to schedule WMI scans for the agentless scanning. However, if you do schedule a WMI scan, the agentless scan occurs.

Vulnerability assessment

When Security Analysis is enabled, CPDI checks supported devices for the vulnerabilities defined by the National Vulnerability Database (NVD). It looks for vulnerabilities in all major products from Microsoft, Apple, Adobe, Google, and Mozilla. You can visit the NVD at the following URL: https://nvd.nist.gov/

For Microsoft products, only vulnerabilities from 2016 and later are reported. In addition, CPDI only reports vulnerabilities for which Microsoft has provided a hotfix. For non-Microsoft products, CPDI reports all vulnerabilities.

CPDI lists the discovered vulnerabilities by Common Vulnerabilities and Exposures (CVE) ID and provides a brief description of each vulnerability. It also shows the CVE score associated with each vulnerability. A CVE score is based on a variety of factors such as how easy it is for hackers to exploit the vulnerability and how much damage hackers could do if they succeed in exploiting the vulnerability. The higher the score, the worse the vulnerability. If the vulnerability has a hotfix associated with it, CPDI reports that as well.

Posture assessment

During agentless scanning, CPDI also runs posture assessments if you have enabled posture assessment and if the Data Source is ClearPass Device Insight. In this case, you configure the posture rules in the Security Settings page. In CPDI 2.0.1, you can have CPDI check for these settings:

Antivirus enabled

Host firewall enabled

Encryption enabled

USB drive disabled

Dual NICs disabled

You can also select the Check for any of these malicious hashes not present in the device check box. You must then add at least custom hash. The hash is an MD5 hash of the binary of a running process. If that hash is detected, the device fails the check.

Figure 14-40: Posture assessment

CPDI assigns a device a Healthy posture if it scans the device and detects that the device meets the selected criteria. In the example shown in Figure 14-40, a device is healthy if an antivirus and its host firewall are enabled. The other settings do not matter because they are not enabled. A device receives the Unhealthy posture if it fails to meet any of the selected criteria. In this example, a device with no antivirus application or its firewall disabled is Unhealthy.

Controlling posture for devices that cannot be scanned

By default, CPDI assigns devices that it cannot scan an Unknown posture. However, you can adjust this setting such that CPDI assigns these devices a Healthy or Unhealthy posture instead.

Figure 14-41: Controlling posture for devices that cannot be scanned

You can configure the setting separately for Windows devices that cannot be checked and non-Windows devices. For example, you might want to tell CPDI to configure non-Windows device’s posture as Healthy. Agentless scanning is not supported on these devices, so assigning a Healthy posture, as shown in Figure 14-41, is the only way for those devices to ever receive a Healthy posture. In this way, you can avoid adding points to the risk score on all of your non-Windows devices.

Understanding the risk score

When CPDI assesses vulnerabilities, it assigns each supported device a vulnerability score. This score ranges from 0 to 100. CPDI derives the score by first multiplying the CVE associated with each detected vulnerability, which range from 0 to 10, by 10. It then sums these values. Finally, it applies a logistic function, which is not quite an average of the values, but a representative value between 0 and 100. Examples of the logistic function are shown in Figure 14-42.

Figure 14-42: Understanding the risk score

If CPDI is also assessing posture, it assigns the device a posture score. The score is 0 if the device is healthy, 50 if its posture is unknown, and 100 if the posture is unhealthy.

CPDI then multiplies the vulnerability score by .7 to produce the vulnerability contribution to the risk score. It multiplies the posture score by .3 to produce the posture score contribution to the risk score. It then adds these two scores together.

You can view the Risk Score, as well as the underlying vulnerability and posture scores and information in a device’s Security tab. As you learned earlier, you can also create tags that select devices with risks score above a particular value.

Summary

Congratulations! You have completed Chapter 14. You should now be able to deploy CPDI and use this solution to grant a company deeper visibility into its device inventory. You can view generic device clusters and reclassify them, as well as create rules and tags. You also understand how CPDI assigns clients a risk score that can help you pinpoint vulnerable devices and remediate the vulnerabilities.

In the next chapter, you will learn how to integrate CPPM and CPDI to enhance the capabilities of both solutions.

Learning checks

What port must be open between a CPDI Data Collector and Central? TCP 8080

TCP 443

UDP 22

UDP 4422

What do the augmentation methods for a segment define? They provide expanded MAC address ranges to supplement classification.

They define which additional user rules to apply to classify devices.

They define which ML clustering methods are used to classify devices.

They define the methods and credentials that the Data Collector uses to scan devices.

Which correctly describes a tag? A custom rule that reclassifies device types based on a variety of attributes

A description that applies to devices based on various criteria

A device attribute that is collected by a Data Collector

A flow attribute that is collected by a Data Collector

What is a requirement for CPDI to collect vulnerability and posture information on Windows devices? The devices must have 32-bit operating systems.

The devices must use Windows 7.

CPDI agents must be installed on the devices.

A WMI augmentation method must be attached to the segment for the devices.

Note: For answers to all learning checks, refer to the Appendix.

15

Integrate CPDI with CPPM

EXAM OBJECTIVES

✓ Integrate ClearPass Policy Manager (CPPM) and ClearPass Device Insight (CPDI).

✓ Mitigate threats by using CPDI to identify traffic flows and apply tags and CPPM to take actions based on tags.

Assumed knowledge

Fundamental ClearPass Device Insight concepts

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

Integrate CPDI with CPPM

By integrating Aruba CPDI with Aruba CPPM, customers can more effectively identify and remediate security vulnerabilities on the network.

This chapter explains how to integrate these solutions, and how to use the CPDI/CPPM combination to detect and mitigate threats. You first start by learning exactly how to integrate these solutions. You will see what prerequisites must be met for integration, to avoid roadblocks during implementation. And you will cover what implications this integration has for the network, to ensure that no unintended consequences result from integration.

Why integrate CPPM and CPDI?

Why should admins take the effort to integrate CPPM and CPDI?Because, as shown in Figure 15-1, integrating these solutions allows them to feed each other information and boost overall visibility to strengthen network security.

Figure 15-1: Why integrate CPPM and CPDI?

More specifically, once integrated with CPPM, CPDI can provide more extensive device information than CPPM can obtain on its own. Not only can CPDI provide accurate device categories, families, and types for a broad range of devices, including IoT, but it can also give CPPM additional context through tags. CPDI admins can apply tags to devices based on very flexible criteria, including behavior-like criteria such as the applications that the device is using and the destinations that it is contacting. CPPM can then use this information in policies to control client access.

CPPM, in turn, can provide CPDI with information about users and authentication to expand CPDI’s endpoint profiles. It can also provide posture information to CPDI.

CPPM and CPDI integration architecture

When you integrate CPPM with CPDI, CPPM creates a collector service. The collector service receives profile requests from various services in CPPM and acquires device data. As shown in Figure 15-2, the collector service then forwards this information on to the CPDI Analyzer.

Figure 15-2: CPPM and CPDI integration architecture

The CPDI Analyzer processes device characteristics as well as communication and behavior patterns. Using rules and ML, it matches each device to a set of known fingerprints and classifies the device.

The sync service, another subsystem of CPPM, then fetches the endpoint’s classification from Analyzer and updates CPPM’s endpoint repository.

These updates happen in real time, and to back them up, CPPM also polls Analyzer periodically.

CPDI integration in a cluster

When CPPM is running on a cluster of servers, admins must designate a primary server for CPDI integration. Typically the Publisher is a good candidate to serve as the primary server.

Figure 15-3: CPDI integration in a cluster

Once a primary server is designated, the collector service will run on each member of the cluster, as shown in Figure 15-3. The non-primary appliances will then forward their data to the primary server, which will send the data to the CPDI Analyzer. The sync service will also run on only the primary server, updating the endpoint registry after fetching data from the CPDI Analyzer.

Prerequisites for integrating CPPM and CPDI

Before you enable CPPM and CPDI integration, ensure that you meet the prerequisites, shown in Figure 15-4.

Figure 15-4: Prerequisites for integrating CPPM and CPDI

The CPPM server or cluster requires Access Licenses.

Next, you must have a subscription in the Aruba Cloud Platform for CPDI. Or you can alternatively use the CPDI features integrated in Central.

Lastly, you must disable several features that you may have configured. Specifically you must remove any custom fingerprints or network scans that you have configured. You must remove any enforcement profiles that are configured with Nmap scans, SNMP scans, or OnDemand scans. And you must disable or remove any services that have audit servers enabled.

Understand the implications of integration

When you integrate CPPM and CPDI, CPPM has access to the rich profiling information collected by CPDI. Therefore, you often do not need to configure CPPM to collect profiling information. CPPM can still use device profile information, such as endpoint category, within its policies, relying on the information provided by CPDI.

Depending on the CPPM version, CPDI’s device profiler and related features, such as scanning, might be disabled when you enable Device Insight Integration. You should check the documentation for your CPPM version to understand how CPDI and CPPM interact.

Security context integration between CPPM and CPDI

Before you integrate CPPM and CPDI, you should also understand which solution’s vulnerability and posture assessment information is used, based on the settings in CPDI.

Figure 15-5: Security context integration between CPPM and CPDI

In the Security Settings page, the Data Source indicates whether CPDI takes the vulnerabilities, posture, and score from its own agentless scanning or from CPPM. As shown in Figure 15-5, if you select ClearPass Device Insight as the Data Source, CPDI will use its own scanning to derive the vulnerability, posture, and risk score shown for clients. However, it will not overwrite posture information on CPPM. If you select ClearPass Policy Manager (CPPM) as the Data Source, on the other hand, CPPM sends the vulnerabilities, posture, and risk scores to CPDI.

Obtaining registration tokens

To integrate CPPM with CPDI, you need a registration token. You use the same token that you do for Data Collectors.

Figure 15-6: Obtaining registration tokens

In case you need a refresher on generating the token for CPDI, go to the Central Account home > Global Settings > Data Collectors page, as shown in Figure 15-6. If the CPDI account does not have any Data Collectors yet, you should use the Get Started wizard. Otherwise you can go to the Data Collectors page.

In either case, click Registration Token and copy the token. Paste the output into a file so that you are ready to upload it on your Data Collectors.

Configuring Device Insight Integration on CPPM

Configuring Device Insight Integration on CPPM is simple. Navigate to Administration > Server Manager > Device Insight, and click the Enable option for Device Insight Integration, as shown in Figure 15-7.

Figure 15-7: Configuring Device Insight Integration on CPPM

Copy in the registration token that you collected.

If you are integrating a cluster with CPPM, select the primary ClearPass Server. You can also select a standby server.

CPDI updates CPPM with device information in real time. However, if no communication occurs between CPPM and CPDI over the course of the polling interval, then CPPM polls CPDI to ensure that it has the latest devices, classification details, and Device Insight Tags. The Device Sync interval, available in v6.9.1 and above, determines for which endpoints CPPM and CPDI sync information. They only sync info for devices that have been active in the previous specified number of days. (In earlier versions, CPPM and CPDI synched information for all endpoints.)

As of v6.9.2, you can configure the settings for tags. You will learn more about using tags a bit later in this chapter.

When you have filled out the settings, click Save.

Using CPDI information in CPPM services and policies

You have already learned how to set up CPPM to use device profile information to assign endpoints to ClearPass roles and eventually to enforcement profiles. The same concepts apply when CPPM is receiving the device profile information from CPDI instead of its own device profiler.

You can create rules within role mapping policies or enforcement policies that reference the device profile attributes. These attributes are stored within these namespaces: Authorization: [Endpoints Repository] and Endpoint. For example, you can create role mapping policy rules that assign a “smartphone-CPPM” role to clients with the SmartDevice category and a “medical-device-CPPM” role to clients with the Medical Devices category. You can then create enforcement policy rules that assign an appropriate enforcement profile based on the CPPM roles.

In the services that use policies with device profile–based rules, make sure to enable the Profiler. In the Profiler tab, choose to trigger a CoA for any change in category, family, or name. Then set the appropriate CoA profile for network devices that authenticate clients to this particular service. Then CPPM can use that CoA profile rather than the default one defined in the Device Insight Integration settings; this approach can be important when multiple services, associated with multiple types of network devices, might need to reauthenticate clients based on updated tags.

Use CPDI with CPPM to detect and mitigate threats

In this second section, you will learn about putting these integrated solutions to work to enhance network security. You will see how admins can use CPDI tags to enrich CPPM’s understanding of clients on the network and guide CPPM’s response to any security incidents.

CPDI tags and CPPM integration

As you learned previously, admins can create tags in CPDI. These tags select devices based on a broad range of conditions. Within CPDI, they are meant to convey useful information about devices and make it easier for users to find devices that exhibit characteristics of interest.

Figure 15-8: CPDI tags and CPPM integration

When you integrate CPPM with CPDI, the tags can provide valuable information for CPPM to consider when determining what access level to grant to clients. For example, CPDI might tag devices as having a high-risk score. As shown in Figure 15-8, CPPM can use that information to decide to apply a remediation enforcement profile to the client. This profile could limit the client’s access, and the impact of a potential attack, until the vulnerabilities can be remediated.

Or CPDI might tag devices based on their location or other context. CPPM can use this information to apply an appropriate enforcement profile with a particular Aruba-User-Role VSA.

Understanding Tag Update Action options

A device’s tags might change. If you want CPPM to be able to apply a new enforcement profile based on the latest tags, you must configure CPPM to issue a CoA in response to a tag update.

Figure 15-9: Understanding Tag Update Action options

Configure the Tags Update Action in the Device Insight Integration settings. Navigate to Administration > Server Manager > Device Insight in the CPPM UI. You have three options for Tags Update Action.

The No action option tells CPPM not to issue CoAs. As shown in Figure 15-9, this action is only suitable if all tags are purely information; CPPM is not using them as conditions in role mapping or enforcement policies.

If you choose the Apply action for all Tag updates option, CPPM will send a CoA for a client every time that CPDI updates any tag on the client. If CPDI users are configuring purely informational tags, selecting this option could cause many unnecessary disconnects, which might disrupt clients. However, some admins still prefer it because they can simply enable the setting once; they do not need to return later and add new tags to the selected list, which can minimize mistakes in the future.

However, if you are concerned about disruption, you should select Apply action for selected tag updates only option. Then, in the list below, add the specific tags that are used in role mapping policy or enforcement policy rule conditions. These are the tags that might change the client’s enforcement profile, so these are the tags that should trigger a CoA.

When CPPM triggers this action, it uses the action defined in the Profiler tab for the service that authenticated the client in question. However, if this action is not configured, CPPM uses the RADIUS CoA Action defined in the Device Insight Integration settings.

Overview of using tags to apply enforcement profiles

In Figure 15-10, you see a basic overview of the process by which CPPM can use tags to apply a specific enforcement policy to a client.

First, an admin creates a tag in CPDI and that tag applies to a device. CPDI informs CPPM of the new device tag for that client. CPPM places that tag in the client’s endpoint profile.

Figure 15-10: Overview of using tags to apply enforcement profiles

Assuming the integration settings use the proper option for Tags Update Action, CPPM sends a CoA to the network device (an AP or switch) to which the client is connected.

After the network device enforces the CoA, the client will re-authenticate to an 802.1X service, or other L2 authentication service, on CPPM. A rule in that service’s enforcement policy uses the tag as a condition. The rule will apply an enforcement profile with an appropriate Aruba-User-Role. For example, if the tag indicates that the device is vulnerable, the rule associated with that tag might place the user in an Aruba-User-Role for remediation.

Example tag-based rule in an enforcement policy

You can use Device Insight Tags in role mapping policies and enforcement policies, just like you use other attributes in an endpoint profile. If you want to use a tag to adjust clients’ access, you will need to add a tag-based rule to the policies for any service that a client could potentially use to authenticate, such as the wired and wireless 802.1X service on CPPM.

Figure 15-11: Example tag-based rule in an enforcement policy

Keep in mind that whether you add the rule to a role mapping policy or an enforcement policy depends on what approach you’re using in general and your particular use case.

In the example shown in Figure 15-11, you are using an enforcement policy. You add a rule with the Endpoint Type and the Device Insight Tags Name in the condition. You set the condition value equal to “suspicious_dst.” Then you select the profiles that you want to apply.

Example use case using network activity

Now look at a complete example use case.

Figure 15-12: Example use case using network activity (1-3)

In the example shown in Figure 15-12, CPDI admins analyze the network activity, applications, and destination hosts on endpoints. They might discover signs of a compromised device such as an IoT device contacting a known command and control host. The admins can quickly respond by creating a tag from the profile (named “suspicious-dst” in this example). As you recall, the tag comes up with all the attributes of that device and the admins can select just the attributes that indicate the device is compromised.

The CPDI admins inform the CPPM admins about the new tag. The CPPM admins add a rule to each 802.1X service enforcement policy. That rule selects endpoints with that Device Insight Tag and applies a quarantine or remediation profile. If CPPM is using the Disconnect for Selected Tags option, the admins add the new tag to the list of selected tags. (CPPM admins can also issue a CoA on the initial device or devices on which admins detected the suspicious behavior. Or admins might have already dealt with those devices.)

Figure 15-13: Example use case using network activity (4-O)

Later other devices display the same suspicious behavior. Without admin intervention, CPDI automatically applies the “suspicious-dst” tag. It also updates CPPM to inform CPPM that the devices have this tag, as shown in Figure 15-13. CPPM then automatically issues CoAs for the compromised devices with that tag. The devices reauthenticate and CPPM quarantines them. CPDI and CPPM have worked together to protect the network.

Summary

You began this chapter by learning about integrating CPDI with CPPM. You saw how this integration works, what prerequisites it has, and what effects it has on the network.

Then you learned about how to use these integrated solutions to enforce stronger security. You took a look at CPDI tags, use cases for them, and how to use them.

Learning checks

CPPM is integrated with CPDI. What determines whether CPPM sends a CoA when a device’s tag is updated by CPDI? The settings in the Profiler tab for the service that authenticated the device

The settings in the ClearPass Device Insight Integration page

The cluster-wide General settings

The network device settings for the NAD to which the device is connected

Note: For answers to all learning checks, refer to the Appendix.

16

Use Packet Captures to Investigate Security Issues

EXAM OBJECTIVES

✓ Perform packet capture on Aruba infrastructure locally and using Central.

✓ Interpret packet captures.

Assumed knowledge

Basics of deploying Aruba network infrastructure products

Basics of Aruba solution architectures

Basic 802.11 and Ethernet principles

Review packet captures on Aruba Unified Infrastructure

When you need to dig deep into an issue, packet captures provide a powerful tool.

In this chapter, you will review how to capture packets on Aruba network infrastructure devices. You will learn about a variety of strategies that you can take to obtain the packets, depending on what traffic you want to capture and your network architecture.

After a brief introduction to basic guidelines for using the tool, the chapter will guide you through a few scenarios for detecting security issues using Wireshark packet captures. Specifically, you will look at detecting port scans and investigating an ARP poisoning attack.

Review packet capture

Packet captures can be useful tools for investigating security issues. As shown in Figure 16-1, when a device “captures”packets, it records traffic that is flowing through it.

Figure 16-1: Review packet capture

A packet capturing device might also save either the packets themselves, or it could save an analysis of the packets to a file for later examination. The device might also send the packets to another device, such as an Intrusion Detection System (IDS), for examination.

Considerations for implementing the packet capture

To use packet captures effectively, you need to carefully consider the goals of your investigation. What traffic are you interested in? Are you attempting to gather traffic across the network as the preliminary step in pinpointing a problem? Or do you already know that a client is behaving suspiciously, and you want to investigate that client further?

Figure 16-2: Considerations for implementing the packet capture

When you know your target, consider the traffic flow, an example of which is shown in Figure 16-2. Generally you want to capture traffic as close to the source of the issue as possible. However, when you do not know what the source is, you might need to capture a large amount of traffic as a first step in looking for the source. In that case, you could set up a capture at a bottleneck where most traffic flows,such as the link between a core routing switch and the data center.

For wireless traffic you also need to consider decryption. Based on the wireless architecture, an AP, gateway, or MC might be decrypting the wireless traffic. In AOS 10, APs encrypt and decrypt wireless traffic for both bridged and tunneled SSIDs. The AP might then encrypt the traffic with IPsec again; however, you can capture the traffic on the AP before that encryption occurs.

However, in AOS 8 architectures, MCs typically encrypt and decrypt the traffic. Understand the architecture that the company is using so that you can capture the traffic after decryption.

Capturing packets to and from a wireless client on a Central-managed AP

Sometimes you will want to capture all packets from a particular client as shown in Figure 16-3. The simplest way to capture that traffic depends on your Aruba solution architecture.

Figure 16-3: Capturing packets to and from a wireless client on a Central-managed AP

When a wireless client connects to an AP that is managed by Central, you can easily initiate a packet capture from within Central. You can use this feature regardless of whether the AP is bridging or tunneling the client traffic. Similarly, you can initiate packet captures from Central on wired clients that are connected to an AOS-CX switch or have their traffic tunneled to a gateway.

When you start the packet capture on a client’s traffic, Central tells the device to which the client is connected to execute the packet capture. For up to 15 minutes, the device copies all packets flowing to and from that client and sends the packets to Central. Central saves the packets in a Packet Capture (PCAP) file, which you can download to your local station at the end of the packet capturing session.

Note, however, that all network devices and device software versions do not necessarily support this feature, so you should check the capabilities and requirements for your particular network devices.

Steps for implementing a packet capture with Central

To implement a packet capture with Central, go to the Clients page from any view (Global, Groups, Sites, or Labels). Click the name of the client for which you want to capture traffic. You will be taken to the Clients Details page.

Select Live Events under Analyze.

Figure 16-4: Steps for implementing a packet capture with Central

Enable the Packet Capture toggle button and click Start Troubleshooting, as shown in Figure 16-4. The live troubleshooting session runs for up to 15 minutes. You can stop the troubleshooting session at any time before that if you choose. After the live troubleshooting session ends, a Download PCAP text appears above the live events table. Click Download PCAP to download the .pcap file on your local system.

You can also initiate packet captures for client traffic from the Site view under Live Events. Note that, regardless of where you initiate the packet capture, the packet capture feature is only available if the network device to which the client connects is assigned to a site.

Capturing packets to and from clients on a gateway or MC

If the company is using a controller-based architecture, the AP is tunneling the wireless client’s traffic to a Mobility Controller (MC), which decrypts the traffic. You can initiate a datapath capture of the client’s traffic from the CLI. Similarly, you can initiate a datapath capture of any client connected in the MC user-table, including UBT clients and clients in a client-to-site VPN. As seen in Figure 16-5, the same holds true for Aruba gateways.

Figure 16-5: Capturing packets to and from clients on a gateway or MC

When you initiate a datapath capture on an MC or gateway, the device copies all of the traffic to and from the client and sends the packet copies to the configured packet capture destination. You can configure this destination as a local file on the MC, an interface on the MC to which you would attach a device running a packet analyzer like Wireshark, or the IP address of a device running a packet analyzer.

Implementing an Aruba MC or gateway datapath packet capture to a remote IP

As shown in Figure 16-6, you can use the IP address destination option to analyze the captured packets directly on your management station. Start a packet analyzer like Wireshark on your station (you will learn more details about doing this in the next section). Then configure that station as the destination for the packet capture on the MC or gateway. Use this command: packet-capture destination ip-address .

Figure 16-6: Implementing an Aruba MC or gateway datapath packet capture to a remote IP

Find the MAC address of the client whose traffic you want to capture. Then start the packet-capture with this command: packet-capture datapath mac . You can choose whether to capture all traffic to and from the client,just the decrypted traffic, or just the encrypted traffic.

The MC or gateway then encapsulates the client traffic with GRE and sends the traffic to the destination IP address.

When you have finished investigating the issue, make sure to turn the packet capture off with the no form of the same command: no packet-capture datapath mac .

Implementing an Aruba MC or gateway datapath packet capture to a file

Sometimes you will want to collect the packets in a file, which you can then copy off of the MC or gateway and analyze elsewhere. For this option, set the packet capture destination to the local-filesystem as shown in Figure 16-7. Then initiate the datapath packet capture in the same way explained previously.

Figure 16-7: Implementing an Aruba MC o’gateway datapath packet capture to a file

When you are done with the capture, disable it. The packets are saved in this file: /var/log/oslog/

datapath.pcap. Copy the file to an FTP server, SCP server, or TFTP server. Or you can copy the file to a USB drive.

Capturing packets to and from a wired client on an AOS-CX switch

If you want to capture packets flowing through an AOS-CX switch, use mirroring. A mirroring session copies packets received from or transmitted to one or more source interfaces. It then sends those packets to a destination, as shown in Figure 16-8. Options for the destination include an interface or a tunnel to a remote IP address. You can use these options to send the packets to a device that is running a packet analyzer.

Figure 16-8: Capturing packets to and from a wired client on an AOS-CX switch

If you want the switch to capture and analyze the packets itself, you can set the destination to “cpu.” You can then view the packets on the switch directly by entering these commands: diagnostic and then diag utilities tshark. However, it is usually easier to interpret the packets in an application like Wireshark. You can place the last 32 bytes of the CPU capture in a file with these commands: diagnostic and then diag utilities tshark file. Then copy the tshark file to an SFTP server.

However, the CPU capture can be processor intensive. Often the best approach is to set up a client running Wireshark and remotely mirror the traffic to it.

AOS-CX switches support multiple mirroring sessions. However, only one session using the CPU as the destination.

Running a packet analysis directly on the switch

If you want to capture packets and analyze them directly on the switch, you can do so by initiating a tcpdump in the shell. You might also choose this option when you want to capture just a specific type of traffic, such as RADIUS traffic in the example shown in Figure 16-9. It is possible to use classes to filter a mirror session, but the configuration takes a few extra steps.

Figure 16-9: Running a packet analysis directly on the switch

The shell is locked down to prevent users from causing damage to the switch functions. However, whenever you access the shell, you should be cautious and avoid entering commands that you do not understand. To start the shell, enter: start-shell.

Use this command to start the packet capture: sudo ip netns exec swns tcpdump.

When you specify -vv option, the CLI outputs more complete information about each packet. If you omit this option, you simply see one line about each packet that arrives—which can still be useful if you are simply trying to see if particular types of packets are flowing.

Use the -i option to indicate on which interfaces you want to capture the traffic. In this example, you are capturing traffic on all interfaces.

You can use the port options to select the UDP or TCP port for the particular type of traffic that you want to capture.

Mirroring traffic from a switch port to a packet analyzer

In Figure 16-10 you see an example of how to mirror traffic to a client running Wireshark.

Figure 16-10: Mirroring traffic from a switch port to a packet analyzer

Begin by creating the mirror session. Each session has a unique number: mirror session .

Next set the source interface or interfaces for the session: source interface . In this example, you want to capture traffic from the client connected to interface 1/1/4, so you set that interface as the source. You can choose to mirror traffic received on the interface (from the client in this example), traffic sent on the interface (to the client in this example), or both. Generally, it is most useful to see both sides of the conversation.

Next set the destination. In this scenario, your client running Wireshark is not connected directly to the mirroring switch, so you need to set up remote mirroring. Use this command: destination tunnel source [vrf dscp ]. As you see in Figure 16-10, you set the first IP address in the command to the remote IP address to which you want to send the traffic. The source IP address is an IP address on the switch. Specify the VRF in which the switch reaches the destination if not default.

When you are ready to start mirroring packets to the destination, enter enable. When you are done, you can disable the mirror: no enable.

Use Wireshark

In this section, you will learn how to use Wireshark so that you can analyze the packets that you have discovered.

Wireshark

You have reviewed how to capture packets and send them to a device running a packet analyzer. Now you will learn about using Wireshark, one of the most common packet analyzers, to interpret the packet capture. Wireshark can capture packets that arrive on an interface on the device running Wireshark. It decodes the packets and outputs information about them. You can also use Wireshark to open a saved PCAP file and view the packets decoded within that file.

Figure 16-11: Wireshark

You could spend many hours practicing using Wireshark, so this study guide clearly cannot teach you all the aspects of this tool. However, it will give you some basic steps and pointers to get you started. This section features screenshots and instructions for Wireshark v2.6.5 like the one shown in Figure 16-11. Steps might differ a bit on other versions; however, you can apply many of the same principles.

Start a Wireshark capture

When you open Wireshark, you will see a section called “Capture,” which lists all of the interfaces on the device and is shown in Figure 16-12. You can double-click the interface to immediately start capturing all of the packets on that interface. You will want to use this option when you are mirroring packets from an Aruba network device to the device running Wireshark.

Figure 16-12: Start a Wireshark capture

Wireshark then begins to capture all packets that arrive on the selected interface.

Open a PCAP file

Sometimes you will have captured packets on an Aruba device and saved the capture out as a PCAP file.

Figure 16-13: Open a PCAP file

In this case, shown in Figure 16-13, open Wireshark and select File > Open. Then choose your file and click Open.

Wireshark output

After you start the packet capture or open the file, the top section of the application shows a list of packets ordered by time. As you can see in Figure 16-14, Wireshark provides a brief summary of important information about the packet, including its source IP address, destination IP address, protocol, length, and brief information (Info) about the packet contents. For example,Wireshark decodes ARP requests as “Who has < target IP address>? Tell .”

Figure 16-14: Wireshark output

If you are running a live capture on an interface, as more packets arrive, Wireshark adds them to the bottom of the list. You can select a packet in the list and use the arrow keys to move up and down the packets.

When you select a packet, the middle section of the application shows more detailed decoding of that packet. This section is organized in headers and the payload. You can expand any of the headers to see the fields within that header. In this example, the ARP header is expanded, and you can see the sender MAC address, sender IP address, target MAC address, and target IP address.

The bottom of the interface shows the packet bits in hex. It highlights the bits that correspond to the particular field that you have selected in the middle section.

Capture filter

Often you will want to narrow the packet output so that you can focus on conversations of interest. Wireshark supports both capture filters and display filters. An example of a Capture filter is shown in Figure 16-15.

Figure 16-15: Capture filter

You apply a capture filter when you start the capture. Wireshark then only captures and displays packets with the specified characteristics. You can only remove the capture filter by stopping the capture and restarting with a new filter. You cannot remove the filter and see a broader range of earlier packets because Wireshark never captured the packets in the first place. You might use a capture filter when you are mirroring traffic to the Wireshark device, and you want to capture only the mirrored traffic, filtering out any random traffic that the device might be sending or receiving on its own behalf. If you are mirroring traffic from an AOS-CX switch, filter for the GRE protocol with this string: ip proto 47. To filter for Aruba_ERM traffic, use this string: udp port 5555. Capture filters use libpcap filter language. For more information, refer to Wireshark documentation.

Display filter

A display filter is temporary, and an example is shown in Figure 16-16. A display filter looks for packets that match the filter specifications and removes all other packets from the display.

Figure 16-16: Display filter

Wireshark still retains memory of the removed packets, and it continues to capture all packets permitted by the capture filter. You can remove the display filter and see all the captured packets again. You can then apply a new display filter as you desire.

Display filter notation

Display filters use this basic notation: parameter operator value. The Operators table, shown in Figure 16-17, shows some of the operators that you can use in display filters. To find parameters, you can start typing in the display filter field and see suggestions of valid parameters.

Figure 16-17: Display filter notation

You can apply display filters to help you focus in on a particular issue. For example, you might be investigating an attack on a particular server. You can filter for that server’s IP address to see traffic to and from it. Or you might be looking for signs of a ping sweep. You can filter for ICMP echoes (type 8) as well as echo replies (type 0). As you see in Figure 16-17, you can combine multiple statements together with an “or” if you want to select packets that meet either criteria. Or you can use “&&” or “and” to select packets that meet both criteria. Use “!” to negate a statement.

Central captures include both management and data frames. The management frames can be useful for troubleshooting, but sometimes you want to focus on the data sent to and received from a client. You can filter for 802.11 data frames with this filter:

You apply the display filter by typing it into the display filter field at the top of the packet list and pressing [Enter]. As you start to type in the display filter field, you will receive prompts. If you want to learn more about filter syntax, refer to Wireshark documentation.

Decoding of packets sent by Aruba devices with GRE

In addition to decoding the typical protocols used in network communications, Wireshark can decode the packets sent to it from an AOS-CX mirror session, AOS gateway datapath packet capture, or AOS MC datapath packet capture. In this example shown in Figure 16-18, an AOS-CX switch at 10.1.140.6 has a remote mirroring session with the device running Wireshark, which is at 10.1.140.90. Wireshark automatically decapsulates the GRE packets and shows the inner packet in the list of packets. In this example, packet 14 is selected. You can see in the middle section that this packet has an outer IP header with a source and destination of the switch and Wireshark device. It also has a GRE header. Inside the GRE header you can see the original Ethernet header, including the VLAN tag. You can then see the inner IP header and protocol header. As you see in Figure 16-18, the display of packets shows the inner source IP address, inner destination IP address, and inner protocol.

Figure 16-18: Decoding of packets sent by Aruba devices with GRE

This automatic decapsulation makes it easy for you to focus on the traffic that was mirrored, rather than see a lot of GRE packets.

You can verify that Wireshark is decoding the packets by going to Analyze > Enabled Protocols. Then search for GRE and verify that the check box is selected.

Decoding Aruba_ERM packets

Aruba CAPs capture packets with Aruba_ERM. Wireshark does not know how to decode this protocol by default, so you will need to configure it to do so.

Figure 16-19: Decoding Aruba_ERM packets

As you see in Figure 16-19, Wireshark initially presents the packets from the Aruba CAP as UDP packets destined to port 5555. Right-click one of the packets and select Decode As. The window appears with a filter already configured to match the packet that you selected. Select Aruba_ERM in the Current column.

You must also click the plus (+) icon and add another definition to tell Wireshark that the Aruba_ERM traffic is a packet capture. Select Aruba ERM Type and select Aruba ERM PCAP (Type 0) in the Current column.

Click Save.

When you perform this task in your Wireshark application once, the configuration is saved for other times that you use the application.

Decoding 802.11 frames captured in Aruba Central

When you capture packets in Central, the AP captures the complete 802.11 frame. At default settings Wireshark cannot properly decode the traffic, so it appears as indistinguishable 802.11 frames.

Figure 16-20: Decoding 802.11 frames captured in Aruba Central

To view intelligible packets, you must select Edit in the Wireshark menu and then preferences. Scroll to IEEE 802.11. In Figure 16-20 you can see several options for how Wireshark decodes 802.11 frames. You must tell Wireshark to ignore the Protection bit with the IV. Also tell it to validate the FCS checksum if possible. You might need to experiment with toggling the assume packets have FCS settings. Click OK to apply the settings. After you tell Wireshark how to decode the IEEE frames correctly, you will then be able to see all of the 802.11 frames properly decoded to show the inner IP headers and deeper protocol layers.

The packet capture includes all of the 802.11 frames, including both management and data frames.

Tracing a conversation

Sometimes you will want to trace a particular conversation. You could apply a display filter for the source and destination IP address in question. However, those IP addresses might be participating in multiple conversations with each other. The easiest option can be to trace the conversation.

Figure 16-21: Tracing a conversation

Select a packet in the conversation of interest. Right-click and select Follow and then the type of stream that is appropriate for that conversation. As you see in Figure 16-21, Wireshark can follow TCP, UDP, SSL, or HTTP streams.

Wireshark then automatically applies a filter for that stream. You will see all the packets associated with it. You can move through the conversation and drill down into details for any of the packets.

Detect port scans with Wireshark

In this section, you will learn about how to detect port scans using Wireshark.

Detect ping sweeps

You will now look at how you can use Wireshark to detect various types of sweeps and scans. While innocent reasons for such scans exist—for example, CPDI Data Collectors use them—hackers also use these scans to reconnoiter a network and plan their next steps in the attack.

First you will look at ping sweeps, which are a simple first step in finding active devices. ICMP ping sweeps use ICMP type 8 messages (echo messages), so you should filter for those with this syntax in the display filter: icmp.type==8. To see the echo replies, add or icmp.type==0. Press [Enter] to apply the filter.

Figure 16-22: Detect ping sweeps

Any active network will feature pings, so seeing output after you apply this filter does not necessarily mean that you have detected a ping sweep. Instead look for additional signs of a sweep. First you will need a general sense of your network based on analyzing the network over time. How many pings are normal for this particular environment, and are you seeing more than usual within a specific time period? Next look for many pings from the same source. In the example shown in Figure 16-22, IP address 10.1.141.151 is sending the bulk of the requests within a short period. You can also see how 10.1.141.151 is sending pings to many different incrementing destinations, moving from 10.1.140.1 to 10.1.140.2 to 10.1.140.3 and so on. This methodical approach is a sign of a ping sweep.

Other types of sweeps

Because some networks and devices filter ICMP, hackers might continue to sweep the network in other ways. The hackers can then build a more complete picture of the network.

Figure 16-23: Other types of sweeps

In a TCP “ping,” the scanner sends a TCP Syn or TCP Ack message to one arbitrary port on all the IP addresses in a range. Any response indicates that an active device has that IP address. Ports 80 or 443 are often used for the sweep. You should understand that you will often see legitimate packets with these flags, like in Figure 16-23. What indicates a scan is the fact that a single source rapidly attempts to connect to many destinations.

Hackers can similarly use UDP sweeps to try to get past firewalls that filter ICMP and TCP. The hacker sends UDP messages to a port that is likely to be closed. If a device exists at that IP address and the port is closed on it, the device responds with an ICMP unreachable. Again you can detect the sweep based on seeing a chunk of UDP packets from the same source to many different IP addresses on the same port. Nmap uses UDP port 40125 by default for UDP sweeps. This port is rarely used otherwise, so seeing packets to this port is a good sign that someone is performing reconnaissance on the network.

TCP Syn scan

Hackers often run sweeps as preludes to a more intense port scan, in which they attempt to discover open ports on devices detected as active during the sweep.

Figure 16-24: TCP Syn scan

To discover the TCP ports that are open on a scanned device, hackers often run TCP Syn scans as shown in Figure 16-24. Sometimes called half-open TCP scans because the scanner does not fully open the TCP session, TCP Syn scans are relatively fast and unobtrusive. The application, such as like Nmap, sends a TCP Syn to each port that it wants to scan. If the port is open on the scanned device, the device returns a TCP packet with the Syn and Ack flags set. The application then knows that the port is open. Because it does not really want to open a session, it sends a TCP Rst to the scanned device.

If the port is closed, the scanned device responds with a TCP Rst or possibly a TCP Rst, Ack message. A firewall might lie between the scanner and the scanned device. If the firewall denies access to a port, the scanner will either receive no response or an ICMP Unreachable (type 3) message. The scanner marks those ports as filtered.

Detect TCP Syn scans

To detect a TCP Syn scan, you can look for an unusually large number of packets with TCP RST flags set. In Figure 16-25 you see a display filter for such packets: tcp.flags.reset == 1. (The 1 indicates that the flag must be set.) You might also add or icmp.type==3 to see the ICMP Unreachable messages sent if a firewall is filtering some ports. These filters detect all the final messages in the TCP Syn scan.

Figure 16-25: Detect TCP Syn scans

While clients and servers do sometimes reset sessions, the display shown in Figure 16-25 has several signs of a TCP scan. The vast majority of the RSTs within a short time frame are destined to a single IP address, 10.1.141.151. And the RSTs that are destined to another IP address are actually from 10.1.141.151. You can identify 10.1.141.151 as likely to be running a port scan.

Another way to search for TCP Syn scans

Alternatively, you might filter for the first packet in the scans. These packets have the Syn flag set, but not the Ack flag. Use this filter: tcp.flags.syn == 1 and tcp.flags.ack == 0. Perfectly legitimate traffic features flags of this type. This packet simply indicates the start of a TCP session. However, in Figure 16-26 you see the signs of a scan.

Figure 16-26: Another way to search for TCP Syn scans

The same IP address is rapidly trying to connect to many different ports. Legitimate clients rarely need to open so many connections in rapid succession. The source of these connection attempts is likely running a port scan.

Further investigating the TCP Syn scan

After you determine that a particular IP address is likely running port scan, you can investigate further by filtering for that IP address—10.1.141.151 in this example. Use ip.addr to see packets both to and from this IP address. In the example shown in Figure 16-27, you continue to see signs of a scan. The suspected scanner is sending TCP Syn messages on many different ports to different IP addresses.

Figure 16-27: Further investigating the TCP Syn scan

To check up further, you can follow one of the streams for which the scanned device responded with a SYN, ACK, indicating that the port is open.

TCP Syn scan versus legitimate TCP session

In Figure 16-28 you see the result of following one such stream. As you see, 10.1.141.151 immediately reset the session as soon as it received the Syn, Ack. That behavior indicates a scan.

Figure 16-28: TCP Syn scan versus legitimate TCP session

A normal TCP session would look more like the one shown in Figure 16-28, in which the client and server exchange many packets with application data.

Other types of TCP scans

Hackers might sometimes run other types of TCP scans. The TCP Fin, TCP Null, and TCP Xmas scans are sometimes called stealth scans because the scanner does not need to form a session to conduct the scan. The scanner simply sends a packet with illegitimate flags for the first packet in a TCP session. A TCP Fin scan uses a packet with the Fin flag set. A TCP Null scan uses a packet with no flags. And a TCP Xmas scan sets the Fin, Psh, and Urg flags. All of these scans are looking for similar behavior. If the scanned device sends no response, the port is open. If the device sends a TCP Rst, the port is closed.

Note that these types of scans do not work against Windows OS because Windows devices send a TCP Rst in response to the illegitimate packet whether or not the port is closed. For this reason, hackers might not use these scans as often as the TCP Syn scans. However, you should still be aware of them.

Figure 16-29: Other types of TCP scans

You can use the filters shown in Figure 16-29 to look for these scans in Wireshark. For the TCP Xmas scan, rather than filtering for each flag separately, it can be faster to filter for the Hex value associated with those flags: 0x029. Seeing packets with the Fin flag set does not necessarily indicate a scan, as devices legitimately send such packets at the end of a session. You should look for other signs of a scan such as many such messages from the same source to different ports and destinations.

The combination of flags for TCP Null and TCP Xmas scans should not occur in legitimate traffic. If you filter for those packets and see results, you know that a hacker is running a scan.

UDP port scans

Hackers might also conduct UDP port scans to gather information about which UDP ports are open, and potentially exploitable, on scanned devices. The scanner sends a series of UDP messages on different ports. If it receives no response to the message, it considers the port open. (Rarely the scanned device might send a UDP response, in which case the port scanner would also consider the port open.) If the scanner receives an ICMP Unreachable (type 3) response, it considers the port closed if the code is 3. If the code is 1, 2, 9, 10, or 13, it considers the port open.

Figure 16-30: UDP port scans

As you see in Figure 16-30, a UDP port scan will be characterized by many UDP messages on different ports from one source. It will also produce a lot of ICMP Unreachable packets.

Detect a UDP scan

Filtering for icmp.type==3 can help tip you off to UDP scans, just as it can for TCP scans. Again you are looking for an unusual number of ICMP Unreachable messages within a short time frame and destined to the same IP address. You can select one of these packets and remove the display filter to see the packets that occurred around the same time. When the display shows many UDP requests from that IP address, you can be reasonably confident that the device at that address is conducting a UDP scan. As you see in Figure 16-31, 10.1.140.151 is sending UDP requests to a few IP addresses within a range. The requests are for several different commonly scanned ports.

Figure 16-31: Detect a UDP scan

As with other scan, you can continue to investigate by filtering by the likely scanner’s IP address. You can then see if perhaps the scanner is running other types of scans or even other attacks.

Investigating ARP poisoning with packet captures

In this section, you will learn about ARP Poisoning and how to investigate this issue using packet captures.

Filter for ARP poisoning

Wireshark can give you a clue that an ARP poisoning has occurred. If a packet capture includes ARP messages that claim the same IP address at different MAC addresses, Wireshark marks the messages with the second MAC address. The Info fields state “duplicate use of detected!” You can see an example of this message in Figure 16-32.

Figure 16-32: Filter for ARP poisoning

You can filter for these packets with this display filter: arp.duplicate-address-detected. Also remember that ARP broadcasts do not cross Layer 2 boundaries. If you are looking for ARP poisoning, you will need to capture traffic before it is routed.

If you see any ARP responses with a duplicate address detected, note the source MAC address. The device with this address is a potential hacker, attempting a poisoning attack. As you recall, an ARP poisoning attack is often a prelude to a man-in-the-middle (MITM) attack.

Also remember that you can prevent such attacks before they occur by setting up ARP inspection on your AOS-CX switches.

Find the original MAC address

You can further investigate by looking for the other ARP messages that claim the IP address in question. Use a filter such as this: arp.dst.proto_ipv4 = = . Note the MAC address associated with those messages, as shown in Figure 16-33.

Figure 16-33: Find the original MAC address

Wireshark does not know the legitimate device that owns the IP address. Depending on the timing of the attack and the packet capture, the attacker might have either address. Sometimes you will be able to tell relatively quickly which MAC address is legitimate. If one MAC address belongs to a network infrastructure device, and the other to a client, the client is the likely attacker. Other times you should investigate both MAC addresses.

Collecting information about suspicious clients

You can collect more information about the client MAC address or addresses in question using a variety of Aruba tools, which are listed in Figure 16-34.

Figure 16-34: Collecting information about suspicious clients

In ClearPass, you can find this information in several places. You can search for the potential hackers’ MAC addresses in Insight Inventory. You can also find endpoint information in the Endpoints Repository. Or you can use Access Tracker to find the user authenticated on those clients. Filter based on Host MAC-Address. Open up the record to find information such as the NAS to which the client is connected.

You can also search for the client in Central. From there you can find the client’s username, connected NAS, and initiate a packet capture. If you are using CPDI, that application will have information about the endpoints’ profile, network activity, and history.

You can also look in the network infrastructure itself. You can search gateway or MC client lists or even switch MAC forwarding tables.

Example of finding information in ClearPass Insight

In Figure 16-35 you see an example of how you can find more information about the potential attacker’s client in ClearPass Insight. In the left menu, select Endpoints. Find the MAC address or addresses that you recorded earlier. As shown in Figure 16-35, click the address to view information such as the name of the device’s user and the NAS to which the device is connected.

Figure 16-35: Example of finding information in ClearPass Insight

You can then contact the user and start to figure out whether the user is malicious or the device is compromised.

Scenario: Use Wireshark to troubleshoot

In this topic, you will apply what you have learned about packet captures to using Wireshark for troubleshooting.

The problem

In this scenario, you are investigating a serious problem. All devices have been blocked from connecting to AOS-CX switches at a site. The switches are supposed to authenticate users to CPPM and receive DURs for controlling the users’ access.

Figure 16-36: The problem

But, as shown in Figure 16-36, something is going wrong, and no one can connect to the network.

Initial investigation

You start investigating the issue by viewing the clients’ authentication port-access status. You see in Figure 16-37 that the clients have actually authenticated successfully. However, their roles are not applying.

Figure 16-37: Initial investigation

When you look at the roles, you see that the switch failed to download roles because it does not trust CPPM’s HTTPS server certificate.

CPPM checks do not show the problem

You next check the certificate on CPPM to ensure that the switch has the proper root CA certificate installed in a TA profile.

Figure 16-38: CPPM checks do not show the problem

On CPPM, you view the HTTPS server certificate on both servers in the cluster. You see in Figure 16-38 that the root authority is rootpublicCA. You also check the subject name in the certificates, as this must match the RADIUS server specified on the switch.

TA profile and RADIUS server checks do not show the problem

You check the TA profile on the switch and see that the correct root CA certificate is installed and valid, as shown in Figure 16-39.

Figure 16-39: TA profile and RADIUS server checks do not show the problem

The RADIUS server settings, not shown in Figure 16-39, are also correct.

Capture packets to find the issue

Because the issue is resisting your normal troubleshooting procedures, you decide to run a packet capture to investigate further.

Figure 16-40: Capture packets to find the issue

As shown in Figure 16-40, you set up a mirror on the switch uplink for sent and received traffic. You set the mirror destination to your laptop, which is running Wireshark. You then have a user try to connect to the network again.

Analyze the packet capture to find the issue

You know that an error is occurring in the certificate trust, so you are focusing on that exchange. In the packet capture, you filter for the switch IP address, 10.1.140.6, and CPPM’s IP address, 10.1.149.10. You then look for the TLS exchange that occurs when the switch attempts to download the roles. You look for the packet with a certificate after the Server Hello. This packet has the server certificate.

You expand headers in the middle section until you have expanded the Certificate and can view information about it. In Figure 16-41, you see that the switch is not receiving the same certificate that you saw listed for CPPM’s HTTPS certificate. This certificate is signed by a different CA: intCA.companyx.example.com.

Figure 16-41: Analyze the packet capture to find the issue

You now know that the switch and CPPM setup are correct. Something is intervening between the switch and the AP. On further investigation into what has changed, you find out that the company has implemented a new firewall. This firewall uses SSL Forward Proxy which involves replacing certificates in communications with new certificates signed by the firewall on the fly. This explains how the CA certificate changed en route. You will need to set up the AOS-CX switch to trust the firewall’s root CA certificate to resolve the issue. (Or the company will need to change how it is implementing this security feature to keep the switch and CPPM communications intact.)

Summary

Congratulations! You have completed Chapter 16.

You can now follow your security team’s instructions to capture relevant packets for a security investigation. You have also gotten started with analyzing these packet captures yourself using Wireshark. You can navigate the Wireshark interface and apply simple display filters to zero in on relevant data for your investigation. You can now recognize port scans and other potential security issues.

Learning checks

What is one difference between Wireshark capture filters and display filters? Only capture filters can be removed and changed during an active capture.

Only capture filters can filter packets based on protocol.

Only display filters can be removed and changed during an active capture.

Only display filters can filter packets based on protocol.

What is a sign of a TCP Syn scan? (Multiple answers can be correct.) A device that immediately sends TCP RST packets in response to Syn + Ack messages

Any TCP packet that has the Syn flag set without the Ack flag

Any TCP packet that has the Syn flag set with the Ack flag

Many TCP Syn packets from the same source to different destinations and ports

Note: For answers to all learning checks, refer to the Appendix.

17

Establish Secure Remote Access

EXAM OBJECTIVES

✓ Explain VPN Concepts.

✓ Understand that Aruba SD-WAN solutions automate VPN deployment for the WAN.

✓ Describe the Aruba 9x00 Series Gateways.

✓ Design and deploy remote VPNs using Aruba VIA.

Assumed knowledge

Basics of deploying Aruba network infrastructure products

Basics of Aruba solution architectures

Encryption fundamentals

PKI fundamentals

Fundamental ClearPass Policy Manager (CPPM) components, such as services, roles, enforcement profiles, and enforcement policies

Introduction to VPNs

Virtual Private Networks (VPNs) help companies establish lower-cost WANs and provide remote access to workers. But they can be complex to deploy and maintain. You will start this chapter with a brief introduction to VPNs and then review Aruba solutions that simplify VPN deployment and maintenance.

VPN types

A VPN enables devices to connect to each other securely over an insecure network such as the Internet.

Figure 17-1: VPN types

Site-to-site VPN

A site-to-site VPN securely connects two sites together. As shown in Figure 17-1, a company can use a site-to-site VPN to connect a branch office to a central data center over the Internet—a much more cost-effective option than a private WAN line.

Client-to-site VPN

A client-to-site VPN securely connects a client to a site over the Internet. It enables remote workers and “road warriors” to access corporate resources from wherever they are working.

IP security (IPsec)

IPsec is a common, open-standard protocol for VPNs that carry IP traffic. IPsec uses algorithms such as AES and SHA to encrypt data and ensure its authenticity. IPsec also provides replay protection.

Figure 17-2: IP security (IPsec)

For the purposes of this study guide, you are interested in tunnel mode IPsec, which sets up a tunnel between two IPsec hosts or gateways. This tunnel can carry traffic on behalf of clients behind the IPsec gateways in a site-to-site VPN. In a client-to-site VPN, such as the one shown in Figure 17-2, tunnel mode IPsec carries traffic between a remote client and devices behind a gateway at the headquarters or data center. The client encapsulates its own IP traffic with an ESP header and outer IP header. The gateway encapsulates traffic on behalf of clients and servers at the main site.

IPsec security associations (SAs)

Each IPsec tunnel features two security associations (SAs), as shown in Figure 17-3, one for carrying traffic in each direction. The SA defines parameters such as the algorithms used to authenticate and encrypt traffic, as well as the actual authentication and encryption keys. The SAs and their keys can be defined manually on each side of the tunnel. However, often the two tunnel endpoints use Internet Key Exchange (IKE) or IKEv2 to negotiate the SA automatically. Using IKE/IKEv2, endpoints negotiate algorithms, authenticate each other, and securely generate shared keys for the SAs.

Figure 17-3: IPsec security associations (SAs)

Deploy Aruba VIA

Next, you will learn how Aruba VIA simplifies establishing client-to-site VPNs.

VIA introduction

Aruba’s solution for client-to-client VPNs is Virtual Intranet Access (VIA). VIA supports all of the pieces required for a client-to-client VPN, including IKEv1 and v2, Xauth, and NAT-T. Even better, VIA simplifies client-to-site VPN deployment, eliminating the need for complex configuration on the part of users and admins.

Figure 17-4: VIA introduction

VIA consists of software that users can install on their devices to permit access to the corporate network over any connection to the Internet. This is very useful for remote and mobile workers. As shown in Figure 17-4, employees can install VIA on many different end user device types, including Android, IOS, Linux, MacOS, and Windows.

Aruba makes the software available in popular play stores, as well as in the Aruba Support Portal (ASP). Companies can automate the distribution of the software using any of the techniques that they typically use such as MDM solutions.

VIA clients connect to VPN Concentrators (VPNCs) at the data center or headquarters.

VIA configuration process

To configure a VPNC or VPNC group to support VIA, you will need to follow the steps illustrated in Figure 17-5. You must create a VPN pool in the VPN > General VPN settings. You also create several profiles in the Security > L3 Authentication page. The profiles define how VIA clients connect and establish tunnels, as well as how they authenticate. You must also create the roles to which VIA clients will be assigned. And you need to consider which forms of authentication you are using and the certificate requirements for them.

Figure 17-5: VIA configuration process

You will learn more about these steps over the rest of this section.

If you configure your solution to use IKE with PSKs, you must also configure the PSKs. However, PSKs are not recommended.

VPN pool configuration

The clients are most likely using a private IP address that is only meaningful in the client’s remote location. To permit clients to communicate with corporate resources, the VPNC needs to assign the clients valid IP addresses in the corporate network, as shown in Figure 17-6.

Figure 17-6: VPN pool configuration

You should create at least one VPN pool in the VPNC’s VPN > General VPN settings. Specify a range of IP addresses that are reserved for the VIA clients. The corporate LAN must be able to route traffic back to these IP addresses. To facilitate this, you must configure a VLAN on the VPNC and assign an IP address in this subnet. The default gateway can be the VPNC or an upstream router. If the VPNC acts as the default gateway, make sure that it advertises the subnet to the rest of the network.

Alternatively, you can apply source NAT to the pools, which causes the VPNC to translate the source IP addresses to its own IP address on the outgoing interface. Then all return traffic to the VIA clients will be sent back to the VPNC.

VIA Web authentication and authentication profiles

The VIA solution uses several profiles to regulate users’ remote access. When the VIA client is first installed on a device, it needs to connect to the VPNC with HTTPS and download a connection profile with the correct VPN settings, as shown in Figure 17-7. The VPNC uses its Web authentication profile to determine how to authenticate the client.

Figure 17-7: VIA Web authentication and authentication profiles

The VPNC supports just one VIA Web authentication profile, which is the default profile. This profile simply references VIA authentication profiles, and you can add as many of the VIA authentication profiles as you want to the default Web authentication profile.

The VIA authentication policy specifies the default role to be assigned to VIA clients if a role cannot be derived in another way. It also specifies the server to which clients are authenticated, which can be CPPM, another RADIUS server, or the VPNC’s internal database. As always, Aruba recommends using CPPM as the centralized authentication source and policy manager. You can also set the authentication protocol to PAP or MSCHAPv2. Note that users authenticate to the Web authentication profile with usernames and passwords. If you are using CPPM (or another RADIUS server) and CPPM uses AD as the authentication source, you must set the authentication protocol to MSCHAPv2.

VIA connection profile settings

If the client passes Web authentication, the VPNC pushes the VIA connection profile associated with the client’s role to the client. As shown in Figure 17-8, this connection profile defines all the settings that the client needs to contact the VPNC and establish an IPsec SA. It provides a list of one or more VIA servers, which are the public IP addresses of VPNCs. The connection profile further defines whether IKE version 2 is permitted and policies for IKEv1, IKEv2, and IPsec. Typically, you should enable IKEv2, which disables IKEv1. Choose EAP-TLS for the IKEv2 authentication method, as this option is secure and permits authentication to CPPM. When you choose EAP-TLS, also remember to enable EAP-TLS pass-through in the IKEv2 settings (outside of the connection profile). You should also configure the profile to force the client to validate the server’s certificate.

Figure 17-8: VIA connection profile settings

The connection profile can enable split tunneling, which allows a connected VIA client to send Internet traffic over the local Internet connection and tunnel corporate traffic. When the connection profile permits split tunneling, you must specify to which destination networks VIA should implement tunneling. If you are using split tunneling, you can also mandate that the Internet traffic be sent to a specific content security gateway URL for filtering.

The connection profile references a VIA authentication profile, which tells the VPNC how to authenticate the client. This profile includes the default role to which an authenticated client is assigned as a last resort. It also specifies the server group to which to authenticate the client during IKE.

Connection profiles include more other advanced options. You can learn more about these in the documentation.

Downloading or updating the connection profile

If users obtain and install the VIA client on their own, the client will not have a connection profile. The first time that the user opens the VIA application, it will prompt the user to download a profile. The user will need to specify the VPNC’s FQDN. The VIA client will then contact the VPNC over HTTPS. As shown in Figure 17-9, the VPNC uses the VIA authentication profile referenced in the VIA Web authentication profile to authenticate the client. It can enforce username/password-based authentication with PAP or MSCHAP, or it can have the client authenticate with certificates.

Figure 17-9: Downloading or updating the connection profile

If the user authenticates successfully, the VPNC uses the Aruba-User-Role assigned to the user to look up the user’s connection profile. It then pushes the profile to the client.

Once a client has a configuration profile on it, whenever it needs to reconnect, it first contacts the VIA server referenced in that profile, re-logs in, and updates the profile. The process occurs in much the same way as the initial profile download.

Example VPN connection establishment

After the client has the connection profile, it can try to connect to the VPNC. The same IKEv1 or IKEv2 process that you learned about earlier occurs. However, you should take note of some features particular to VIA and authentication to CPPM.

Figure 17-10: Example VPN connection establishment

The VIA connection profile configured on the VIA client references a VIA authentication profile. During the initial IKE proposal exchange, the client submits the authentication profile name as vendor-specific data. The VPNC can then determine how to authenticate the client.

When you select EAP-TLS for the authentication method with IKEv2, you can authenticate the user against CPPM. Make sure that the VIA authentication profile specifies a server group with the CPPM server or servers. Also make sure that EAP-TLS pass-through is enabled in the VPNC’s VPN > IKEv2 settings. This setting allows CPPM to terminate the EAP-TLS session.

As you see in Figure 17-10, CPPM requires an authentication service that selects the RADIUS requests from the VPNC. This service should authenticate the clients with EAP-TLS. Note that the clients will need to trust CPPM’s certificate, and CPPM will need to trust their certificates. The CPPM service uses role mapping and enforcement profiles like the ones about which you have learned throughout the study guide. Create rules that apply an enforcement profile with an Aruba-User-Role name. Depending on the company preferences, users might receive the same roles that they receive locally, or you might create new roles for them with different access rights.

When the VPNC receives the RADIUS Access-Accept, it allows IKE phase 2 to complete, and the IPsec SAs come up.

Roles for VIA

You must make sure that the VPNC supports the user roles to which clients are assigned at various points of the process.

You can set up the solution to assign clients that pass Web authentication to one role—which will let them download the VIA connection profile—and clients establish a VIA connection to a different role—which will let them forward traffic through the gateway. Or you can choose to assigns users to the same roles for both.

Figure 17-11: Roles for VIA

Requirements for Web authentication

As you have seen, the client completes Web authentication to download VIA and VIA connection profiles. As with any authentication process, the user is assigned a role at the end, either by an Aruba-User-Role VSA or based on the VIA authentication profile default role. The role does not require any access rules because the client is not actually passing traffic through the VPNC at this point. But the role must reference the VIA connection profile for the client. If you are using CPPM to authenticate the users, CPPM can assign different types of users to different roles, and you can assign those users to different VIA connection profiles.

Requirements for VIA connection

During the IKE or Xauth connection process, the client authenticates and is assigned a role. If CPPM is the authentication server, it can send the role in an Aruba-User-Role VSA, which is the typically preferred option. As a last resort, if it cannot assign a role in another way, the VPNC assigns the client to the default role in the VIA authentication profile associated with the VIA connection profile. You must also make sure that corresponding roles exist on the VPNC.

You can set up whatever access rules meet the company requirements. You see an example in Figure 17-11. This role permits the client to access DHCP and DNS services on the corporate network. It also allows general traffic to and from the corporate network. The clients assigned to this role use split tunneling, so they do not need the VPNC to provide them with access to the Internet.

You should also assign the role to the VPN pool that you configured earlier as an L2tp pool.

CPPM and role assignment

If you want to assign a client to the same role when it downloads the connection profile and when it connects to the VPN, CPPM can use a single RADIUS service for both types of authentication.

If you want to divide the roles, keep in mind that CPPM, as the authentication server, will need to distinguish between the types of authentication. One way to achieve this is to create two services that accept requests from the VPNCs. One service also has a service rule that selects the RADIUS-IETF Framed-MTU attribute. Only authentication requests that are part of the VPN connection process will match that rule. The other service, which does not have that rule, will apply to clients undergoing Web authentication to download the connection profile. You can then specify different enforcement policies in each service so that CPPM applies different enforcement profiles, and Aruba-User-Role VSAs, to the same user for Web authentication and IKE authentication.

Certificate requirements

You need to make sure that the correct certificates are in place to support the solution.

Figure 17-12: Certificate requirements

Each remote user needs a user certificate. These certificates can be issued in the same way as certificates for EAP-TLS or TEAP for 802.1X. And if the user already has a certificate for that purpose on the machine with the VIA client, the client can use that same certificate.

When the client establishes an HTTPS session with the VPNC to download the connection profile, it must validate the VPNC’s Web server certificate, as shown in Figure 17-12. That means that you need to upload a certificate signed by a trusted CA in Central and assign that certificate for use on the VPNC’s Web server. Like any Web server certificate, its subject name and DNS SAN must specify the FQDN at which the clients contact the VPNC.

If you are using IKEv2 EAP-TLS with CPPM acting as the authentication server, as typically recommended, the VIA client must trust CPPM’s RADIUS/EAP certificate. CPPM must also be able to validate the VIA client’s certificate. In other words, the root CA certificate for the clients’ certificates must be loaded to CPPM’s trust list with the EAP usage.

As a final note, the VPNC also needs a VIA server certificate simply to initialize IKE, even when the VPNC is using EAP-TLS pass-through to CPPM. You might be able to select the same certificate that you are using for HTTPS as the VIA server certificate.

If you configure “user-cert” as certificate authentication method for IKEv2, the VPNC validates VIA users’ certificates. In this case, you need to upload the root CA certificate for the VIA users’ certificates on the VPNC. Specify that certificate as the VPN client CA. In this scenario, the VIA clients also need to trust the root CA for the VPNC’s VIA server certificate. If you need to learn more about this setup, refer to Central documentation for VPNCs.

Firewall ports to open

Make sure that the company’s firewall has the following ports, shown in Figure 17-13, open to the VPNC:

TCP 443 for HTTPS

UDP 500 for IKE

And UDP 4500 for NAT-Traversal (NAT-T); NAT-T enables IKE/IPsec peers to communicate when one or both of them are behind a device that implements NAT

Figure 17-13: Firewall ports to open

Viewing the connection on the VPNC

A typical scenario where a client uses VIA to connect to a remote site is shown in Figure 17-14.

Figure 17-14: Viewing the connection on the VPNC

The VIA user is at a remote location and has received an assignment to a local IP address of 192.168.2.26. He uses his VIA client to connect to the VPNC and a secure VPN tunnel forms. His device receives a tunnel IP address assignment of 172.16.92.250 from the VPN pool.

When you issue the command show user to assess end user connectivity, you can view the VIA users Leo and Robert; they used VIA-VPN authentication, as shown in Figure 17-14. The IP column validates the VIA user’s tunnel IP address. You will also notice that, even though VIA user’s local address is 192.168.2.26, his end-of-the-tunnel shows up as 50.101.60.71 in the “VPN link” column. This is probably because his local address is NAT’ed to an internet-routable IP address.

It is best to assign authentication usernames that reflect the actual user’s name. This makes it easier to find and troubleshoot a specific user. However, if this is not the case, all is not lost. You can still help a user by asking them for their assigned IP address. The user simply looks at their VIA client configuration.

Troubleshooting on the VIA client

Users can also view settings within their VIA application.

Figure 17-15: Troubleshooting on the VIA client

To view these settings, open the application and select the gear icon. You can then further assess client connectivity. The Network tab shows the laptop’s local IP address and VIA-assigned IP address (from the VPN pool). You can also view the VPNC server IP address. Now, you can verify the user’s IP address and identify the user on the VPNC using the show user command.

For example, in the VPN Profiles tab, you see a VIA user connected using the authentication profile “student-via,” as shown in Figure 17-15. If you needed more information about this profile, you could expand the Server and Auth Profile sections. You can also clear the profiles, but then you would need to re-enter the server IP address, as well as your username and password, so that VIA can download a new profile.

The logs tab reveals current and previous connectivity issues.

Overview of Aruba SD-WAN solutions

Last, you will see how Aruba SD-WAN solutions automate the establishment of secure VPN tunnels between branches and headquarters.

Aruba SD-Branch

Aruba Software-Defined Branch (SD-Branch) automates the deployment of IPsec tunnels between gateways at different branches—and does much more. Consisting of software-defined WAN (SD-WAN) and software-defined (LAN) components, Aruba SD-Branch delivers end-to-end orchestration of connectivity and security across a multi-site orchestration.

Figure 17-16: Aruba SD-Branch

Aruba Software-defined WAN (SD-WAN) uses automation to make it feasible for companies to use broadband Internet connections for their WAN. An Internet-based WAN requires VPNs for security, but protocols like IPsec traditionally require extensive and complex setup. SD-WAN automates the tunnel establishment and continues to orchestrate the tunnels, making it easy for companies to deploy the solution and add new branches. Path quality monitoring and other quality of service (QoS) mechanisms optimize the performance. SD-WAN further enables companies to deploy multiple WAN technologies at a site. As shown in Figure 17-16, a site could use a private MPLS-based connection to carry important traffic to the data center, for example, and a broadband Internet connection to carry less important traffic. All paths are secured with IPsec. Dynamic path steering enables gateways to automatically choose the right path for each conversation based on the organization’s policies. Local gateways can also output traffic destined to the Internet directly out the local Internet connection.

Aruba Central orchestrates the SD-WAN solution from the cloud. From Central, admins can also manage the SD-LAN components of the solution. The Aruba network infrastructure at the branch uses dynamic segmentation to enforce role-based access controls for every user and device.

Aruba EdgeConnect SD-WAN solutions

Aruba also supports a separate solution line for SD-WAN solutions, as shown in Figure 17-17. Aruba EdgeConnect consists of EdgeConnect platforms, which are deployed at each site to provide routing, security, SD-WAN and WAN optimization. They are controlled by an Aruba Orchestrator, which provides centralized policy orchestration, monitoring, and reporting. (Do not confuse this Aruba Orchestrator with the Central SD-WAN Orchestrator.) Aruba Boost WAN optimization, an optional component, optimizes the WAN for latency sensitive applications with features such as data reduction.

Figure 17-17: Aruba EdgeConnect SD-WAN solutions

Companies with Aruba infrastructure at the branch can choose to deploy Aruba SD-Branch or Aruba EdgeConnect. Aruba SD-Branch focuses on the complete branch solution, including secure WLAN and LAN, as well as secure WAN. Aruba EdgeConnect SD-WAN focuses on the WAN. It is designed for companies who require the highest levels of performance, quality of service, and automation for their SD-WAN connections. This study guide focuses on Aruba SD-Branch solutions;you can attend other training to learn more about EdgeConnect.

Aruba SD-Branch components (AOS 10)

An Aruba SD-Branch solution includes a branch gateway at each site. Larger sites, or sites that require particularly high availability, can have two branch gateways deployed in a cluster. Typically, companies should deploy Aruba 9x00 Series as the branch gateways. They can also use the 7000 Series for this role; however, only the 9x00 Series Gateways support full Unified Threat Management (UTM) capabilities.

Figure 17-18: Aruba SD-Branch components (AOS 10)

As shown in Figure 17-18, the company also requires headend gateways at the headquarters or data center. These gateways are sometimes called VPN Concentrators (VPNCs). Smaller organizations can use the 7010 Series or 9000s for this role, while larger enterprises should deploy 7210 models or above. (Note that the 7005, 7008, and 7205 models are not supported.) Aruba also offers Virtual Gateways, which companies deploy on hardware of their choice.

An SD-Branch solution uses the same Aruba APs and AOS-CX switches as any AOS 10 architecture.

Central provides cloud-based orchestration for the SD-WAN solution, as well as cloud-based management and automation for all the network devices.

As of the release of this study guide, SD-Branch features are supported with Foundation licenses; however, some features require Advanced, Foundation with Security, or Advanced with Security licenses. Refer to the latest datasheets for up-to-date information on licensing.

Aruba 7200 Series models can theoretically operate as branch gateways; however, they support more clients and greater throughput than a branch requires.

Overview of Aruba SD-Branch architecture options

As of Central 2.5.3, Aruba SD-Branch supports topologies, which you can combine together flexibly.

Figure 17-19: Overview of Aruba SD-Branch architecture options

Hub-Spoke

SD-Branch solutions are founded on hub-spoke topology. This topology consists of tunnels between BGWs and VPNCs. The hub-spoke topology enables branch clients to communicate with devices at a data center or main campus. It can also feature redundancy, as shown in Figure 17-19, with a BGW that connects to two more VPNCs. However, if the architecture becomes too large or complex having only hub-spoke tunnels can limit scalability.

Hub-Mesh

You can place VPNCs in a hub-spoke architecture within one or more hub-mesh topologies. The VPNCs in the hub-mesh establish tunnels between each other. Then a BGW in branch 1, for example, can reach DC 3 through a connection to DC 1. A hub-mesh topology supports greater scalability for a company with multiple VPNs at multiple sites.

Branch-Mesh

For many companies branch clients only need to communicate with the Internet and data center. However, some companies need to establish communications directly between some branches. These customers can add a branch-mesh topology to the solution. A branch-mesh architecture requires each BGW to connect to at least one VPNC. You can then choose to connect BGWs to one or more BGWs in the same Central group or a different group. You can pick and choose the precise BGWs that connect together for great flexibility.

Refer to Central documentation for the most up-to-date limitations on the number of BGWs in a branch-mesh topology.

IPsec SA establishment with Central SD-WAN Orchestrator

The Central SD-WAN Orchestrator automates the establishment of IPsec SAs without the need for IKE. For each IPsec tunnel, it creates an inbound and outbound ESP SA (direction from the viewpoint of the initiator). It sets the SPI for the SA and also chooses the encryption and authentication algorithms, as shown in Figure 17-20. It also generates the encryption and algorithm keys.

Figure 17-20: IPsec SA establishment with Central SD-WAN Orchestrator

Central SD-WAN Orchestrator then distributes this information to both sides of the tunnel, also informing the gateways the IP address of their peer. The initiator, which is the BGW for hub-spoke tunnels, then contacts the peer, securing traffic with the keys provided by Central. The peer detects that the keys are correct for the SA with that peer, and the tunnel is established.

In addition to setting up the IPsec tunnels automatically, Central also orchestrates routing over those tunnels using Overlay Agent Protocol (OAP).

From admins’ point of view, they only need to configure a few simple settings to establish a hub-spoke architecture. Assume that the VPNCs and BGWs are already configured with their base IP, VLAN, WAN uplink, and routing settings. Admins then enable SD-WAN Orchestration on VPNCs and BGWs. In BGWs’ groups, they use the DC preference list to choose the VPNCs to which the BGWs should connect, listed in order of priority for routing traffic. Central then automates establishing the VPN. For routing, admins simply choose which connected networks or routing protocols they want to redistribute into OAP. They can also redistribute OAP networks into a routing protocol (for example, to advertise branch networks in the data center). Central then automates programming BGWs’ and VPNCs’ routing tables.

Note that SD-Branch also supports NAT-T for cases when one or both gateways are behind a device that implements NAT.

For more information on setting up an SD-WAN solution in Central, refer to Central documentation.

Viewing IPsec SAs on an Aruba gateway

When you use SD-Branch, you do not need to configure IPsec settings. Instead you simply specify with which VPNCs you want your BGWs to establish tunnels. Aruba SD-WAN Orchestrator then handles the SA establishment.

Figure 17-21: Viewing IPsec SAs on an Aruba gateway

You can view tunnels on a gateway within Central. Go to the specific gateway view and click WAN. Click the Tunnels tab. You will see a list of tunnels. As shown in Figure 17-21, you can expand each tunnel and see information about the SA such as the encryption and authentication algorithms in use. You can also see the SPIs that identify the two SAs for the tunnel.

Periodic rekeying

Even though Central SD-WAN Orchestrator distributes keys securely, best practices call for periodically rotating the keys. The more traffic that is encrypted by the same key, the more likely it is that the key could be cracked. By frequently changing the keys, Central SD-WAN Orchestrator keeps data security. As shown in Figure 17-22, the SD-WAN Orchestrator periodically rekeys based on SA lifetime. As of the release of this study guide, the default SA lifetime is 7200 seconds (2 hours). The SD-WAN Orchestrator creates a new SA before pulling down the old SA to prevent traffic disruption.

Figure 17-22: Periodic rekeying

Summary

Congratulations! You have completed Chapter 17.

You have learned how Aruba VIA makes establishing secure remote access easy. You also understand that Aruba SD-WAN Orchestrator automates the establishment of secure IPsec tunnels across a highly available WAN.

Learning checks

What is the VIA Web authentication profile used for? To authenticate VIA clients downloading a connection profile

To authenticate the VIA certificate

To authenticate RAPs

To provide the allow list for authenticated VIA clients

Which type of topology do you need to add if you want VPNCs to create tunnels to other VPNCs? Hub-spoke

Branch-mesh

Hub-mesh

Spoke-mesh

Note: For answers to all learning checks, refer to the Appendix.

18

Configure Aruba Gateway IDS/IPS

EXAM OBJECTIVES

✓ Describe the Aruba 9x00 Series Gateways.

✓ Define and apply UTM policies.

Assumed knowledge

Basics of Aruba solution architectures

Aruba gateway IDS/IPS

Aruba 9x00 Series Gateways provide a Unified Threat Module (UTM), which helps them further protect your network from malware, ransomware, denial of service (DoS) attacks, and many other threats.

This chapter explains exactly what Aruba gateway IDS/IPS is, how it works, and how to configure it. You will begin the chapter by learning about the 9x00 Series security features and the difference between an Intrusion Detection System (IDS) and an Intrusion Prevention System (IPS), so you will know what to implement later on. You will also look at the gateway IDS/IPS ruleset and IDS/IPS policies. At the end the first topic, you will take a high-level look at how Aruba gateway IDS/IPS works.

Aruba 9x00 Series Gateway security features

Aruba 9x00 Series Gateways support the AOS security features with which you are already familiar, including a role-based stateful firewall that provides deep packet inspection (DPI) and Web content control (WebCC), as shown in Figure 18-1. In this chapter, you will focus on the integrated Intrusion Detection and Prevention System (IDS/IPS) capabilities, which further protect the corporate WAN against ever-evolving threats.

Figure 18-1: Aruba 9x00 Series Gateway security features

Aruba solutions also support Wireless IDS/IPS (WIDS/WIPS), which detects RF and 802.11-specific threats. This chapter focuses on gateway IDS/IPS, which detects a variety of different types of threats in traffic that flows through the gateway.

IDS and IPS

An IDS, as the name implies, focuses on detecting threats. In this chapter, you are focusing on network-

based IDS. As shown in Figure 18-2, a network IDS monitors traffic that flows through it for signs of malicious activity. If it detects a threat, it generates an event but does not take action to prevent the threat. It is up to admins to respond to the event and determine how to mitigate the threat.

Figure 18-2: IDS and IPS

A network IPS also monitors traffic that flows through it, and, if it detects a threat, it generates a threat event. But it goes beyond detection to mitigate threats. In the case of Aruba gateways, the IPS mitigates threats by dropping packets associated with the threat.

Licensing for gateway IDS/IPS on Aruba 9x00 Series Gateways

To enable gateway IDS/IPS features on 9x00 gateways, you must purchase one of these licenses:

Foundation with Security

Advanced with Security

Figure 18-3: Licensing for gateway IDS/IPS on Aruba 9x00 Series Gateways

These licenses provide the same features as either the Foundation or Advanced license, including SD-WAN. However, as shown in Figure 18-3, they add gateway IDS/IPS, antimalware, and the Security Dashboard. You choose between the Foundation and Advanced options based on your other requirements. For example, the Advanced license provides SaaS Express.

How Aruba gateway IDS/IPS works

Aruba gateway IDS/IPS uses signature-based threat detection. In other words, the Aruba 9x00 Series Gateway checks traffic against a set of rules. Each rule specifies a “signature,” which defines characteristics of a particular threat. The gateway inspects all traffic that flows through it, including traffic from internal clients, traffic received over the SD-WAN, and traffic from external devices on the Internet.

Figure 18-4: How Aruba gateway IDS/IPS works

When the gateway notices that a packet matches a signature in one of its rules, it takes action. If it is operating in IDS mode, it creates an event to inform admins of the detected threat, as shown in Figure 18-4. In IPS mode, the gateway creates an event and also drops traffic.

Aruba gateway IDS/IPS ruleset

Aruba gateway IDS/IPS uses a ruleset with tens of thousands of signature-based rules. Aruba also updates the rules frequently, and you can configure your gateways to automatically download the updates.

The gateways can detect threats in many categories. For example, they can detect traffic to and from compromised hosts, based on a private, reliable list of known compromised hosts that is updated daily. They can detect Bitcoin mining, exploit kit activity, malware, and mobile device–specific malware. They can detect signs of phishing or Trojans, as well as many other vulnerability exploits, attack types, and malware types.

For a complete list of threat categories, visit:

https://help.central.arubanetworks.com/latest/documentation/online_help/content/sd-branch/idps/appendix/appendix.htm

Aruba gateway IDS/IPS policies and CVSS

Each of the threat categories includes many rules. You configure your gateway to use particular rules by selecting one of three simple policies for IDS or for IPS, shown in Figure 18-5. The lenient policies detect or prevent only the most severe threats. The moderate policies detect or prevent threats of a moderate severity or higher. And the severe policies detect or prevent the broadest range of threats.

Figure 18-5: Aruba gateway IDS/IPS policies and CVSS

Aruba uses industry standards to rank the severity of each threat. As you may recall from Chapter 13, the security industry uses the Common Vulnerability Scoring System (CVSS) to assign known vulnerabilities or threats a score from 1.0 to 10.0, 1.0 being the least severe and 10.0 being the most severe. Each rule in the Aruba gateway IDS/IPS ruleset has a CVSS, based on the vulnerability or threat associated with that rule.

If you select the IDS Lenient or IPS Lenient policy, the gateway applies all rules from the current year and previous two years with a CVSS of 8.0 or higher. The IDS Moderate or IPS Moderate policy applies rules from the current year and previous two years with a CVS of 6.0 or higher. And applying the IDS Strict or IPS Strict policy causes the gateway to use rules from the current year and previous three years that have a CVSS of 4.0 or higher.

Aruba gateway IDS/IPS configuration

You will spend the rest of the chapter learning how to configure both IDS and IPS to match your gateway configuration to meet practical needs. You will learn how to manage rules to maintain security while supporting productivity, as well as how to integrate gateway IDS/IPS with a third-party Security Information and Event Management (SIEM) solution.

Overview of gateway IDS/IPS configuration

To configure IDS/IPS on 9x00 Series Gateways, you will want to follow the steps illustrated in Figure 18-6. First, enable traffic inspection, which provides visibility into the packets that move through the gateways. Then update the gateway IDS/IPS rulesets to ensure that gateways use the latest signatures to detect threats. After that, choose between IDS or IPS for the inspection mode. You then act on that choice by configuring IDS or IPS.

Figure 18-6: Overview of gateway IDS/IPS configuration

Enable traffic inspection

To enable traffic inspection on a gateway, you must first ensure that you have an active gateway subscription with the Security license discussed previously. And you must have successfully onboarded the gateway in Aruba Central. Check the current Central version to see whether you must reboot the gateway after you first enable traffic inspection; if you do need to, plan to set up IDS/IPS during a scheduled outage.

Figure 18-7: Enable traffic inspection

You can configure the gateway IDS/IPS settings at the group level or the individual device level. Then under Manage, click Security > Gateway IDS/IPS. Click the Config icon. In the General tab, select the Enable traffic inspection check box, as shown in Figure 18-7.

Update rulesets

When you first enable gateway IDS/IPS, you should update the ruleset manually. Do so from the same page in which you enable traffic inspection. Within the Ruleset section, select the version from the Update To drop-down list. Confirm that you’d like to update when the message shown in Figure 18-8 is displayed.

Figure 18-8: Update rulesets

You should generally also enable automatic updates to ensure that your gateway learns how to detect new threats. Select the Automatically update the ruleset check box. Choose when the periodic update occurs by selecting Week or Day from the drop-down list. Then choose the day of the week and time, for a weekly update, or the time of day, for a daily update. Then click Save.

Choose whether to use IDS or IPS

You will need to consult with the company’s security team to determine whether to configure the gateways in IDS mode or IPS mode.

Figure 18-9: Choose whether to use IDS or IPS

As shown in Figure 18-9, IDS mode minimizes the risks of disruption based on false positives. The IDS simply flags potential threats. The security team takes responsibility for viewing the threats and making well-informed decisions about how to address them. The downside, however, is that more time will elapse between the gateway detecting a threat and mitigation of the threat. In this time, the company can be exposed to ill effects. Admins and security team members also must take greater responsibility to monitor the system and address threats.

An IPS responds immediately to detected threats—in the case of Aruba gateways by dropping traffic that matches a rule. This immediacy is important, since every second counts when defusing an active threat. However, if the policy is too strict for the company’s needs, IPS may react to valid traffic as if it is a threat, interfering with legitimate business operations.

Before you enable IPS mode, you might enable IDS mode for a period of time. Admins can then monitor what threats the gateways detect and determine which threats are real and which detect vulnerabilities that the company might want to ignore based on its own needs and requirements. You can then allow list the specific rules that are flagging false positives. When the security team is confident that all necessary traffic is being allowed, you can change the mode to IPS.

Configure IDS

You will now learn how to configure IDS, if you have determined that IDS is the best fit for a company. Again you should be in the Config settings under Security > Gateway IDS/IPS for a branch group with gateway IDS/IPS-enabled gateways. Alternatively, you can configure the settings at the device level.

Figure 18-10: Configure IDS

In the General tab under Inspection, check the Mode. By default, IDS is selected.

You must also select the IDS policy. Click the Policies tab. When IDS mode is enabled, you can choose from the three IDS policies(IDS Lenient, Moderate, and Strict), and the IPS policies are grayed out, as shown in Figure 18-10. As you learned earlier, the policy determines which rules the gateway IDS/IPS engine uses to inspect traffic. The IDS Lenient policy has the fewest rules, and the IDS Strict policy, the most. Click the slider in the State next to a policy to select it.

Configure IPS

To configure IPS, click the Config icon for Security >Gateway IDS/IPS at the branch group or device level.

Figure 18-11: Configure IPS

In the General tab, under Inspection, select IPS as the mode of inspection, as shown in Figure 18-11. Then click the Policies tab to select the IPS Lenient, IPS Moderate, and IPS Strict policy. Keep in mind that the Lenient, Moderate, and Strict policies have the same characteristics—concerning ruleset timeframes and CVSS scores—as the IDS policies.

Select the gateway IDS/IPS Fail Strategy

For both IDS mode and IPS mode, you should also configure the Fail Strategy, which determines how the gateway behaves if its IDPS engine stops functioning.

Figure 18-12: Select the gateway IDS/IPS Fail Strategy

The Bypass Fail Strategy allows all traffic to continue on to its destination in the LAN, WAN, or Internet, as shown in Figure 18-12. The Block strategy, on the other hand, prevents all traffic flow if the IDPS engine goes down. This holds true even if the Inspection Mode is IDS.

Most companies will prefer the Bypass strategy to prevent complete disruption if a single security system goes down. However, for some use cases that require the utmost security at all times, such as certain banking applications or classified government intelligence, the Block strategy is appropriately severe.

View rules and allow list rules

Sometimes you want to allow list the specific rules because your security team has investigated them and determined that the traffic flagged by these rules does not pose a significant risk to the company. When a rule is allow listed and the gateway detects a threat based on that rule, the gateway still creates a threat event, but the event indicates that the traffic is allow listed. If the gateway is in IPS mode, it does not drop the traffic.

Figure 18-13: View rules and allow list rules

Under the Policies tab, for both IDS and IPS, you can click on the name of the policy in effect (Lenient, Moderate, or Strict) to see a list of the rules that are included in that policy.

You can then select a rule and move it to the allow list. Click on the icon at the right end of the row, as shown in Figure 18-13. Or you can select multiple rules at once and click on the Move To Allow List command in the bottom right-hand corner of the page.

Send data to a SIEM

The Aruba gateway can send threat event data to a third-party Security Incident and Event Management (SIEM) server, such as Splunk. SIEM provides a holistic picture of the security posture of the organization by aggregating and correlating data from disparate sources in the network. Admins can then perform advanced analysis and generate reports. A SIEM often provides automated alerts and workflows. For example, it might generate help tickets that notify admins of issues and give them the information they need to start addressing the problem.

Figure 18-14: Send data to a SIEM

Before configuring SIEM integration on the gateways, check to make sure you have an active subscription with a third-party SIEM provider. You will also need to know the server URL and an index number and have an authentication token.

You enable reporting to SIEM systems in the global Gateway IDS/IPS settings. (In the Network Operations app, set the filter to Global. Under Manage, navigate to Security >Gateway IDS/IPS. Click the Config icon to open the Gateway IDS/IPS configuration page.) Go to the SIEM tab, shown in Figure 18-14. Then select the Enable reporting of threats to SIEM systems check box and click Save.

To add a SIEM for gateway IDS/IPS, click the + icon in the Servers table. In the Add SIEM Server window, enter the Name, URL, Index, and Token for the server. Click Test Connection to verify the connection. Then click Add if the test is successful.

Security Dashboard

After you have configured IDS/IPS on your gateways, Central collects information about the threats that they detect in a Security Gateway IDS/IPS Dashboard. You can view this dashboard at the global level, at the group level for a group that includes IDS/IPS-enabled gateways, or at the gateway level. Go to Security and select the Gateway IDS/IPS tab. Make sure that Summary is selected in the top right corner, as shown in Figure 18-15.

Figure 18-15: Security Dashboard

As shown in Figure 18-15, the dashboard provides an overview of the detected threats, breaking them down by type. It further presents trends, allowing you to see if the types of detected threats are changing over time. The Most Affected Gateways section lets you focus on the gateways finding the most threats while the Top Hosts section lets you see the top sources triggering the threats.

Example threat details

You can click the List icon in the top right corner to see a list of detected threats, as shown in Figure 18-16. Then you can click a threat to see more details about it. You can see the detected signature and the relevant threat category for that signature. The page also displays the source IP address for the malicious traffic and its destination IP address, as well as a deeper dive into the exact contents of the traffic.

Figure 18-16: Example threat details

Summary

You began this chapter by learning about Aruba gateway IDS/IPS from a conceptual standpoint. You reviewed the broader features of 9x00 Series Gateways, distinguished between IDS and IPS, and reviewed licensing for gateway IDS/IPS. You also learned how the gateway IDS/IPS engine uses rulesets and the actions that it can apply.

Then you learned how to configure IDS, how to configure IPS, how to manage specific rules, and how to send data to a SIEM.

Learning checks

How does Aruba gateway IDS/IPS detect malicious traffic? APs and switches notify the gateway when they detect malware.

CPPM notifies the gateway when it detects malware.

The gateway detects signatures in the traffic that indicate the presence of threats.

The gateway detects anomalies in the traffic that differ from usual traffic patterns.

For which use cases should you recommend IDS, as opposed to IPS?

Why might a customer integrate Aruba gateway IDS/IPS with a SIEM server? To allow traffic to continue through a gateway if the IDPS engine goes down

To prevent a gateway from forwarding traffic if the IDPS engine goes down

To integrate gateway IDS/IPS with the company’s automated security event management

To ensure that gateways have the most up-to-date rules

Note: For answers to all learning checks, refer to the Appendix.

19

Use Central Alerts to Investigate Security Issues

EXAM OBJECTIVES

✓ Investigate Central alerts.

✓ Recommend action based on the analysis of Central alerts.

Assumed knowledge

Basics of Aruba solution architectures

How to implement Aruba WIDS/WIPS

How to implement Aruba gateway IDS/IPS

Aruba Central security alerts

Central alerts give admins insights into the network from a centralized source. With timely notification of potential issues, admins can take action to secure the network.

This chapter provides an overview of the alerts supported in Central. You will learn about the notification options and how to configure the precise options that you want for each alert.

Central alert overview

Throughout this study guide, you have learned about how to configure several features related to detecting and mitigating threats. However, admins are not constantly in network management interfaces, checking on functions. They need to be alerted to the most critical issues as those issues occur so that they can take timely action.

Figure 19-1: Central alert overview

Aruba Central collects alerts from the APs, switches, and gateways that it manages. Admins can look for the alerts in the Central interface. But perhaps even more critically, Central can send notifications in response to alerts, as shown in Figure 19-1, calling the most important issues to admins’immediate attention. Using the alert as the starting point, admins can drill down into the details and begin an investigation.

Central alerts help admins to track a variety of issues, but this study guide will focus on the security-related ones.

Central alert types

Aruba Central groups alerts into seven categories, as shown in Figure 19-2:

Figure 19-2: Central alert types

User—User alerts relate to admin accounts on Central.

Access Point—Central gathers these alerts from managed APs. Some of these alerts deal with general connectivity, while others, like Rogue AP Detected, refer to security events.

Switch—Central gathers these alerts from managed switches. Again, the alerts deal with a variety of issues from connectivity issues to security ones.

Gateway—Central gathers these alerts from managed gateways. They report on issues like gateway connectivity and WAN health, as well as IDS/IPS functions.

Connectivity—These alerts report on client connectivity and authentication.

Audit—These alerts trigger when configurations change.

Site—Site alerts reduce the number of device disconnect alerts when a widespread issue such as a site outage occurs. For example, if site alerts are configured with Severity as Major, Duration as 10 minutes, and Site as site1, a single alert saying “Aggregated Device Disconnects” is raised on the user interface for every set of device belonging to “site1” that goes down within 10 minutes of the first DOWN event limited to 100 devices per alert.

Central alert severities

Each alert has a severity level. From least to most severe, the four levels are: Warning, Minor, Major, and Critical.

Figure 19-3: Central alert severities

Some alert types, such as Rogue AP detected, have a single severity assigned to any alert of that type. For other alert types, such as Gateway Threat Count, you can configure multiple severities. Each severity is associated with a different condition. The Gateway Threat Count uses the number of threats detected within a duration period to determine the severity. With the example configuration shown in Figure 19-3, an alert triggers if a gateway detects more than 5 threats within 60 minutes. The severity of the alert depends on the precise number of threats detected. For example, if the gateway detected 6 threats over an hour, the severity is Minor, but if it detected 30, the severity is Major.

Notification options

In addition to configuring Central alerts to appear in the dashboard, you can add one or more of three types of notifications, shown in Figure 19-4. You can select the particular notification options to enable on an alert-by-alert basis.

Figure 19-4: Notification options

Email notifications send an email to one or more recipients. You should set up email alerts for the most critical alerts to which admins need to respond immediately. For example, if an alert indicates an immediate threat to the company’s services or data, admins need to know about it as soon as possible so that they can address the problem before the business is disrupted or data is stolen.

The Webhooks option enables you to integrate the Central alerts with third-party applications such as ServiceNow and Zapier, which are systems for automating IT ticketing and workflows. In this way, the company can apply the same processes that it uses to automate response to other events to the events occurring within the network.

The streaming notification option similarly enables integration with third-party applications. However, this option provides more flexibility. Customers can program their choice of applications to receive data that is published to an API streaming interface.

Configuration of streaming or Webhooks is an advanced topic outside the scope of this study guide.

Configure Central alerts

You configure all alerts settings at the Global scope. Those settings then apply to devices in all groups and at all sites. When you first go to the Alerts & Events page, you will see a list of the alerts. Click Config in the top right corner, as shown in Figure 19-5, to configure the settings.

Figure 19-5: Configure Central alerts

Configure the default email recipient

While you can configure different email addresses for different alert types, you often want to send many of the alerts to the same addresses. You can configure a default recipient or recipients, which you can then easily reference in individual alert settings. In the Config view for Alerts & Events, click Default recipients, as shown in Figure 19-6. Add the desired email addresses and click Save.

Figure 19-6: Configure the default email recipient

Configuring site-specific email notifications

Aruba Central also lets you configure site-specific email addresses for notifying alerts. When an alert is generated for a specific site, Central will automatically send an email notification to the addresses configured for that site.

Figure 19-7: Configuring site-specific email notifications

To configure these notifications, in the Network Operations app, set the Filter to one of the options under Sites. Under Analyze, click Alerts & Events. Make sure the page is displayed in the list view. Click the Config icon. Then, in the Email Configuration Override window, click the plus sign to add addresses. Don’t forget to hit Save.

Please note, as is shown in the information box in Figure 19-7, if you configure site-specific emails, those addresses will override email destinations from global alert configuration pages.

Enable alerts

You enable alerts at the Global level. Select an alert category and click the + icon for each alert that you want to show in the Central interface, as shown in Figure 19-8. The alert is enabled with the default settings. At the default settings, when the alert is triggered, the Central interface shows it in the alerts list with the default severity for that alert. However, notifications are not enabled by the alert by default.

Figure 19-8: Enable alerts

You can verify which alerts are enabled based on the alerts with a check mark.

Configure alerts settings

If you want to change the alert settings, click the name of the alert. In the page that appears, you can change the severity for the alert. For alerts like the one shown in Figure 19-9, you can set the threshold with which each severity is associated. The Duration field refers to the length of time over which the threshold is calculated. In this example, if the gateway detects more than 25 threats in 5 minutes, the alert is triggered.

Figure 19-9: Configure alerts settings

By default, enabling the alert means that the alert triggers based on events on devices in any group, with any label, and at any site. You can use the device filter settings to change that behavior and, for example, enable an alert for some sites, but not others. As soon as you add one group, label, or site to the filter, then the alert can only be triggered by devices in that group, label, or site.

You can also configure one or more notification options. When you select the Email check box, you must specify the recipients or, in other words, the destination email addresses. Selecting the Default recipients check box sends an email to all the recipients list. You can add other recipients, separating their addresses with a comma. If you select the Webhook check box, you must select a pre-configured Webhook, which defines the URL for the third-party solution.

Useful AP security alerts

Earlier in this study guide, you learned about configuring WIDS/WIPS on Aruba wireless devices. When the APs are managed by Central, you can set up alerts and notifications to inform admins when APs detect any of the attacks enabled under IDS. These alerts fall into the three categories shown in Figure 19-10. When deciding for which alert categories to enable email notification, take into consideration how likely the alert is to indicate a serious threat. For example, you might enable an email notification for detecting a rogue AP, but not for all client attacks.

Figure 19-10: Useful AP security alerts

Note that these alerts are only available if the account supports WIDS/WIPS.

Follow up on AP security alerts

When you receive an AP security alert, you should follow up on the issue.

To gain more information, go to the Security > RAPIDS page. There you can see the security events and expand for more information. Record some information about the attack. First, what is the threat type, and is this likely to be a true threat or a false positive. Earlier in this study guide, you received guidelines about which IDS settings to enable and which IDS settings are likely to cause false positives. Refer back to these guidelines as you assess whether a particular type of client or infrastructure attack poses a real threat.

Once you have determined that the event indicates a true threat, you should record information about the client or radio that triggered the alert. The event reports the station MAC address. Then take steps to locate and remove the device. In locating the device, you can consider the detecting devices. For example, if an AM on the north side of floor 1 detected the threat, you know that the offending device was in that general area. If you have uploaded floorplans into Central and placed your APs and AMs on them, then those floorplans can further help you find the location of the threat.

You should then visit that location and investigate further. Talk with employees and admins. It could be possible that users introduced a threat without understanding the issue (such as a rogue AP). Or if the threat truly comes from a hacker, the employees might have insight into who was in the location at the time the threat was detected.

Useful gateway security alerts

Similarly, you learned about setting up IDS/IPS earlier in this study guide. The three alerts shown in Figure 19-11 inform admins of detected threats. Several other alerts report on the IDS/IPS engine’s general functionality and the resources used by that engine. You can enable those alerts too, if you choose.

Note also that the severity configured for the alerts is different from the Threat Lists and Threat Details pages in the Security > Gateway IDS/IPS tab. The Severity value displayed in the Gateway IDS/IPS tab is specific to the threat signature.

Figure 19-11: Useful gateway security alerts

Gateway threat count

This alert is triggered when a gateway detects more threats than the configured threshold (from 50 to 500 threats) in a given duration.

Aggregation for this alert occurs at the gateway level. For example, you might have set the duration to 30 minutes and the threshold to 10 for warning and 100 for major. If a company has three gateways, and one detects 12 threats over the hour, one detects 20 threats over the hour, and a third detects 80 threats over the hour, Central creates three warning alerts, one on each gateway.

Gateway threat count per signature

This alert also triggers based on the number of threats detected over a duration. However, it applies to threats of the same signature. It is also aggregated at the customer level. For example, you might have set the duration to 30 minutes and the threshold to 10 for warning and 100 for major. If a company has three gateways, and one detects 12 threats with the same signature over the hour, one detects 20 threats with the same signature over the hour, and a third detects 80 threats with the same signature over the hour, Central creates one major alert.

Gateway IDS IPS Engine Packet Dropped Detected

If the gateways are using IPS mode, they drop packets in which they detect threats. Gateways generate a “IDS IPS Engine Packet Dropped Detected”alert when the percentage of packets over the duration dropped exceeds the configured threshold value. For example, if you set the duration to 30 minutes and threshold to 1 for a warning alert, the alert triggers when a gateway is dropping, on average over 30 minutes, one out of 100 packets because those packets contain a threat.

Follow up on gateway security alerts

When you see one of the security-related gateway alerts, you should go to the Security > Gateway IDS/IPS page (global, group, or site). You can use the Summary view to look for trends in the Security Gateway IDS/IPS Dashboard. Go to the List view to see a list of threats.

From there, you can record the particular threat type. You can refer to Aruba documentation for more information on each type. You should also be aware that allow listed rules still create alerts. So check whether the alert indicates that the traffic is allow listed, in which case you or other admins have already determined that this traffic does not cause a serious threat.

If you decide that you need to follow up on a potential security issue, you can click the threat in the Threats list and gather more information. For example, you can check the source of the threat. (Keep in mind, though, that the address might be spoofed.) You can also download the packet that triggered the threat.

Using that information, make your best effort to find the attack source and stop it from sending more attacks. If the gateway is not using IPS, mitigating the threat is particularly important. But even if the gateway is dropping the packets with IPS, you want to track down the attack source and prevent more attacks, as far as possible.

If the attack source is internal and you have CPDI and CPPM, you might mitigate the threat as follows. You could find the client in CPDI and gather information about it. What is the type? Which user or users have logged on with this client? You can apply a tag indicating that the client is compromised. If CPDI is integrated with CPPM, you should apply a tag that is used in an enforcement policy for clients of this type and associated with a quarantine or remediation enforcement profile.

You should investigate further as much as possible. Did the user on the device launch the attack deliberately? Or has the device been compromised? Security team members might need to take over the client and interview the user so that they can determine when and how the compromise occurred.

Useful connectivity alerts for security auditing

As shown in Figure 19-12, the “Authentication Failure Detected” alert, under the Connectivity category, can also be useful for security auditing. This alert is generated when there are a high number of client authentication failures in the network. These failures include Wi-Fi security key-exchange failures, 802.1X authentication failures, MAC authentication failures, and captive portal authentication failures.

Figure 19-12: Useful connectivity alerts for security auditing

This alert triggers based on the authentication failures as a percentage of total authentication attempts over a specified time period.

Follow up on authentication failures

As shown in Figure 19-13, widespread authentication failures typically arise from configuration issues, rather than security breaches. If many users at a particular site fail to authenticate, perhaps admins have accidentally changed the RADIUS secret or other settings on a NAD at that site. Or perhaps Android devices do not trust the certificate used by your ClearPass servers. Certificate expiration on a ClearPass server could also cause widespread authentication failures.

Occasionally authentication failures could indicate that a hacker is attempting to gain access to a less secure WLAN that is using MAC-Auth or PSK. Hackers could also attempt to gain access to a network using 802.1X using stolen passwords. However, if you are using certificate-based authentication, you do not need to be concerned with such attempts.

Figure 19-13: Follow up on authentication failures

AI Insights

Aruba Central also offers AI Insights as another way for admins to keep on top of what is happening within the network. With a more traditional approach, admins need to search through alerts and determine whether the alerts indicate troubling changes or unusual activity. AI Insights automatically detects anomalies and highlights them. By checking the AI Insights tab periodically, admins can more quickly detect potentially concerning issues.

In the example shown in Figure 19-14, Insights highlights that the number of clients failing to complete the Wi-Fi security key exchange is unusually high. It further shows the reason for this issue and recommends a next step.

Figure 19-14: AI Insights

Summary

Congratulations! You have completed Chapter 19.

You began this chapter by learning about alerts in Aruba Central. You then learned how to configure Central alert settings, including notification settings.

Learning checks

Match the Config with the Central Scope. _ Email overrides

_ Which alerts to enable

_ Alert settings

Global

Site

Which of these alerts occurs when the number of packets dropped by gateway IPS exceeds the configured threshold? Infrastructure Attack Detected

Authentication Failure Detected

Gateway Threat Count per Signature

Gateway IDS IPS Engine Packet Dropped Detected

Note: For answers to all learning checks, refer to the Appendix.

20

Practice Exam

Introduction

This exam validates candidates’ knowledge, skills, and ability to implement Zero Trust Security (ZTS) using the Aruba portfolio. It covers how to configure Aruba network infrastructure and ClearPass solutions to authenticate and control both wired and wireless users, as well as remote users on a client-to-site VPN. The exam further tests candidates’ ability to collect a variety of contextual information using ClearPass Policy Manager (CPPM) and implement advanced role mapping and enforcement policies. Candidates should also understand how to use Aruba ClearPass Device Insight to enhance visibility. They should be able to set up features such as the ArubaOS-CX Network Analytics Engine (NAE), Aruba Wireless Intrusion Detection System/Intrusion Prevention System (WIDS/WIPS), and Aruba gateway IDS/IPS, as well as understand how to investigate alerts.

Minimum qualifications

The candidate should be a network engineer or help desk engineer working in either a customer or partner environment. The candidate should have about three years of experience working with wired and wireless technologies.

Exam details

Below are details about the HPE6-A83 exam.

Exam type: Proctored

Types of exam items: multiple choice, single response, and multiple responses

Exam duration: 1 hour 30 minutes

Exam length: 60 questions

Passing score: 65%

Delivery languages: English

To register for the exam, you need an HPE Learner ID and a Pearson VUE login and password.

No reference material is allowed at the testing site. This exam may contain beta test items for experimental purposes, which are not taken into consideration for grading. During the exam, you can make comments about the exam items. We welcome these comments as part of our continuous improvement process.

Testing objectives

This exam validates that you can successfully perform the objectives listed in Table 20-1. The objectives are grouped into three sections, and each section is given a weighting.

Table 20-1: Weightings and objectives

Weighting (% of exam) Objectives

76% Protect and Defend Describe PKI dependencies

Mitigate threats by using ClearPass Device Insight (CPDI) to identify traffic flows and apply tags and using ClearPass Policy Manager (CPPM) to take actions based on tags

Explain methods and benefits of profiling

Explain Zero Trust Security in relation to Aruba solutions

Explain Wireless Intrusion Protection System (WIPS) and Wireless Intrusion Protection Detection (WIDS), as well as describe the Aruba 9x00 Series IDS/IPS

Describe log types and use the CPPM ingress event engine to integrate with third-party logging solutions

Explain virtual private network (VPN) deployment types and IP Security (IPsec) concepts such as protocols, algorithms, certificate-based authentication with IKE, and reauth intervals

Set up secure authentication and authorization of network infrastructure managers (with a focus on advanced topics such as TACACS+ authorization and multi-factor authentication)

Secure L2 and L3 protocols, as well as other network protocols such as SFTP

Deploy Authentication, Authorization, and Accounting (AAA) for WLANs with CPPM

Define and apply advanced firewall policies (AppRF, PEF, WIPS, WebCC)

Set up integration between the Aruba infrastructure and CPPM, allowing CPPM to take action in response to events

Configure rogue AP detection and mitigation and other WIDS/WIPS features

Deploy AAA for wired devices with CPPM

Configure 802.1X authentication for APs

Deploy dynamic segmentation

Deploy certificate-based authentication for users and devices

Understand that Aruba SD-Branch automates deployment for the WAN

Design and deploy remote VPN with VIA

Deploy and apply endpoint classification to the device

Define endpoint classification methodology using active and passive methods

Define, deploy, and integrate CPPM and CPDI

22.5% Analyze Investigate Central alerts

Interpret packet captures

Recommend action based on the analysis of Central alerts

Evaluate endpoint posture

Deploy and analyze Network Analytics Engine (NAE) scripts for monitoring and correlation

Perform packet capture on Aruba infrastructure locally and using Central

Analyze endpoint classification data to identify risk

Analyze endpoint classification data on CPDI

1.5% Investigate Explain CPDI capabilities for showing network conversations on supported Aruba devices

Advice to help you take this exam

Complete the training and review all course materials and documents before you take the exam.

Exam items are based on expected knowledge acquired from job experience, an expected level of industry-standard knowledge, and possibly other prerequisites (events, supplemental materials, etc.).

Successful completion of the course alone does not ensure you will pass the exam.

Read this HPE Exam Preparation Guide and follow its recommendations.

Visit HPE Press for additional reference materials, study guides, practice tests, and HPE books.

Practice exam items

An AOS-CX switch implements an access control list (ACL). You want to track trends in the number of hits against certain deny rules in that list and receive alerts if the hits pass a threshold. Which can you do to support this use case? Set up interim RADIUS accounting to ClearPass Policy Manager (CPPM) and enable Insight on CPPM.

Discover the switch as a NAS in ClearPass Device Insight (CPDI) and use CPDI’s Network Activity views.

Deploy a Network Analytics Engine (NAE) agent to monitor the ACL hits.

Manage the switch in Central and use Central’s show command tool to view ACL hits.

Refer to the exhibit in Figure 20-1.

Figure 20-1: Item 2 exhibit

You set up this EAP-TLS authentication method on CPPM. You then select that method as the only authentication method in a service. How will CPPM validate client certificates?

Instead of checking the CA signature to validate the certificate, CPPM checks whether the certificate’s serial number is in its OCSP database.

In addition to validating the certificate’s signature, CPPM queries the OCSP URL in the certificate about the certificate’s status.

CPPM will trust any certificate that is considered valid by CPPM’s OCSP server, regardless of whether the certificate’s CA is in CPPM’s Trusted CA list.

In addition to validating the certificate’s signature, CPPM checks whether the certificate serial number is on a CRL list, which it downloads using OCSP.

You intend to schedule periodic subnet scans on ClearPass Policy Manager (CPPM) to actively scan Windows domain clients. What should you do to ensure that CPPM can scan these devices correctly? On CPPM, map the domain clients’ subnets to WMI accounts for accessing the clients.

Configure the domain client firewalls to permit NetFlow traffic in and out of the devices.

Enable periodic polling in the CPPM network device entries for the APs and switches to which the clients connect.

Run a one-time discovery scan with the ARP polling option enabled.

A company has Aruba APs, which are managed by Aruba Central and authenticate clients on a corporate SSID to Aruba ClearPass Policy Manager (CPPM). The company wants to use ClearPass Onboard to issue certificates to employees’ Bring Your Own Device (BYOD) devices. You have set up a new onboarding SSID on your APs to permit users to access Onboard. What security settings should you configure on the new SSID? Open or PSK security and captive portal redirect to the Onboard portal

Enterprise security and 802.1X authentication to CPPM, which redirects clients to Onboard

Enterprise security and 802.1X authentication to Onboard

Open security and MAC-based authentication to Onboard

A company has an AOS 10 architecture with Aruba APs and Aruba gateways. The APs implement WIDS/WIPS. You want a fast way to find out if the APs detect a rogue AP or other wireless threat, even if they do so outside of normal business hours. What should you do? Use Syslog to integrate the APs with ClearPass Policy Manager (CPPM) ingress event engine.

Use Aruba Network Analytics Engine (NAE) to monitor for WIDS/WIPS events.

Configure the APs to tunnel traffic to gateways, and set up alerts from the gateways’ Threat Dashboard.

Set up email notifications using Central’s global alert settings.

Refer to the exhibit in Figure 20-2.

Figure 20-2: Item 6 exhibit

A company’s AOS-CX switches enforce manager authentication using TACACS+ to ClearPass Policy Manager (CPPM). One of the TACACS+ enforcement profiles to which CPPM assigns managers is named “SwitchAdmins1” and is shown in Figure 20-2.

You have been instructed to configure a list of permitted and denied commands for managers assigned to this profile. However, you cannot find the Commands tab in the profile. What should you do?

Enable TACACS+ command authorization in the CPPM server’s TACACS+ settings.

Change the SwitchAdmins1 profile Priv-Lvl to 15.

Add the Shell service to the SwitchAdmins1 profile.

Change the Aruba-Admin-Role VSA in the SwitchAdmins1 profile to “administrators.”

You are setting up the Gateway IDS/IPS features on Aruba 9x00 gateways. The company wants to use IDS mode, and you need to set the IDS policy. What is the main difference between the moderate and strict policies? The moderate policy causes the gateway to detect threats but let all traffic pass, while the strict policy causes the gateway to detect threats and drop the threats.

The moderate policy and strict policy both cause the gateway to detect threats, but let all traffic pass. But the strict policy matches traffic against a larger ruleset that includes less severe threats.

The moderate policy and strict policy both cause the gateway to detect threats, but let all traffic pass. But the strict policy causes the gateway to drop traffic if the IDPS engine goes down.

The moderate policy causes the gateway to detect threats in WAN and Internet traffic, while the strict policy causes the gateway to detect threats in WAN, Internet, and LAN traffic.

A company has AOS-CX switches and Aruba ClearPass Policy Manager (CPPM). The company wants switches to implement 802.1X authentication to CPPM and download user roles. What is one task that you must complete on the switches to support this use case? Install the root CA certificate for CPPM’s HTTPS certificate in a TA profile.

Specify CPPM as the RADIUS server with the exact CN in CPPM’s RADIUS/EAP certificate.

Specify a clearpass username and password that match credentials in the AD server with which CPPM communicates.

Configure empty user-roles with names that match role names on CPPM.

In an Aruba Central 2.5.4 SD-Branch solution, how are the keys, algorithms, and Security Parameter Index (SPI) established for IPsec security associations (SAs)? The gateways in the SA use IKEv1 to negotiate these settings.

The gateways in the SA use ESP to negotiate these settings.

Admins configure these settings manually and apply them to appropriate gateways or gateway groups in Central.

Central SD-WAN Orchestrator establishes these settings and automatically pushes them to the correct gateways.

Which is a use case for using device auth-mode on an AOS-CX switch? To enable the switch to authenticate multiple downstream clients that connect to it through an unmanaged, non-EAP capable switch

To enable the switch to authenticate a client and VoIP phone, which uses tagging, on the same port

To enable the switch to authenticate an AP, but not the wireless clients connected to that AP

To enable the switch to implement both MAC-Auth and 802.1X on the same port

Refer to the exhibit in Figure 20-3.

Figure 20-3: Item 11 exhibit

What can you interpret from the packets that you see?

10.1.10.5 is likely running a UDP sweep to detect active devices in the network.

10.1.10.5 is likely attempting to launch a denial of service (DoS) attack using UDP packets.

10.1.10.5 is likely attempting to implement a man-in-the-middle (MitM) attack against devices in the 10.1.10/24 subnet.

10.1.10.5 is likely attempting to gain unauthorized Ethernet access using UDP tunneling.

You are configuring the Device Insight Integration settings on ClearPass Policy Manager (CPPM). For which use case should you set the “Tag Updates Action” to “apply for selected tag updates?” You want to minimize traffic between CPDI and CPPM by configuring CPDI to inform CPPM only about specific tags.

You use some Device Insight tags in enforcement policies, but other tags are only informational, and you want to minimize device disruption.

You have a ClearPass cluster with servers at multiple sites; you want to minimize unnecessary traffic between the sites.

You are using both CPPM and CPDI to collect device profile information; you want to control precisely which information the solutions exchange.

You are configuring an AOS-CX switch to implement user-based tunneling (UBT) to an Aruba gateway. Only untagged traffic is required to pass over the tunnels. Admins are configuring VLAN assignments for wired clients in roles on the gateway. What should you configure on the switch to work with these requirements? Configure UBT in VLAN extend mode.

Configure the default UBT mode and set an unused VLAN as the UBT client VLAN.

Configure the switch to download roles from the gateway.

Configure VXLAN and associated VNIs on the switch.

Refer to the exhibit in Figure 20-4.

Figure 20-4: Item 14 exhibit

You have configured an Aruba Downloadable Role enforcement profile on Aruba ClearPass Policy Manager (CPPM). As shown in Figure 20-4, this role implements tunneling between AOS-CX switches and Aruba gateways. You also configured an enforcement policy to output this profile; that policy is used by a service that authenticates clients on the AOS-CX switches. What is one step that you must complete on network infrastructure devices to ensure that clients assigned to this profile can forward traffic correctly?

Configure a user-role named “limitedaccess-tunneled” on the AOS-CX switches.

Configure a user-role named “limitedaccess-wired” on the AOS-CX switches.

Configure a role named “limitedaccess-wired” on the gateways.

Configure a gateway zone named “gateway1” on the gateways.

You need to obtain a Certification Authority (CA)-signed certificate for some Aruba APs, which are managed by Aruba Central. You used this command to create a certificate signing request (CSR): openssl req -new -out file1.pem -newkey rsa:3072 -keyout file2.pem The intermediate CA returns the signed certificate in a file named file3.pem. What should you include in the PEM file that you upload to Central?

The contents of file 3 and the intermediate CA certificate only

The contents of file 1, file 2, and file 3

The contents of file2, file3, and the intermediate CA certificate

The contents of file 3 only

For which AOS-CX feature can you help prevent traffic disruption by saving IP-to-MAC bindings to external storage? User-based tunneling (UBT)

Virtual network based tunneling (VNBT)

MAC authentication

ARP inspection

A company has Aruba APs that are controlled by Central and that implement WIDS. When you check WIDS events, you see a “detect ad hoc with valid SSID” event. What can you interpret from this event, and what steps should you take? Devices operating at default settings often create ad hoc networks, so this event is likely to be a false positive. You should turn off detection for this threat type.

Hackers or users are likely trying to introduce an unauthorized device. You should use the detecting radio information and immediately track down the device that triggered the event.

Clients are likely bridging traffic across multiple wireless NICs; you need to work with client admins to adjust these settings.

The company likely has some third-party APs; you should add them to the authorized radios list manually.

The following ArubaOS firewall role is configured on Central-managed Aruba APs: wlan access-rule employees

 index 3

 rule any any match 17 67 67 permit

 rule any any match any 53 53 permit

 rule 10.2.2.0 255.255.255.240 match any any any deny

 rule 10.2.2.0 255.255.255.0 match 6 80 80 permit

 rule 10.2.2.0 255.255.255.0 match 6 443 443 permit

 rule 10.2.0.0 255.255.0.0 match any any any deny

 rule any any match any any any permit

A client has authenticated and been assigned to the “employees” role. The client has IP address 10.2.4.4. Which correctly describes behavior in this policy?

HTTPS traffic from 10.2.2.30 in an active session between 10.2.2.30 and 10.2.4.4 is denied.

HTTPS traffic from 10.2.4.4 to 10.2.2.6 is denied.

HTTPS traffic from 10.2.4.4 to 203.0.113.12 is denied.

HTTPS Traffic from 198.51.100.12 in an active session between 10.2.4.4 and 198.51.100.12 is denied.

Refer to the exhibits in Figures 20-5, 20-6, and 20-7.

Figure 20-5: Item 19 exhibit 1

Figure 20-6: Item 19 exhibit 2

Figure 20-7: Item 19 exhibit 3

You have configured a ClearPass Policy Manager (CPPM) service as shown in the exhibits. What additional step should you take to ensure that some clients are not left at the wrong access level?

Enable role and posture caching in the enforcement settings.

Enable the Profiler in the general settings and then set the CoA action for profile changes.

Add another rule to the role mapping policy that outputs the [Machine Authenticated] role.

Disable username stripping in the authentication settings.

You have run an Active Endpoint Security Report on ClearPass. This report indicates hundreds of endpoints with MAC addresses but no known IP addresses. What is one step for addressing this issue? Import an XML file with the IP-to-MAC bindings to CPPM’s Endpoints Repository.

Configure CPPM to automatically update endpoint profiler dictionaries in the cluster-wide parameters.

On CPPM, set up periodic SNMP polling and reading the ARP table on network devices.

Add CPPM’s IP address to the IP helper list on routing switches.

In which order does Aruba ClearPass Device Insight (CPDI) apply classification methods to a discovered device? User rules, system rules, MAC range classifiers, LDA clustering

MAC range classifiers, system rules, LDA clustering, user rules

LDA clustering, user rules, system rules, MAC range classifiers

User rules, LDA clustering, system rules, MAC range classifiers

A company is using ClearPass Device Insight (CPDI) (the standalone application). In the CPDI security settings, Security Analysis is On, the Data Source is ClearPass Device Insight, and Enable Posture Assessment is On. You see that device has a Risk Score of 80. What can you know from this information?

The device has an unhealthy posture, but CPDI has not detected any vulnerabilities on it.

The device has a healthy posture; the risk score derives entirely from detected vulnerabilities.

The device does not have a healthy posture, and CPDI has also detected at least one vulnerability on it.

The device has an unknown posture, and CPDI has detected exactly 30 vulnerabilities on it.

A company has Aruba APs (AOS 10), which authenticate clients to Aruba ClearPass Policy Manager (CPPM). CPPM has some policies which apply [ArubaOS Wireless - Terminate Session] enforcement profiles. What else should you set up on CPPM to ensure that those profiles take effect? Set the CoA delay to 0 in the CPPM server’s RADIUS server settings.

Enable interim accounting processing in CPPM’s general server settings.

Enable RadSec in the network device entries for the APs.

Enable Dynamic Authorization in the network device entries for the APs.

A company has an AOS 8-based mobility architecture with mobility controllers (MCs) and Aruba Campus APs (CAPs). The security team wants you to capture traffic from a particular wireless client, which is connected to AP 1. This AP is controlled by MC 1 and connects to AOS-CX switch 1. You should direct this wireless client’s traffic to the security team’s machine for further analysis for potential security threats. What should you do to meet these requirements? Access the CLI for AP 1. Set up a remote mirroring session between its Ethernet port and the security team’s machine.

Access the CLI for switch 1. Set up a remote mirroring session between AP 1’s port and the security team’s machine.

Access the CLI for MC 1. Set the datapath capture destination to the security team’s machine; then start a datapath capture with the client’s MAC address.

Access the CLI for MC 1. Set the controlplane capture destination to the security team’s machine; then start a controlplane capture with the client’s IP address.

A company wants Aruba ClearPass Policy Manager (CPPM) to respond to Syslog messages from the company’s Palo Alto Next Generation Firewall (NGFW). You have added the firewall as an event source and set up an event service. However, test Syslog messages are not triggering the expected actions. What is one CPPM setting that you should check? You have enabled all default device fingerprints on CPPM.

The Palo Alto Extension is installed through ClearPass Guest.

The Palo Alto NGFW is configured as a Syslog server on CPPM.

Insight and ingress event processing are enabled on the CPPM server.

On Aruba ClearPass Policy Manager (CPPM), you have configured a posture policy that uses the ClearPass OnGuard agent. This policy has rules for assigning clients to the Healthy and Quarantine postures. How do you configure CPPM to respond to agents’ reports and assign the correct postures to clients? Configure a Web-based Heath Check Service that references the posture policy.

Configure a RADIUS Enforcement Policy that uses the Healthy and Quarantine postures in rules.

Install an OnGuard extension from the ClearPass Guest Administration page.

Enable caching roles and postures in the CPPM service to which clients authenticate.

You are setting up an Aruba VIA solution for a company. The customer wants employees to download their VIA connection profile from the VPNC, and you have created that connection profile. You have also set up VIA Web authentication. During tests, you can successfully contact the VPNC with the VIA client and log in. However, you are then told that no connection profile is available for you. What is one setting to check?

That you have mapped the VIA connection profile to the public IP addresses from which VIA clients connect

That you have specified the public IP addresses from which VIA clients connect as tunneled networks in the VIA connection profile

That the VPNC firewall role to which clients are assigned during Web authentication references the VIA connection profile

That you have attached the VIA connection profile to the VPNC’s Internet interface as an L2 AAA profile

You have already deployed a virtual Data Collector on a VMware ESXi host for use with Aruba ClearPass Device Insight (CPDI). You now need this Data Collector to collect flow information about client’s network behavior. You will configure core routing switches to mirror traffic to the ESXi host’s NICs 3 and 4, which are owned by virtual switch 2. What should you tell virtual network admins to do? Connect the Data Collector’s adapter with the third lowest MAC address to virtual switch 2 in VLAN 4095.

Connect the Data Collector’s adapter with the lowest MAC address to virtual switch 2 in VLAN 0.

Connect the Data Collector’s adapter with the highest port ID to virtual switch 2 in VLAN 4095.

Connect the Data Collector’s adapter with the lowest port ID to virtual switch 2 in VLAN 0.

Refer to Figures 20-8 and 20-9.

Figure 20-8: Item 29 exhibit 1

Figure 20-9: Item 29 exhibit 2

ClearPass Policy Manager (CPPM) has a custom attribute for AD that uses AccountStatus alias for userAccountControl. Which enforcement profile does CPPM apply to a client that meets both these conditions:

Succeeds in authenticating as a user, but to a disabled AD user account (userAccountControl value 66050)

Succeeds at authenticating as a computer profile1

profile2

profile3

Deny Access profile

A company has Aruba APs that connect to AOS-CX switches. The APs need to authenticate as 802.1X supplicants to Aruba ClearPass Policy Manager (CPPM). The company wants to use the Device (TPM) certificates for this purpose, as well as check that APs’ MAC addresses are known in CPPM’s Endpoints Repository. What is one recommended setting on CPPM? Implement EAP-TEAP for the authentication method with both EAP-TLS and MAC-Auth as inner methods.

Install each APs’ TPM certificate to CPPM’s Certificate Trust List with the Aruba Infrastructure usage.

Use the HPE-User-Role VSA to send the APs’ role name to the AOS-CX switches.

Enable the Aruba Networks Trusted Computing Root CA and add the EAP usage.

Explanations

C is correct. NAE can monitor a broad range of information on AOS-CX switches. An NAE script can define monitors that check the hit count on ACL rules; it can also define actions such as triggering an alert when a particular threshold is passed. (You could check whether such a script is available in ASE, and, if not, your company could develop the script in house.) You can then deploy an NAE agent from the script. You will then receive alerts and can track hitcounts in the switch’s Analytics Dashboard. A is incorrect. Switches do not report ACL hitcounts in RADIUS accounting messages. Instead they report information about RADIUS-authenticated clients such as IP address and bandwidth utilization.

B is incorrect. CPDI’s Network Activity view for a client shows that client’s network conversations based on flow information, not ACL hits.

D is incorrect. If you manage the switch in Central, you could use the show command tool to view ACL hits on the switch. However, this action does not meet all the criteria in the use case, including getting alerts when a threshold is passed.

For more information on this topic, refer to Chapter 9.

B is correct. Enabling OCSP tells CPPM to use Online Certificate Status Protocol (OCSP) to query a server about the status of the certificate. The certificate includes an OCSP URL, which tells CPPM where to send this query. The OCSP check is in addition to all of the typical checks of certificate validity. A and C are incorrect. When using OCSP, CPPM still needs to validate that the certificate is signed by a CA that is in CPPM’s trusted CA list with the EAP Usage. (In addition, CPPM does not have an OSCP database; it queries an OCSP server.)

D is incorrect. Using OCSP is an alternative to using CRLs. Using CRLs requires a device to download an entire list and check that a certificate’s serial number is not on that list. But with OCSP the client (such as CPPM) queries the server about just the serial number in question.

For more information on this topic, refer to Chapters 2 and 3.

A is correct. To run an active scan properly, CPPM needs at least one external account mapped to the subnet or subnets being scanned. These accounts dictate which protocols and associated credentials to use during the scan. WMI is a good protocol for scanning Windows domain clients. B is incorrect. CPPM does not use NetFlow for active scans.

C is incorrect. Enabling periodic polls in a CPPM network device entry lets CPPM poll that network device itself, not the clients connected to it.

D is incorrect. You can run a discovery scan before running subnet scans, but it is not required.

A is correct. Aruba generally recommends using a separate SSID for onboarding BYOD devices. The onboarding SSID should use open or PSK security; however, PSK is recommend for greater security. Then the devices can connect without needing to trust any ClearPass certificates in advance, and they can easily switch to a more secure WPA3-Enterprise SSID after being provisioned by Onboard. The onboarding SSID must redirect clients to the Onboard portal so that users can provision their devices. Note that the Onboard portal should enable Prevent CNA to bypass CNAs (configured in the Provisioning Profile Web Login settings). B is incorrect. CPPM does not receive clients’ traffic; network devices such as APs must redirect clients. Also enterprise security is less recommended for the onboarding SSID. Users will move to a more secure SSID that uses enterprise (802.1X) security after onboarding.

C and D are incorrect. Onboard is not an authentication server.

For more information on this topic, refer to Chapter 3.

D is correct. AOS 10 APs (and AOS 10 gateways) are managed in Central. Central alerts include ones related to WIDS/WIPS events such as rogue AP detection, infrastructure threat detection, and client threat detection. You can enable these alerts in Central’s global alert settings and set up email notifications for when these alerts trigger. These actions meet the scenario’s requirements of informing you quickly when WIDS/WIPS events occur. A is incorrect. In theory, it is possible to configure APs to send Syslog messages to CPPM and to configure CPPM’s ingress event engine to process those messages (however, doing so would require creating custom event dictionaries, which is an expert topic). However, these actions would not fulfill the requirements of this scenario, which is to make admins aware of threats more quickly.

B is incorrect. NAE can help alert admins to events and issues on AOS-CX switches.

C is incorrect for several reasons. The APs are responsible for running the WIDS/WIPS feature regardless of whether they bridge wireless traffic or tunnel it. The gateway’s Threat Dashboard relates to gateway IDS/IPS, not WIDS/WIPS. (Also note that you do not set up gateway IDS/IPS alerts directly from the dashboard. Instead you can set those alerts up from Central’s global alert settings, much like you do the AP alerts.)

For more information on this topic, refer to Chapter 19.

C is correct. Adding the Shell service makes the Commands tab appear; you can then configure the permitted and denied commands in that tab. A is incorrect. You do not need to enable authorizing commands globally.

B and D are incorrect. These actions relate to changing the group to which the switch assigns the manager. (In more detail, the Aruba-Admin-Role VSA takes precedence over the TACACS+ privilege level.) These actions do not add the Commands tab. You are allowed to configure commands for managers assigned to any group on the AOS-CX switches.

For more information on this topic, refer to Chapter 6.

B is correct. When the gateway acts in IDS mode, it detects threats but lets all traffic pass. The difference between IDS policies lies in the number of rules against which the gateway matches traffic. The strict ruleset is larger and includes less severe threats. (In more detail, the strict policy includes threats with CVSS 4 and higher from the current and previous 3 years, while the moderate policy only includes threats with CVSS 6 and higher from the current and previous 2 years.) A is incorrect. In IDS mode, the gateways detect threats, but let all traffic pass, regardless of policy.

C is incorrect. It is the fail strategy that dictates whether the gateway drops traffic if its IDPS engine goes down. You can choose either the bypass or block fail strategy with any IDS policy.

D is incorrect. The gateways detect threats in WAN, Internet, and LAN traffic when using any of the IDS (or IPS) policies.

For more information on this topic, refer to Chapter 18.

A is correct. To download the downloadable user-roles (DURs), the switch must trust CPPM’s HTTPS certificate. This trust includes having a TA profile with the root CA certificate for the CA that issued CPPM’s HTTPS certificate. B is incorrect. The switch should specify CPPM as the RADIUS server with the exact name in the CN of CPPM’s HTTPS certificate, not RADIUS/EAP certificate.

C is incorrect. You must specify a clearpass username and password on the switch, but the credentials must match an admin account on CPPM. That admin account should have the Aruba User Role Download privilege level.

D is incorrect. When the switch is downloading roles, it does not need user-roles configured locally in advance.

For more information on this topic, refer to Chapter 7.

D is correct. Central SD-WAN Orchestrator is responsible for creating the SAs and securely distributing the information to the gateways in that SA. A is incorrect. IKE is a protocol for negotiating IPsec SAs, which Aruba VIA clients and Aruba VPNCs use for client-to-site VPNs. However, in the latest versions of Central, Aruba SD-Branch (site-to-site) VPNs, gateways do not need to use IKE to negotiate the SAs. The Central SD-WAN Orchestrator handles the SA establishment itself.

B is incorrect. ESP does not provide negotiation for IPsec SAs.

C is incorrect. With Aruba SD-Branch, admins do not configure keys and SPIs for SAs manually.

For more information on this topic, refer to Chapter 17.

C is correct. Device auth-mode tells the switch to authenticate the first MAC address on the port and then to permit all traffic, regardless of MAC address. This mode lets the switch authenticate the AP, but then permits traffic that the AP bridges from clients to flow freely. (Presumably the AP has already authenticated those clients.) A and B are incorrect. In these scenarios, you want the switch to authenticate each MAC address on the port separately. Client auth-mode acts in this way.

D is incorrect. The switch can implement both MAC-Auth and 802.1X in device auth-mode, but it can also do so in client auth-mode. The need to implement both methods is not a specific reason for enabling device auth-mode.

For more information on this topic, refer to Chapter 7.

A is correct. These packets show several signs of a sweep. One IP address, here 10.1.10.5, is rapidly contacting many other IP addresses within a range. This indicates that 10.1.10.5 is trying to reconnoiter the network and discover which IP addresses are active. This particular sweep is called a UDP sweep because it uses UDP packets to an uncommonly used port. Active devices will send an ICMP unreachable packet because the port is closed. B and C are incorrect. While 10.1.10.5 might move on from reconnaissance to launching other attacks later, these particular packets are not associated with DoS or MitM attacks.

D is incorrect. UDP tunneling is not a way to obtain unauthorized Ethernet access. This device already has access to the network, and its user is trying to discover more information.

For more information on this topic, refer to Chapter 16.

B is correct. The “Tag Updates Action” setting tells CPPM whether to issue a CoA when a change occurs to a client’s Device Insight tags. The “apply for selected tag updates” option lets you choose precisely which tags’ updates trigger the CoA. You can then select tags that you reference in enforcement policies to trigger CoAs, but leave informational only tags off the list. This approach minimizes device disruption. A is incorrect. CPDI informs CPPM about all tags that apply to devices, regardless of the “Tag Updates Action.”

C is incorrect. The tag information propagates across the cluster, regardless of the “Tag Updates Action.”

D is incorrect. The “Tag Updates Action” does not control information exchanged between CPPM and CPDI. (Note that this exam focuses on CPPM 6.9, which disables profiling on CPPM when CPPM is integrated with CPDI. In ClearPass 6.10 and later, it is possible to enable profiling on both CPPM and CPDI. However, the “Tag Updates Action” continues to have nothing to do with an exchange of information.)

For more information on this topic, refer to Chapter 15.

B is correct. When an AOS-CX switch operates in reserved VLAN mode for UBT, you configure clients’ VLAN assignments in the clients’ role on the gateway. You do not have to configure matching assignments in the roles on the switch. To enable this mode, you simply configure a VLAN, not used for any other purpose, as the UBT client VLAN on the switch. A is incorrect. When you use VLAN extend mode, you must configure matching VLAN assignments for clients on both the gateway and the switches.

C is incorrect. Switches download user-roles from Aruba ClearPass Policy Manager (CPPM), not from gateways.

D is incorrect. AOS-CX switches use VXLAN with VNBT, not with UBT.

For more information on this topic, refer to Chapter 8.

C is correct. The gateway role must match a role that is configured on the Aruba gateways that terminate the tunnels. The gateways use that role to apply settings to clients’ traffic. A and B are incorrect. The enforcement profile shows a DUR, which the switch downloads from CPPM. The switches do not require any user-role settings pre-configured on it for them to download this DUR.

D is incorrect. The switches need a gateway zone named “gateway1” configured on them. However, the gateways simply terminate the tunnel from switches that contact them, and you do not need to configure a zone on the gateways for this purpose.

For more information on this topic, refer to Chapter 8.

C is correct. The APs need to use this certificate as their own, which means that they need the private key. The PEM file should include the private key associated with the certificate (file 2) and the signed certificate (file 3). It should also include the intermediate CA certificate; when APs submit their certificate to another entity, they need to include the intermediate CA certificate as part of the chain of trust. A and D are incorrect because the file must include the private key.

B is incorrect because the file does not need to include the CSR and should include the intermediate CA certificate.

For more information on this topic, refer to Chapter 2.

D is correct. When a switch implements ARP inspection, it checks ARP replies and only lets them pass if the MAC address that claims a particular IP address actually does own that IP address. The switch uses its IP-to-MAC binding table for this check, and typically it builds this table over time using DHCP snooping. If the switch reboots, it has not yet had time to rebuild the table, which can cause disruptions. Saving the table to external storage lets the switch obtain the table more quickly after a reboot (as often clients try to use the same addresses that they had before). A, B, and C are incorrect. These features do not rely on the IP-to-MAC binding table.

For more information on this topic, refer to Chapter 6.

B is correct. If someone has set up an adhoc network that uses one of the company’s SSIDs, that person is likely deliberately trying to hide the network or lure users to connect to it for malicious purposes. A is incorrect. It is true that some devices create ad hoc networks without users’ awareness, so merely seeing that WIDS has detected an ad hoc network does not necessarily indicate a threat. However, this ad hoc network specifically has the company’s SSID. That fact can indicate malicious intent, and you should follow up to learn more.

C is incorrect. Bridging traffic across interfaces would not look like an ad hoc network.

D is incorrect. Third-party APs would not advertise SSIDs in ad hoc mode.

For more information on this topic, refer to Chapter 10.

B is correct. HTTPS traffic from 10.2.4.4 to 10.2.2.6 first hits rule 3 in the list (10.2.2.0 255.255.255.240 match any any any deny). For the source, AP firewall rules implicitly use the IP addresses of clients assigned to the role (wlan access-rule) in question. Therefore, 10.2.2.0 255.255.255.240 refers to the destination. The 10.2.2.6 IP address falls within the specific range (10.2.2.0-10.2.2.15). All traffic to these IP addresses is denied. A is incorrect. The ArubaOS firewall is stateful, so it always permits return traffic for active sessions. The client is permitted to send traffic to 10.2.2.30 by rule 5 (the first match), and 10.2.2.30 can also send traffic back. Note that this traffic does not match rule 3, which only applies to destinations 10.2.2.0-10.2.2.15.

C is incorrect. This traffic is permitted by the final rule in the list, which is the first match. Note that this traffic does not match rule 6 because 10.2.0.0 255.255.0.0 in that rule refers to the destination.

D is incorrect. The ArubaOS firewall is stateful. The client is permitted to send traffic to 198.51.100.12 by the final rule in the list, and return traffic from 198.51.100.12 is permitted.

For more information on this topic, refer to Chapter 4.

B is correct. This service is authenticating clients with 802.1X and specifically EAP-TLS. The role mapping and enforcement policy show that CPPM is using device category, as well as other context, to assign enforcement profiles to authenticated devices. When a device connects for the first time, CPPM will not know its device category, so it will assign the “profiling” role and, for BYOD devices, the “dhcp-only” enforcement profile. But after CPPM learns the device category, it should move the client to a new role and enforcement profile. The Profiler setting is required for this purpose. After enabling this setting, you must set the CoA action. Then CPPM can tell network devices to reauthenticate profiled clients, and the clients can receive the correct access level. A is incorrect. In this scenario, CPPM is not using posture in policy rules, and it does not need to cache posture or roles from earlier connections.

C is incorrect. CPPM automatically assigns the [Machine Authenticated] role to any client that authenticates to a computer account on AD. You do not need to configure a role mapping rule for CPPM to do so.

D is incorrect. Username stripping is often used with the EAP-TLS method.

For more information, refer to Chapter 12 and also to Chapter 3.

C is correct. CPPM can use network devices’ ARP tables to find out which IP address is associated with each MAC address. (It can also use interim RADIUS accounting messages for this purpose). To enable CPPM to discover this information, you can configure it with SNMP credentials for network devices, set up periodic SNMP polling of those network devices, and also enable reading the ARP table from the device. A is incorrect. You cannot import the IP addresses in an XML file.

B is incorrect. Updating the endpoint profile dictionaries gives CPPM new device fingerprints so that it can better determine the device category, family, and name for each endpoint. However, these dictionaries do not help CPPM figure out the devices’ IP addresses.

D is incorrect. Adding CPPM’s IP address to the IP helper list on routing switches is very important for helping CPPM receive DHCP Discover messages and profile endpoints. However, it does not specifically help CPPM figure out the devices’ IP addresses (as CPPM does not receive the DHCP Offers).

For more information on this topic, refer to Chapter 12.

A is correct. CPDI always applies user rules first. If it does not find a match, then it applies system rules. If it still does not find a match, it uses MAC range classifiers. Finally, it uses machine learning-based LDA clustering to group together the “generic” unclassified devices, as well as look for recommendations based on similarities to classified devices. B, C, and D are incorrect because they indicate the wrong order.

For more information on this topic, refer to Chapter 13.

C is correct. The posture contributes up to 30 points to the risk score. Because the risk score is greater than 30, you know that CPDI has detected at least one vulnerability. The vulnerability contributes up to 70 points. With a risk score of 80, you know that the posture score is 10 or more. So the client might have an unknown posture (15 points toward the risk score) or an unhealthy posture (30 points toward the risk score), but not healthy. A is incorrect. The posture contributes up to 30 points to the risk score. Because the risk score is greater than 30, you know that CPDI has detected at least one vulnerability.

B is incorrect. The vulnerability contributes up to 70 points. With a risk score of 80, you know that the risk score contributed by the client posture is more than 0. So the client cannot be healthy.

D is incorrect. The posture might be unknown (or unhealthy). But the vulnerability score does not come from the number of vulnerabilities detected. Instead it derives from the vulnerabilities’ CVE scores.

For more information on this topic, refer to Chapter 14.

D is correct. The [ArubaOS Wireless - Terminate Session] profile tells CPPM to issue a Change of Authorization (CoA) message. Dynamic Authorization must be enabled in the APs’ network device entries for CPPM to send CoAs to the APs. A is incorrect. The CoA delay tells the CPPM server how long to wait before sending the CoA message; however, it will not send the CoA to a network device at all unless Dynamic Authorization is enabled for that device.

B is incorrect. Enabling interim accounting processing lets CPPM process interim accounting messages sent by network devices to it. Processing these messages is not required for CPPM to send CoAs.

C is also incorrect. Enabling RadSec between CPPM and a network device tells the devices to set up a secure TLS session for RADIUS messages; it does not affect whether or not CPPM can send CoAs to the network device.

For more information on this topic, refer to Chapter 1.

C is correct. You can capture a particular client’s traffic as it passes through the MC datapath, based on the client MAC address. You can set the destination for the capture to a remote IP address, such as the security team’s machine, as specified in this scenario. A is incorrect. The APs in this scenario are controlled by an MC, and you do not manage them through their CLI. Also capturing traffic at the AP’s Ethernet port would not be the best approach because that would include a lot of packets non-related to the client in question—and the packets would still be encrypted.

B is incorrect. Capturing the traffic at the switch port that connects to the AP would capture a lot of irrelevant traffic. Also the wireless client’s packets would still be encrypted.

D is incorrect. A controlplane capture on the MC captures the packets that are destined to the MC itself, not all the packets from clients that flow through it. (Also you cannot set the controlplane capture destination to a remote IP.)

For more information on this topic, refer to Chapter 16.

D is correct. In addition to the steps outlined in the question, you must make sure ingress event processing is enabled on the CPPM server. You should also enable Insight to ensure that CPPM can properly process events and correlate an IP address of an attacker with a client MAC address. A is incorrect. Device fingerprint dictionaries are not associated with ingress event processing. Event dictionaries are, and you should enable the correct one for the Palo Alto NFGW’s Syslog messages.

B is incorrect. You do not need to install an extension for the ingress event processing capabilities to work.

C is incorrect. The Palo Alto NGFW acts as a Syslog client, not server, for this scenario. To process the messages, CPPM must define the NGFW as an event source, have ingress event processing enabled, and have the correct event dictionary enabled.

For more information on this topic, refer to Chapter 11.

A is correct. The Web-based Health Check Service processes SHV reports from OnGuard agents. It uses the plugin checks and rules in the referenced posture policy to assign the correct posture to clients. B and D are incorrect. You might want to complete both of these steps to use postures assigned to clients to control their access. However, these steps do not help assign the posture to clients, which is the task about which the question asks.

C is incorrect. CPPM does not use an OnGuard extension to enable the OnGuard features.

For more information on this topic, refer to Chapter 5.

C is correct. When a client succeeds at VIA Web authentication, the VPNC assigns it to a role. (For example, if CPPM is the authentication server, CPPM could send an Aruba-User-Role VSA.) You specify the VIA connection profile in this role’s settings to tell the VPNC to offer it to clients that log in and receive that role. A is incorrect. You do not map VIA connection profiles to subnets.

B is incorrect. The tunneled networks in a VIA connection profile are used when the profile enables split tunneling. With split tunneling the VIA client sends some traffic over the established VPN tunnel to the VPNC and forwards other traffic locally. The tunneled networks setting tells the client which traffic to tunnel. This setting does not relate to downloading the connection profile itself.

D is incorrect. VIA connection profiles are not L2 AAA profiles.

For more information on this topic, refer to Chapter 17.

A is correct. To collect the flow attributes and information about devices’ network activity and network behavior information, the virtual Data Collector needs to receive information on its SPAN port. Virtual Data Collectors have two SPAN adapters; one has the third lowest (second highest) MAC address, and one has the fourth lowest (highest) MAC address. On ESXi hosts, VLAN 4095 passes all traffic, tagged and untagged, which is the best way to send all the traffic mirrored by the core routing switches. B and D are incorrect because VLAN 0 passes untagged traffic only. B is also incorrect because the adapter with the adapter with the lowest MAC address is the Mgmt port, which the Data Collector uses to connect to Central.

C is incorrect because the port ID is not a reliable way to determine the virtual Data Collector adapter usage. Aruba recommends using the MAC address. (D is incorrect for this reason also.)

For more information on this topic, refer to Chapter 14.

B is correct. Based on the role mapping policy, clients that authenticate to a disabled AD user account receive role2. (The AccountStatus values in rule 2 indicate disabled accounts.) Clients that authenticate as computers always receive the [Machine Authenticated] role. That means that this client has two CPPM roles: role2 and [Machine Authenticated]. The first rule that this client matches in the enforcement profile is rule 2, so CPPM applies profile2. A and C are incorrect. The client does not have role 1, so these rules do not match. D is incorrect because the client does match a rule; therefore, the default enforcement profile does not apply.

For more information on this topic, refer to Chapter 3.

D is correct. Because the APs are authenticating with EAP-TLS (for certificate-based authentication), CPPM must validate the certificate signatures. The Aruba Networks Trusted Computing Root CA is the root CA for the APs’ TPM certificates. So you must enable this CA and add the EAP usage. A is incorrect for several reasons. APs do not support EAP-TEAP as an authentication method. Also MAC-Auth is not a valid inner method for EAP-TEAP. Although the scenario did state that CPPM should check the APs’ MAC addresses, as well as their certificates, MAC-Auth is not required for that purpose. Instead you can set up role mapping or enforcement policy rules to check that the APs are in the Endpoints Repository.

B is incorrect. You do not need to install every AP TPM certificate in CPPM’s Certificate Trust List. Enabling the root CA is sufficient. Also the correct usage is EAP for this use case, not Aruba Infrastructure.

C is incorrect. AOS-CX switches receive the role name for authenticated clients in the Aruba-User-Role VSA.

For more information on this topic, refer to Chapter 7 and also to Chapter 2.

Appendix: Answers to Learning Checks

Chapter 1

Learning checks

Which correctly describes Zero Trust Security? External clients are untrusted, while internal clients are trusted.

The perimeter is enhanced by a demilitarized zone (DMZ).

All users and devices are identified and controlled with granular identity- and context-based policies.

All users are considered equally untrustworthy and are given the same privileges regardless of identity.

Match the Aruba Zero Trust Security principles to the products that allow customers to act on those principles. c Visibility

b Authentication

a Role-based access control, enforcement and response, continuous monitoring Unified Infrastructure, Aruba 360 Security Exchange

ClearPass Onboard

CPDI

What role do service rules play within a CPPM service? Determining whether a user is permitted access

Selecting the preferred authentication method

Matching the incoming request to the correct service

Determining whether the NAD is authorized

What is a reason to use role mapping policies? Because role mapping policies simplify configuration by eliminating the need for enforcement profiles and policies

Because you want to characterize clients with a global policy that you can use in multiple services

Because you want to use more complex conditions which are not supported in enforcement policies

Because you want to define role-based firewall policies directly within CPPM

Chapter 2

Learning checks

What is required for a client to trust a web server’s certificate? (Select two.) The client has the certificate’s public key installed on it in advance.

The certificate was issued within the previous six months.

The client can trace the certificate back to a trusted root.

The certificate DNS SAN matches the hostname accessed by the client.

What is one requirement for joining a Subscriber to a ClearPass cluster? The Subscriber trusts the entire chain for the Publisher’s RADIUS/EAP certificate.

The Subscriber trusts the entire chain for the Publisher’s HTTPS certificate.

The Subscriber has an HTTPS certificate with its IP address listed as a DNS SAN.

The Publisher has an HTTPS certificate with its IP address listed as a DNS SAN.

What correctly describes the Device Certificate on Aruba APs? It is signed by an Aruba CA and installed in a TPM.

It is a self-signed certificate, which should be replaced in production.

It uses the AP’s default IP address as its CN in the subject name.

It is signed by a CA of the company’s choice and must be installed manually.

Chapter 3

Learning checks

A CPPM service uses the default [EAP-TLS] method for the authentication method and AD for the authentication source. What is required for a client to pass authentication? (Select two.) The client certificate is signed by a different CA from the one that signed CPPM’s RADIUS/EAP certificate.

The client certificate is signed by a CA in the CPPM trust list with the EAP usage.

The serial number for the client certificate is listed on a CRL.

The subject name in the client certificate matches an account in AD.

What function does the Onboard Pre-Auth service provide in the onboarding solution? It authenticates users who are using 802.1X to authenticate with certificates issued by Onboard.

It checks whether the user is attempting to onboard an authorized device type.

It checks the credentials that the user submits to the Onboard portal.

It authenticates users who are attempting to connect to an Onboard SSID.

A client has completed TEAP. It succeeded at TEAP Method 1 and failed at TEAP Method 2. What role does CPPM assign it? [Unauthenticated]

[Partial Authenticated]

[Machine Authenticated]

[User Authenticated]

Chapter 4

Learning checks

An ArubaOS device uses 802.1X to authenticate clients to ClearPass Policy Manager (CPPM). How does Aruba generally recommend you assign roles to clients that successfully authenticate? Using the authentication default method

Using server-derived rules

Using user-derived rules

Using the Aruba-User-Role VSA sent by CPPM

If a client attempts to access a particular subnet, the company wants to lock that client out of the network for a period. How can you enforce this action? Enable DPI and create an application rule that denies traffic sent to that subnet.

Enable WebCC and create an application rule that denies traffic sent to that subnet.

Create a firewall rule that denies traffic sent to that subnet and also applies denylisting (blacklisting).

Create a firewall rule that denies traffic sent to that subnet and also applies NAT.

Chapter 5

Learning checks

What is one difference between the OnGuard persistent agent and the dissolvable agent? The persistent agent only works for Windows systems while the dissolvable agent supports Windows and Linux.

The persistent agent supports ongoing monitoring while the dissolvable agent supports a one-time check.

The persistent agent integrates with Microsoft Intune while the dissolvable agent offers no integration.

The persistent agent posture overrides the posture delivered by any other source while the dissolvable agent posture is overridden by other sources.

Match the Component with its Role. b Posture policy

a WebAuth enforcement policy

c Web-based Health Check Only service Provides rules that assign enforcement profiles based on system posture

Provides SHV plugin configuration and rules for assigning posture based on SHV checks

Responds to requests from OnGuard agents

You have added an Intune extension, and now you need to configure it. How do you determine what to specify for the “tenantId,” “clientId,” and “clientSecret? You should always leave the default values for these fields.

You should consult with Aruba support to assess the right values for your environment.

You should register ClearPass as an App in Azure AD and collect the values there.

You should use XML files available in GitHub to look up the right values.

Chapter 6

Learning checks

What purpose does the “aaa authentication allow-fail-through” command serve on AOS-CX switches? It lets the switch authenticate users against the secondary method only if the primary method times out.

It lets the switch actively test whether a TACACS+ server is available.

It lets the switch allow users operator level access if their authentication fails.

It lets the switch authenticate users against the secondary method if the primary method rejects the user.

How does ARP inspection prevent MITM attacks? It discovers which IP and MAC addresses belong together.

It drops all ARP responses that arrive on untrusted ports.

It drops ARP responses on untrusted ports that do not match the IP-to-MAC table.

It stops clients from generating gratuitous ARP responses.

Chapter 7

Consideration answers

You should have answered that CPPM should be set up to send desired roles in an Aruba-CPPM-Role VSA. To download the role, the switch must be set up for DURs, as you learned earlier.

The switch-port should use “guest” for the auth and critical roles. It should use “unauthenticated” for the fallback role. The reject role should be set to a role that denies all access in order to prevent the fallback role from applying to rejected clients.

The “guest,” “unauthenticated,” and "denyall" roles need to be configured locally. The switch will dynamically download the roles for authenticated clients.

Learning checks

CPPM already acts as the authentication server for wireless 802.1X. Now the company wants to add wired 802.1X. Which CPPM components does Aruba generally recommend should be the same for wired and wireless 802.1X? (More than one answer might be correct.)

Service

Authentication source

Role mapping policy

Enforcement policy

How does a switch receive the configuration for a DUR? CPPM uses SSH to log into the switch and configure the DUR on it.

The switch uses HTTPS to retrieve the role configuration from CPPM.

Admins configure the DUR settings on the switch, and CPPM directs the switch which DUR to apply.

The switch uses SSH to contact an Aruba gateway and receive the DUR from it.

What is the significance of the following syntax on an AOS-CX switch? AOS-CX(config)# class ip NEW-CLASS

AOS-CX(config-class-ip)# 10 match tcp any

10.101.12.0/24 eq ssh

The switch will drop all traffic from any IP address destined for an address in 10.101.12.0/24

The switch now has a class that matches all SSH traffic from devices within 10.101.12.0/24

The switch now will permit all IP traffic destined for SSH ports on 10.101.12/24

The switch now has a class that matches all SSH traffic destined to addresses in 10.101.12.0/24

Chapter 8

Learning checks

How do you apply UBT to a client's traffic? (Select one.) Use the gateway zone setting in the role to which the client is assigned.

Enable the UBT (gateway) zone globally, which applies it to all clients’ traffic.

Apply the UBT zone to the client’s port.

Apply the UBT zone to the client’s VLAN.

How can VNBT help a company secure clients’ traffic? (Select one.) By tunneling the clients’ traffic to an Aruba gateway, which performs advanced security functions

By redirecting the clients’ traffic to a captive portal server, which authenticates the clients

By redirecting the clients’ traffic to a cloud security solution, which performs advanced security functions

By tunneling the clients’ traffic to a switch in the data center, which passes the traffic to an application-level firewall

Chapter 9

Learning checks

What functions does an NAE agent perform? (Multiple answers can be correct.) Collects data from the current state database and records it in a time-series database

Performs authorization control of management users

Allows you to virtualize legacy switch code within an AOS-CX switch

Triggers actions based on whether a monitored attribute meets a particular condition

Which correctly describes Aruba NAE scripts? All Aruba-certified scripts are loaded on the AOS-CX switch at factory defaults.

You can find Aruba-certified scripts in Aruba Solutions Exchange (ASE) and Github.

Aruba provides support for all NAE scripts, as long as the scripts use Python code.

You are only allowed to load Aruba-certified scripts on AOS-CX switches.

Chapter 10

Learning checks

What distinguishes a Rogue AP from an Interfering AP? A Rogue AP has launched a DoS attack.

A Rogue AP is connected to the corporate LAN.

A Rogue AP uses unauthorized security settings.

A Rogue AP is connected to Interfering clients.

What are some Aruba recommendations for IPS and IDS settings to enable? (Select two.) Enable all IDS settings.

Enable all IPS settings.

Enable IDS settings that are unlikely to produce false positives.

If automatic containment is required, enable rogue AP containment with wireless deauthentication.

If automatic containment is required, enable rogue AP containment with wired containment.

Chapter 11

Learning checks

What is an event source on CPPM? An MDM from which CPPM receives information about endpoint posture

A security appliance to which CPPM provides user information

A device from which CPPM will accept and process Syslog messages

An endpoint on which malware or another threat has been detected

What purpose does the Ingress Event Dictionary serve? It lists the valid event sources from which CPPM is allowed to process events.

It transforms Syslog content into an event with attributes that can be referenced.

It specifies the actions that CPPM should take in response to an event.

It defines the Syslog message that CPPM should send in response to specific requests.

Match the definition to the component. a Defines which attributes to update in the endpoint profile

c Processes events

b Defines the condition that triggers applying the post-authentication profile ClearPass Entity Update Enforcement profile

Event enforcement policy

Event service

Chapter 12

Answers to Consideration Questions

You should have provided answers similar to the following:

What is the difference between passive and active profiling? – Passive = CPPM discovers info about the endpoint without directly interacting with the endpoint (examples: DHCP, HTTP User-Agent, MAC OUI)

– Active = CPPM contacts the endpoint to collect info about it (examples: Nmap, WMI, SSH)

How can DHCP packets help CPPM determine the device type? Every OS has a unique way of ordering options in a DHCP Discovery packet, called a DHCP fingerprint. CPPM has a dictionary of these fingerprints, indicating which fingerprints go with which device types.

What useful information can CPPM find in clients’ HTTP/HTTPS traffic? HTTP User-Agent can help CPPM distinguish between devices with similar DHCP fingerprints. (If traffic is HTTPS, CPPM must be the server involved.)

Learning checks

How do you enable CPPM to receive device fingerprint updates from Aruba? Integrate CPPM with CPDI.

Integrate CPPM with Central.

Enable auto endpoint profiler fingerprint updates in the cluster-wide parameters.

Import an XML file from the Administration > Dictionaries > Device Fingerprints page.

What steps do you complete to scan endpoints with SSH? (Select two.) Define SSH credentials and map them to the endpoints’ subnet.

Run a Discovery scan on the network.

Run a periodic poll on the endpoints’ NADs.

Run a Subnet scan on the endpoints.

How can you create a custom device fingerprint on CPPM? Import the new device fingerprint from an XML file.

Create the new device fingerprint and then import rules from a discovered device.

Create the new device fingerprint and then define rules for it manually.

Import the new device fingerprint from a third-party solution.

You want to configure the profiling action for a CPPM service, but you do not see the Profiler tab. What should you do? Recreate the service, selecting a template that includes “Profiling” in the name.

In the Service tab, change the template to one that includes “Profiling” in the name.

In the Service tab, select the Profile Endpoints check box.

Add a rule that uses the “IsProfiled” attribute to a role mapping or enforcement policy.

In which of these circumstances does CPPM set an endpoint’s Conflict attribute to true? When the endpoint first connects before it is profiled

When the endpoint category changes from unknown to “Computer”

When the endpoint category changes from “Cameras” to “Computer”

When the endpoint has fingerprints that match multiple device fingerprint entries

Chapter 13

Learning checks

When CPDI applies LDA clustering to generic devices, how does it produce recommendations for the cluster classification? It sends the cluster to Aruba experts who make the recommendation.

It uses the MAC address ranges assigned to vendors by IEEE.

It looks for classified devices that exhibit similar attributes.

It uses system rules to create the recommendations.

Chapter 14

Learning checks

What port must be open between a CPDI Data Collector and Central? TCP 8080

TCP 443

UDP 22

UDP 4422

What do the augmentation methods for a segment define? They provide expanded MAC address ranges to supplement classification.

They define which additional user rules to apply to classify devices.

They define which ML clustering methods are used to classify devices.

They define the methods and credentials that the Data Collector uses to scan devices.

Which correctly describes a tag? A custom rule that reclassifies device types based on a variety of attributes

A description that applies to devices based on various criteria

A device attribute that is collected by a Data Collector

A flow attribute that is collected by a Data Collector

What is a requirement for CPDI to collect vulnerability and posture information on Windows devices? The devices must have 32-bit operating systems.

The devices must use Windows 7.

CPDI agents must be installed on the devices.

A WMI augmentation method must be attached to the segment for the devices.

Chapter 15

Learning checks

CPPM is integrated with CPDI. What determines whether CPPM sends a CoA when a device’s tag is updated by CPDI? The settings in the Profiler tab for the service that authenticated the device

The settings in the ClearPass Device Integration page

The cluster-wide General settings

The network device settings for the NAD to which the device is connected

Chapter 16

Learning checks

What is one difference between Wireshark capture filters and display filters? Only capture filters can be removed and changed during an active capture.

Only capture filters can filter packets based on protocol.

Only display filters can be removed and changed during an active capture.

Only display filters can filter packets based on protocol.

What is a sign of a TCP Syn scan? (Multiple answers can be correct.) A device that immediately sends TCP RST packets in response to Syn + Ack messages

Any TCP packet that has the Syn flag set without the Ack flag

Any TCP packet that has the Syn flag set with the Ack flag

Many TCP Syn packets from the same source to different destinations and ports

Chapter 17

Learning checks

What is the VIA web authentication profile used for? To authenticate VIA clients downloading a connection profile

To authenticate the VIA certificate

To authenticate RAPs

To provide the allow list for authenticated VIA clients

Which type of topology do you need to add if you want VPNCs to create tunnels to other VPNCs? Hub-spoke

Branch-mesh

Hub-mesh

Spoke-mesh

Chapter 18

Learning checks

How does Aruba gateway IDS/IPS detect malicious traffic? APs and switches notify the gateway when they detect malware.

CPPM notifies the gateway when it detects malware.

The gateway detects signatures in the traffic that indicate the presence of threats.

The gateway detects anomalies in the traffic that differ from usual traffic patterns.

For which use cases should you recommend IDS, as opposed to IPS? Ideas include: Preventing disruption of business based on false positives.

Why might a customer integrate Aruba gateway IDS/IPS with a SIEM server? To allow traffic to continue through a gateway if the IDPS engine goes down

To prevent a gateway from forwarding traffic if the IDPS engine goes down

To integrate gateway IDS/IPS with the company’s automated security event management

To ensure that gateways have the most up-to-date rules

Chapter 19

Learning checks

Match the Config with the Central Scope. b Email overrides

a Which alerts to enable

a Alert settings Global

Site

Which of these alerts occurs when the number of packets dropped by gateway IPS exceeds the configured threshold? Infrastructure Attack Detected

Authentication Failure Detected

Gateway Threat Count per Signature

Gateway IDS IPS Engine Packet Dropped Detected