Recently, I was tasked with implementing Websense to help monitor the activities of our user base in LA and NY.  After a few discussions with the Websense sales engineers, I came up with a design to utilize the ASA firewalls in both my locations.

The Websense components were installed as follows:

For the filters:

User Service - This service identifies the users, groups, and domains within Windows Active Directory.

Filtering Service - This is the service that will monitor or block content.

Network Agent - This component is how the server will communicate with the Policy Server.

DC Agent - This service integrates AD authentication for end users who don’t want to be filtered.

Usage Monitor - This service collects usage information based on categories, protocols, etc.

For the manager:

Policy Database - Microsoft SQL is required to store your database.

Policy Broker - This service updates the filter servers whenever a change is made to the policy.

Policy Server - This service provides policy management.

Websense Manager - This service allows you to manage your filters.

Log Server - This service collects the logs off the filters for reporting.

The Websense engineers recommended that I install the Policy Broker, Server, and Database on one of the filter server.  I felt it didn’t make sense to add the bulk of the processing power to a dedicated filter box.  Plus, I’d rather have all the management components reside on a central server.

During my initial install of each of the filters, I only had one network card enabled.  Also, for some odd reason I was unable to set up ‘integrated’ mode and was forced to install each filter as ’stand-alone’ devices.  Integrated mode allows you tie in with your ASA firewall, but can only filter http, https, or ftp.  Here are the commands I used:

url-server (inside) vendor websense host 11.27.194.44 timeout 30 protocol TCP version 4 connections 5
filter https 443 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow
filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow
url-block url-mempool 1500 –> Recommended configuration from Websense.
url-block url-size 4 –> Recommended configuration from Websense.

Even though I was running in stand-alone mode, I was still able to run the ASA firewall commands and the filter started working.  This particular setup ran for about a week until we had to move a new group who seem to have had stringent requirements for their web surfing activities.  What it boiled down to was they weren’t very pleased with the fact that our Internet connection was monitored and filtered.

Our LA filter was performing just fine, but our NY filter where the new group resided was extremely slow.  There were complaints that simple websites would take anywhere between 10-60+ seconds to load.  To troubleshoot the performance problem, I verified performance to/from the intermediate switches, core routers, and firewalls which all checked out fine.  The design I had built took into account that there were 150 end-users combined from both locations and the Websense engineers validated that the integration with our firewalls was sufficient.  After verifying the network, I had contacted the sales engineer to engage their support.

Websense support noticed I wasn’t running integrated mode properly and walked me through updating each filter.  Once we were fully integrated, the performance for NY suffered even more to the point that web pages were taking minutes to load.  So now I started questioning whether or not the integrated mode could support a handful of users.  Websense’s documentation clearly states that the integrated mode with an ASA firewall can easily support up 250+ users which was obviously not the case.

I had to engage support yet again and was told to run each filter in stand-alone mode, activate the second network card on the filters, and SPAN the data to the second NIC.  Websense support clearly stated that RSPAN doesn’t work with their product and that it was unsupported.  To the set the record straight, RSPAN does work with Websense.  You just have to figure out the IOS configuration because most of Cisco’s documentation still refers to the ‘reflector-port’ option which doesn’t run on 3560s or 3750s.

My ASA inside interface in LA was configured as a trunk on port Gi1/0/3 on SW11; nothing special needed to be configured on the trunk port where the firewall was connected.  Here’s my configuration on SW11:

vlan 888 –> This vlan number should be lower than 1000.  I tried 1888, but that didn’t seem to work.
name RSPAN-ASA-INSIDE
remote-span

interface vlan 888 –> A ’show interface’ will reveal that the line protocol is down, which is fine.
no shutdown

monitor session 1 source vlan 8 –> Using ’source interface gi 1/0/3′ didn’t work for me.
monitor session 1 destination remote vlan 888

interface GigabitEthernet1/0/25
description CONNECTED-TO-SW13-G0/24
switchport trunk allowed vlan add 888 –> I do this because I specifically allow certain VLANs across the trunk.

Here’s my configuration on SW13:

vlan 888
name RSPAN-ASA-INSIDE
remote-span

interface vlan 888
no shutdown

interface GigabitEthernet0/24
description CONNECTED-TO-SW11-G1/0/25
switchport trunk allowed vlan add 888

monitor session 1 source remote vlan 888
monitor session 1 destination interface Gi0/22 encapsulation dot1q ingress untagged vlan 8

Once I entered the destination interface, my stand-alone LA filter started seeing all the protocols.  The performance appeared to be much better and can supposedly handle up to 1200+ users.  I’ve excluded the new groups from being filtered for the time being and have activated it for the rest of my group to validate the performance.  I’ll probably monitor the behavior over the long weekend before implementing entirely, but hopefully my performance problems are now behind me.

I wonder if it would’ve been easier to implement Cisco’s Ironport web filter??

For me, returning back to work after a long weekend is a slow process.  I find that I need to spark my motivation in some way, so before diving in to my workload, I decided to read up on MPLS.  The main reason for reading up on MPLS (and not something else more enjoyable) was to prepare for a proposal that I needed to write up for a client.  Since terminology is often thrown around in meetings and discussions, I figured during my morning lull that it was best to solidify my knowledge of the technology.  I pretty much read through Chapters 1 & 2 fairly quickly.  Based on past experiences, the bulk of the material for Cisco Press books seems to appear in the 3rd chapter.  On that point, here are the notes I gathered:

MPLS Fundamentals - Chapter 3: Forwarding Labeled Packets

IP Lookup vs Label Lookup
-Lookup in CEF table
–IP-to-IP
–IP-to-label
-Lookup in LFIB table
–Label-to-IP
–Label-to-label

Label Operations Recap
-Pop - top label is removed; packet forwarded with remaining label stack or as an unlabeled packet
-Swap - top label is removed and replaced with a new label
-Push - top label is replaced with new label (swapped) and one or more labels are added (pushed) on top of the swapped label
-Untagged/No label - stack is removed and packet is forwarded unlabeled
-Aggregate - label stack is removed and IP lookup is performed on IP packet

Unknown Label
-LSR will drop incoming packets with an unknown top label

Reserved Labels 0 - 15
-0 - Explicit NULL Label - Maintains QoS on PHP
-1 - Router Alert Label - Present anywhere in stack except bottom; packet not forwarded in hardware will be reviewed by software process
-2 - IPv6 Explicit NULL Label
-3 - Implicit NULL Label - PHP; removes LFIB lookup for directly connected and summary
-14 - OAM Alert Label - Not used by IOS; used for failure detection, localization, and performance monitoring

IP TTL
-An 8-bit field within an IP header signifies the time a packet has to live before it is dropped;  TTL is usually 255 and decremented by 1 at each hop; When TTL reaches 0, packet is dropped by router and sends ICMP message type 11, code 0 (time exceeded) to end of LSP for delivery to originator (i.e. P-router has no knowledge of orignator routes)

MPLS TTL
-IP TTL value is copied to pushed labels
–IP-to-MPLS Behavior of MPLS TTL - Safeguard mechanism in IOS does not copy if MPLS TTL > IP TTL
–Label-to-label Behavior of MPLS TTL - Swap operation, TTL of incoming label -1 is copied to swapped label; Push operation, received MPLS TTL of top label -1 is copied to swapped and pushed labeles; Pop operation, TTL of incoming label -1 is copied to new exposed label
–P-router Behavior of MPLS TTL - Notes what the MPLS payload, a Layer 2 frame, is when the TTL expires; drops packets if not IPv4 or IPv6

MPLS MTU
-n * 4 bytes, n = # of labels
-sh mpls int det
-mpls mtu ‘1500 + (2 * 4)’
-Giant Frame
–Layer 2 frame that reaches max size for data link
-Baby Giant Frame
–Slightly bigger than max allowed
–Recommended on switches
—system jumbomtu
—system mtu
—mtu (int setting)

MPLS MRU
-Cisco proprietary; LSR is informed how big a received label packet of a certain FEC that can still be forwarded out without fragmentation; label operation determines MRU per FEC or prefix

Fragmentation
-If labeled packet exceeds outgoing MTU, the LSR strips the label stack and fragments IP; if DF-bit set, ICMP error message type 3, code 4 (Fragmentation needed and do not fragment bit set) is sent to end of LSP
-Path MTU Discovery - Orignator that receives ICMP error message type 3, code 4 lowers the size of packet and retransmits to avoid fragmentation
–Firewalls, ACLs, and routing issues can prohibit originator receipt of ICMP error message type 3, code 4

With each passing day, I get further and further from where I need/want to be with my security studies. There was a point in April when I managed to get some practice lab time in my schedule. I can only blame myself for the lack of focus. For here I am at another point in my life and I’m conflicted with continuing my pursuit of the security lab. The reason for this misdirection is quite simple – work has taken over my life. While it may sound harsh, the reality of becoming an IE has drastically changed my life for the better.

During these harsh economic times, I still find companies are looking to contract or employ an IE. Contract work is usually long and tedious for most consultants. For me, I’ve had to adjust and reorganize my daily priorities to accommodate the contract work hours in the evenings and on the weekends. There just aren’t enough hours in the day to do everything, so I basically had to sacrifice my security studies in order to keep up with the chaos. I’m not giving up on the track but merely postponing lab studies until October or November. From the time when you pass your written exam, you have 18 months until your passing result has expired. Basically I have until February 2010 to complete or make an attempt at the lab. This year doesn’t have to be a complete wash. I am, however, going to continue to read all the Cisco Press security books to prep for the OEQ since it takes me awhile to absorb some of the material.

The 2 main drawbacks about my contract is the distance from my house and the current security products that they have in-house. Firstly, I can no longer take the train since the contract is located in another area of SoCal. This just means that I lose the ability to read an hour in the mornings and need to find some time in the evening – for most of you who attempt to read at night now you already know how difficult that task may be with family and other activities (i.e. social life, sports, fitness, etc.). Secondly, my new has no use for any of the Cisco security products. The company uses CheckPoint firewall and McAfee’s Intrusion Prevention products. Cisco isn’t the right solution all the time, but I have stated my case with the current products to senior management, so let’s leave it at that.

There is a plus to all of this in that my contract relies heavily on MPLS. Prior to announcing a few months ago that I was going to focus my time on the security track, I had just walked away from my Service Provider studies. In order to properly support my new environment, I’ve had to read and familiarize myself with ATM, MPLS, L2/L3 VPN, SP QoS, BGP, IS-IS, and Management. Guess what, that’s more than half of the topics on the SP lab. At the moment, I’m far from committing to the track at all, but I have been keeping track of my progress and found that I’m not too far off either. I know for a fact that the amount of work is steady enough where I’ll be busy until the end of the year.

We’ll just have to wait and see.

A few weeks ago, Cisco released version 8.2 for the ASA, which you can read more about the updated features here.  For me, one of the most appealing features that stands out the most is the NetFlow Secure Event Logging feature (NSEL).   Originally this feature was only made available on version 8.1 specifically for the 5580 models in January of this year.  Now it’s available from the 5505 models up to the 5580.

What’s the big deal?  Currently I’m dealing with a configuration where an Internet connection terminates directly on an ASA 5520.  Every month I have to deal with senior management inquiring about which department is consuming the most bandwidth so that finance can appropriately charge back the usage internally.  In order to appropriately collect this data, I had proposed to place a router in front of the ASA so that I could collect NetFlow statistics and report the information properly.  With NSEL on the ASA, I’d be able to collect the information directly without any additional equipment.

Hmm, if everything works as planned, I’ll have to figure out what to do with all these spare 3845 edge routers.