Republished with permission from
WatchGuard Technologies, Inc.
Fireware vs. the Cookie Monster (Part 2)
Using HTTP-Proxy to block ad-serving cookies at your gateway
In Part 1, I considered some of the overlooked problems ad-serving cookies create for individuals and businesses. Behavior tracking companies think that if a user enables cookies and the ad-serving cookie doesn't collect personal identifying information (PII), their ad-serving cookies are not malicious adware. This simple trust model might satisfy consumers, but organizations can experience a broader set of consequences when employee PCs leak business information through cookies. A behavior-tracking company can collect the behaviors of employees who use company-owned computers, aggregate the results, and deliver the findings to clients, all without your knowledge.
In light of all this, you might reasonably conclude that end user cookie controls alone are not sufficient for preventing corporate data leakage. In this article, I lay out a strategy for identifying ad-serving cookies you might choose to block. Then I explain how to configure your firewall's HTTP Proxy to strip those cookies before they are installed on employee PCs. My strategy recommends that employees use cookie blocking measures at the desktops to contain the privacy threat, while you use HTTP-Proxy features to manage the business threat.
Desktop cookie controls: involve the user
Most companies concede that users must enable some cookies to browse the Web effectively. Self-administration is the norm for small and medium businesses, and even organizations that centrally manage desk- and laptops often choose permissive policies that leave cookie control to users (usually, to minimize help desk overhead).
Users must therefore make informed decisions regarding cookies, personal privacy, and corporate exposure. Educate your users about cookie risks. Make users aware of the ways they can manage cookies in Internet Explorer, Firefox, and other browsers they use. Evaluate and post a list of approved cookie management software. There are hundreds of cookie managers to choose from. Two simple and freeware packages I can recommend are CookieWall and IECookiesView, but what works for me might not work for you. Antivirus, antispyware, and desktop security suite software often provide cookie managers: these will identify and block adware regarded as spyware.
If you have power users in your organization, suggest advanced techniques to customize IE's Restricted Zone using IE-SPYAD or other spyware ad block lists to reject cookies from known, risky sites. These measures create an initial layer of defense against malicious and unwanted cookies.
One-Two Punch at the HTTP Proxy
If you use the WebBlocker service on Firebox X Core, Peak, or Edge, you can use URL filtering by category to block access to the types of Web sites that are known to harbor spyware adware (Adult/Sexually Explicit, Gambling, Gaming). However, since merchants and publishers that users might reasonably visit can also install ad-serving cookies, you'll have to weigh aggressive filtering by category against the potential to interfere with business productivity.
Complement category-based URL blocking with cookie stripping. To decide what cookies your organization should block, collect a sampling of cookie caches from various company-managed PCs. This will yield a long list of potentially offending cookies. Now, apply some metrics to manage the configuration effort. For example, begin by identifying the ten most commonly encountered cookies, or simply choose ten cookies with the letters "ad" or "click" or "hit" in the cookie name. Consult online malware and cookie threat databases to determine if each top offender is spyware. Visit the privacy policies of these potential top offenders. In most cases, you can accomplish this easily by searching the domain/cookie name. Look for ad-serving cookies that match the following criteria:
Construct a decision table similar to the one I made:
Treat all ad-serving companies that do not post privacy policies as suspect.
HTTP Proxy Action Configuration
Based on the "strip" column in your decision table, compile a list of ad-serving cookies to ban from your network. Compose a Proxy Action to strip cookies, and then apply this action to an HTTP-Proxy policy. [Note that the procedure below is merely one of several ways to create and use Proxy Actions with the Policy Manager interface.]
From the Fireware Policy Manager, select Setup => Actions => Proxies. If you have already created your own custom proxy action based on the default HTTP-Client action, double-click that custom action to edit it. Otherwise, select HTTP-Client from the proxy list and click Clone. A Clone HTTP Proxy Action Configuration window appears. Name the cloned policy (for example, StripAdCookies; note that this step is unnecessary if you are editing an existing Proxy Action). From the Explorer-style menu on the left choose Cookies. Use Change View to obtain the advanced view, and choose Add. In the New Cookies Rule window, name this rule (for example, StripHitBox). Set the Rule Settings value to Pattern match and in the text box enter the exact name of the cookie you want to strip. (For example, hitbox.com. You can use the asterisk as a wildcard character to indicate you want to strip any cookie from a given domain; for example, *hitbox.com will strip foo.hitbox.com, bar.hitbox.com, etc.). Set the Rule Actions to Strip and make sure Log is checked. Click OK to close the New Cookies Rule window. Repeat these actions for each cookie you want to strip.
When you finish adding cookies rules, click OK to save the pre-defined HTTP Proxy Action Configuration. Click Close to get out of the Proxy Actions dialog box. If you have been editing a Proxy Action that existed before, the Proxy Action already applies to your HTTP Proxy policy, and the cookie stripping edits will take effect immediately. If you created a new Proxy Action for cookie stripping, proceed to the next paragraph.
Create a new HTTP Proxy policy. From the Properties tab in the Edit Policy Properties window, choose the StripAdCookies Proxy Action (or whatever you named the Proxy Action you just defined) from the choices in the pull down menu next to Proxy Action. Click OK to save changes and save your configuration to your Firebox.
Now test your configuration to confirm that your proxy is stripping cookies. You may want to temporarily add a cookie from a site you are sure to visit, such as watchguard.com, to verify that you implemented your blocking rule properly.
When the proxy detects cookies you told it to strip, it generates a logs event containing the key phrase ProxyStrip:
02-27 11:43:59 Allow 192.168.1.50 188.8.131.52 http/tcp 1057 80 1-Trusted 0-External/PPPoE ProxyStrip: HTTP Header cookie domain match (HTTP-proxy-07) src_ip_nat="184.108.40.206" src_port_nat="17809" proxy_act="HTTP-at-HHI" rule_name="Any HitBox" domain="ehg-medialiveinternational.hitbox.com" src_user="matthew@Firebox-DB"
Note that this log event illustrates a cookie rule where I have wildcarded all cookies created under the domain hitbox.com .
Confirm your proxy policy is permitting cookies you are not explicitly blocking. In this case, log events will contain the key phrase ProxyAllow:
02-27 11:43:59 HTTP-at-HHI-px 6001 ProxyAllow/HTTP Header cookie domain match proc_id="ma" time="Mon Feb 27 11:43:59 2006 (EST)" src_ip="172.17.1.50" dst_ip="220.127.116.11" pr="tcp/http" src_port="1057" dst_port="80" src_intf="1-Trusted" dst_intf="0-External/PPPoE"
Cookie rules require some maintenance. Repeat the assessment periodically. If you manage client computers and deploy desktop security software with cookie controls, consider optimizing the cookie rules at your HTTP Proxy. Leave spyware cookie blocking to the desktop, but complement that blocking with business risk cookie stripping at the HTTP Proxy.
After reading this, you might conclude that this is an awful lot of work to counter what you believe is a minor threat. Or, you might decide this procedure is a small price to pay for pruning one more branch off the worry tree. It's up to you to weigh the implications of this effort against the threat you perceive that cookies pose to your organization. Compensating a permissive desktop policy by imposing a uniform policy at the HTTP proxy could be a "win-win" situation if you want to exercise more control but do not want to overburden help desk staff. Especially if you are not comfortable instituting desktop security policies employees might find overly intrusive, consider slaying the cookie monster at the gateway with the Fireware HTTP-Proxy. ##
Copyrightę 2006, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.