Cisco WSA Policies

In this and other posts we’ll discuss the Cisco Web Security Appliance. This is the blog agenda:

Part 1: Introduction
Part 2: Installing
Part 3: Deploying Proxy Services
Part 4: Policies
Part 5: Acceptable use & HTTPS Inspection
Part 6: Authentication
Part 7: Defending malware

This is the 4th part of the series.

Creating policies is one the major (en most fun) part of the WSA. In this blog I’ll cover the configuration of access policies and identities.

Click  Web Security Manager > Access Policies

access policy default

Only one policy can be applied. This is based on first match (top-down). If no policy matches, the Global Policy will be used.

First, you have to create a identity. An identity doesn’t identify a user, but it identifies a client or transaction that may require authentication. Identity membership is determined before authentication is done. Policy group membership is determined after authentication is performed.

Click  Web Security Manager > Identities > add identity and create the identity, based on IP’s ip ranges or IP subnets. Possible identities are:

  • Kiosk users
  • Update agents
  • Company users

Continue reading

Cisco WSA Deploying Proxy Services

In this and other posts we’ll discuss the Cisco Web Security Appliance. This is the blog agenda:

Part 1: Introduction
Part 2: Installing
Part 3: Deploying Proxy Services
Part 4: Policies
Part 5: Acceptable use & HTTPS Inspection
Part 6: Authentication
Part 7: Defending malware

This is the 3th blog in the series about the proxy configuration.

There are a two proxy modes:

  • Explicit Forward Mode
  • Transparent Mode

In Explicit Forward Mode the client does have an Proxy configuration. There is no configuration needed on the network infrastructure (routers/switches). Authentication is easy and there are three methods for providing the proxy information:

  • Automatic Proxy script
  • Enter the proxy server IP address
  • Automatic detect settings using WPAD protocol

In transparent mode, there is no configuration needed on the clients. The network infrastructure redirects the traffic (WCCP). Authentication could be an issue.

Redirection options are:

  • Web Cache control protocol (WCCP, used in Cisco ASA, ASR and Catalyst switches)
  • Policy based routing
  • Layer 4 switch
  • Layer 7 switch (like a Citrix Netscaler)

WCCP is the most used redirection option for transparant proxies. For more information about WCCP and the configuration, check this link.

PAC files

PAC files are used in Explicit Forward Mode. The PAC file link is configured on the clients’ proxy settings. If you need help with creating PAC files, check this link.

You can host the PAC file on any webserver, but hosting on the WSA is possible too. Click Security Services > PAC File Hosting  and upload your PAC file. It’s recommended to host the PAC file on a seperate web server.

Continue reading

Installing Cisco WSA

In this and other posts we’ll discuss the Cisco Web Security Appliance. This is the blog agenda:

Part 1: Introduction
Part 2: Installing
Part 3: Deploying Proxy Services
Part 4: Policies
Part 5: Acceptable use & HTTPS Inspection
Part 6: Authentication
Part 7: Defending malware

This is the 2nd post in the series.

Installation of the (virtual) WSA is straight forward. I’ll cover the most important and critical steps in a basic installation.

Hardware appliance

A hardware appliances has 5 interfaces, connect the required interface to your network:

  • T1 + T2 (used for L4TM only)
  • P1 + P2  (used for web proxy)
  • M1 (management or web proxy)

Virtual appliance

The virtual appliance is downloadable as a OVF file. Import the OVF file into you VMWare servers with the specifications as described in the previous blog post.

Configuration

Your first basic installation starts with connecting to the M1 port and browse to: http://192.168.42.42:8080 and login with these default credentials:

  • username: admin
  • password: ironport

You can also connect with SSH with the same login credentials. Start the interface config with the interfaceonfig command:

  • Run edit command
  • enter number 1
  • Enter IP address, netmaks and hostname.

Run  Setgateway
Select the M1 interface and enter the IP of the default gateway.

Don’t forget to commit the changes with the commit command. This is only needed for CLI configuration.

And the WSA appliance is up and running!

installation done

Continue reading

Cisco Web Security Appliance introduction

In this and upcoming posts we’ll discuss the Cisco Web Security Appliance. This is the blog agenda for the upcoming weeks:

Part 1: Introduction
Part 2: Installing
Part 3: Deploying Proxy Services
Part 4: Policies
Part 5: Acceptable use & HTTPS Inspection
Part 6: Authentication
Part 7: Defending malware

In this blog we’ll talk about the product introduction.

The Cisco Web Security Appliance (WSA) is an appliance for securing http, https and ftp traffic from (and to) the internet.

The WSA replaces all, or most of these devices in your network:

Firewall
Webproxy
Anti spyware
Antivirus
URL Filtering
Policy management

As you can see, it’s more than just a regular proxy server.

The internet provides a lot of websites, good websites and bad websites. There are a lot of websites which are not work related for a lot of companies. If you want to limit or block those websites for users, the WSA is the product for you. Limitation can be time based, bandwidth based, user based or category based (79 categories). Road warriors (remote users) can be protected too by Anyconnect security or Web cloud Security, also known as Scansafe.

Continue reading

LISP Mobility with OTV

In previous posts we talked about implementing OTV with ASR routers. OTV is a overlay network to get end-to-end layer 2 connections over a layer 3 (WAN) network. In most implementations is FHRP (First Hop Redundancy Protocol, like HSRP/VRRP) filtering needed. These filters are needed to keep routing in the same datacenter where the traffic originates.

Let’s take another look at the high level design:

OTV Network layout

When FHRP filtering is active, the Virtual IP (aka.. default gateway for clients) is active in both datacenters. Which means: a packetflow from a server in DC1 is routed on the core switch/router in DC1. If you move (vMotion/ live migrate) that server to DC2, the packetflow is routed on the switch/router in DC2.

If you think this through, the datacenter outgoing trafficflows are efficient: routing will be done on the most nearby router. But… incoming traffic from branch offices is still not efficient: the WAN network does not know where the VM is hosted, so the packets are routed by the normal routing protocols. This could result in inefficient routing: if the IP range is routed to DC1 on the WAN and the VM is hosted in DC2, the Datacenter-Interconnect (OTV) will be used to get the packets to the VM.

This is where LISP mobility comes in.

Continue reading