Hello! I posted an article a while back on how to use a web proxy to block unwanted content. While this is good and fun, we need an easy way to configure clients to use the proxy. For this article I will be over both PAC file deployments and WPAD deployments. We will use the example proxy server of 172.16.0.5:3128. Let’s go!
First I’ll list a few common ways clients are configured to use a Web Proxy:
- Manual configuration — Client manually inputs configuration data into each of their browsers to use the web proxy for each protocol (HTTP, HTTPS, FTP, etc).
- PAC File –– A PAC(Proxy Auto-configuration) file, is a method where the client’s browser is configured with the location of the PAC file via http:// or https:// to be downloaded automatically .
- WPAD — WPAD (Web Proxy Automatic Detection) is the automatic and transparent configuration of client’s to use and send their web-traffic to a proxy server. This deployment of PAC files using already existing network protocols such as DNS or DHCP options.
- GPO — GPO( Group Policy Objects deployments are primarily used in Windows Domain environments. User will obtain proxy configuration automatically through these Group Policy Objects upon log-in. (not-covered in this article)
I’ve posted a few articles on how to set up a Forwarding Proxy using Squid, and using benefits like caching and content blocking (Ads, adult, gambling, etc). This can bring centralized web security and delivery to you and your users. However, users need to be expliclty configured to use the Proxy service. This means having their web browser like Firefox or even Internet Explorer set with the DNS or IP address of the Proxy server. This can be an issue if youhave little or no management of the user’s Web Browsers configuration. This is where a content-routing protocol like WCCP(Web Cache Communication Protocol) comes into play. With WCCP we can influence specific user traffic to be encapsulated and re-routed to your Proxy server. The difference between this and some of the other ways to force web traffic to your Proxy server(like iptables redirection) is the original Web packet generated by the user’s device is not altered. Instead it is encapsulated when it reaches your WCCP receiver running on an upstream egress router(user gateway towards Internet). It is then re-routed via this encapsulation to your Proxy server which is WCCP aware.
Before we begin, you will need a few things:
- Squid Proxy Server 3.4+ compiled with WCCP
- Router or Security device capable of running the WCCPv2 service(See vendor list here…)
- Some knowledge of Web Proxy Technology.
- A Web Browser to test with.
- Your favorite beverage and some patients.
Notice: Cisco ASA only supports having the user subnet(s) and the cache-engine(Squid Proxy server) behind the same Cisco ASA interface(inside,dmz,outside,etc). The reason for this is the WCCP processing on the ASA happens after interface ACL, meaning for example ACL on your inside interface are processed before any WCCP manipulation can begin.
- User requests a web resource on outside interface(usually the Internet) of Router/Firewall.
- WCCP Server (Router/Firewall) catches this interesting traffic(traffic we want to redirect) and encapsulates it within a GRE tunnel to the WCCP Client(Squid Proxy Server) on the other end of the tunnel.
- WCCP Client (Squid Proxy Server) decapsulates the GRE payload and fetches the original client request just like an ordinary Web Proxy would.
- WCCP Client receives a response from the external web server.
- WCCP Client (Squid Proxy Server) serves the web page back to the original User by spoofing the source IP address(This is key). Spoofing is done by rewriting the source IP address field of the packet with the External Resource’s IP address. This makes it look like the packet the user receives is from the external web site.
Hi All! So after my last article regarding securing a guest network web access with Squid and SquidGuard, I wanted to share how I came about creating a Splash Page for Guest users of my Free WiFi hotspot. My goal was to present new Guests with a splash page identifying certain Terms of Usage, etc. Basically we will need a HTML or PHP Splash Page, an ACL identifying the Guests by IP, an external ACL program (squid_session), and a Deny with Information (deny_info).
Hello, hello! Recently I posted a two part article on creating a Guest wireless network using OpenWRT, VLANs, and Firewall rules. Now we left things kinda open from a security standpoint. WE gave our Guest users full Internet access with no restrictions on sites, bandwidth usage, or ports!! Yikes! For this article I am going to walk you through the steps to close those gaps. We are going to first configure a Web Proxy server that will proxy outbound Internet connections. This allows us to check where and what are Guests are trying to get their hands on. Good and bad. We will also force Guests to connect to this Web Proxy server transparently. What I mean by that is the Guests will not be required to do anything on their side to connect, our firewall will take care of that. And lastly, I want only allow limited bandwidth of HTTP traffic. You will see later on how we can accomplish this. I’ve expanded upon this article of mine that uses squid proxy to filter Ads.