Introduction
At any point in time on a network, there are multiple threats and vulnerabilities present, especially when it comes to Internet traffic. To help mitigate these threats and vulnerabilities, the Cisco Web Security Appliance (WSA) can be used as a filter for HTTP. It is important to know how the Web Proxy feature works in order to understand how the WSA will affect HTTP traffic and help protect users from malicious content.
Problem
The WSA is a web proxy that can filter HTTP, HTTPS, and FTP traffic. The most common protocol that is filtered is HTTP, which is handled by the Web Proxy. In this guide, I will discuss how the Web Proxy feature works on the WSA.
Solution
A proxy, in technical terms, is an entity that acts on behalf of another entity. A Web Proxy, as in the case of the WSA, acts as a middle man between a client and server. In order for the WSA to proxy Internet traffic, it must first receive the traffic from the clients. There are numerous methods for sending user traffic to the WSA, both explicit and transparent, which are covered in the Proxy Deployment guide. Once the WSA receives the user traffic, it establishes two sockets. One socket is between the client and the WSA. The other socket is between the WSA and the destination server, also known as the Origin Content Server (OCS). Each socket will be established via a TCP handshake as illustrated below.
Client to WSA
1) Client sends SYN to WSA (if explicit) or OCS (if transparent)
2) WSA responds with SYN, ACK to client with a source IP address of the WSA data interface (if explicit) or OCS (if transparent)
3) Client responds with ACK and TCP handshake is complete
Wireshark Capture of Client to WSA socket
WSA to OCS
1) WSA sends SYN to OCS with a source IP address of the WSA data interface (unless IP spoofing is enabled)
2) OCS responds with SYN, ACK to WSA
3) WSA responds with ACK and TCP handshake is complete
Wireshark Capture of WSA to OCS socket
Once a TCP handshake is complete between the WSA and the client, the client will send a HTTP request to the WSA. At this point, the WSA evaluates its policies to determine if the client traffic is allowed. If the traffic is allowed, then the WSA creates its TCP handshake with the OCS and sends the same HTTP request that was sent by the client. Once the OCS sends its HTTP response, the WSA evaluates the content to determine if the traffic is still allowed based on its policies. If the content passes the response side checks, then the HTTP response and content are returned to the client.
Wireshark Capture of HTTP Request and Response (blue is Client to WSA socket and green is WSA to OCS socket)
Wireshark Capture of HTTP Request and Response when site is blocked by Access Policy
Scenario 2:
Problem:
User would like to know how long does WSA takes to sync with Active directory? Any time frame? For an example WSA sync every 1 hr with Active Directory.
Solution:
It doesn't "sync"
There a couple of ways to get AD auth.
- Transparent auth, where you join the WSA to the domain, and as users hit web pages and are redirected, they get auth.
- AD Agent or now the CDA, and soon ICE... Users login to AD, the ADAgent/CDA/ICE see the activity in the domain controller logs and pass that info to the WSA.