Seven ways to leverage your infrastructure against spyware
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
|When in doubt, reimage|
Spyware is on the tip of every security manager's tongue. During the past 18 months, spyware has exploded from a nuisance of faulty adware to a computing plague that threatens to compromise user privacy, expose proprietary data and destroy IT resources.
In a recent Information Security survey, 87.5 percent of respondents said that controlling spyware was their top priority for 2005. AV and security vendors are racing to convert consumer-centric antispyware applications to centrally manage tools designed to help enterprises counter the threat. But antispyware technology remains rooted in the signature-based framework of its AV cousins, making it only partially effective.
Enterprises can curb spyware by leveraging their existing infrastructure. These seven techniques can help enterprises close the gap on residual spyware risk.
1. DNS Black Holes
By tweaking your internal DNS servers to resolve common spyware domains to internal Web server IP addresses or to a local host (127.0.0.1), you can implement a DNS black hole. Whenever a machine is tricked into looking up a known spyware site, the internal DNS server will respond with an answer configured by the DNS admin.
Even if some spyware still manages to sneak in, manipulating DNS responses can prevent spyware packages from communicating with their home networks, rendering them inert.
Bleeding Edge of Snort's Black Hole DNS Spyware Project catalogs thousands of common spyware domains that should be considered when constructing DNS black holes.
Alternatively, you can include a list of potential spyware sites in each PC's local hosts file, resolving spyware sites to 127.0.0.1 without using DNS at all.
However, the DNS approach is easier to deploy because it doesn't require a configuration change to be pushed to each endpoint. Further, some spyware attacks the host file, changing its configuration to override any blocking via DNS or the hosts files themselves.
2. Restrict Privileges
Enterprises should consider getting serious about limiting the privileges granted to rank-and-file users.
Many organizations still give users local admin privileges. This is dangerous, because most users can be duped into running malicious programs. What's more, if you give users such access, they'll surf the Web and read e-mail with these accounts, likely exposing their systems.
Avoid this problem by assigning users to groups with limited privileges, especially on Windows machines. Assign user accounts to a limited-permission group, either the predefined "Restricted Users" group or a custom group.
However, to pull this configuration off in a Windows environment, security managers will have to alter their operations to support users with limited privileges. These operation changes include the following:
- Making sure clients have remote desktop management, such as Win-dows Remote Desktop, VNC or Dame-ware. This will allow the help desk to troubleshoot systems using administrator privileges.
- Deploying patch management and update control tools, such as Microsoft's Software Update Services (SUS), that let security teams push patches without user involvement.
- Installing by default various necessary browser add-ons, like Acrobat, Flash, Shockwave and QuickTime.
- Ensuring that AV updates can be deployed to desktops even when users don't have admin rights.
- Configuring systems with all printers that users are likely to need. If additional printers are required, make sure your help desk can add them remotely.
Unfortunately, many older (and even some not-so-old) Windows applications require local admin privileges. Enterprises should test these apps to see which files, directories, registry keys and user rights users need to access, utilizing tools such as Filemon, Reg-mon and Tokenmon (available at www.sysinternals.com). Tweak the ACLs to devise a configuration that allows these resources to be run by users without admin privileges, or consider moving the client to a terminal services environment that you can harden and monitor.
Microsoft's free DropMyRights tool restricts the privileges granted to machines with administrative rights. In-stead of the cumbersome RunAs capability, it lets enter- prises create a shortcut to invoke Internet Explorer, Out-look or any other application with limited rights. Place that shortcut icon on the Start menu, and you have a much safer approach than running them as local admin.
Enterprises should upgrade their desktops to Windows XP SP2, which has far more configuration options and is more resilient to spyware than other Windows versions. It isn't perfect, but XP SP2 provides better isolation of browser security zones and includes Data Execution Prevention, which helps prevent some buffer overflows. A number of the exploits used by spyware simply don't work in XP SP2.
3. Leverage AD
Active Directory shops can utilize Group Policy Objects (GPOs) to fine-tune client systems across the enterprise to thwart spyware that exploits weak configurations.
First, add known spyware and other malicious sites to IE's Restricted Sites zone, which flags sites that could cause damage. Carefully configure this zone so all scripting, ActiveX and download functionalities are disabled.
You can formulate a list of potential spyware sites to populate this zone in a variety of ways. For example, you could use the DNS and host files from Bleeding Snort and Someonewhocares.org as a solid start. Alternatively, download the free Spybot-Search & Destroy tool to a lab system and activate the "Immunize" function, which will automatically populate the local browser's list of restricted sites. You can review and edit those sites in the lab system's browser configuration, which can eventually serve as the template you apply to other machines with GPOs.
Also, using GPOs, you can configure IE to deny all browser add-ons, except those that users actually need (such as Acrobat and QuickTime). You can also prevent users from enabling specific browser add-ons.
Instead of worrying that users will accidentally click "OK" on an installation screen for an ActiveX control, configure all XP SP2 versions of IE via GPOs so that they won't display ActiveX installation prompts at all.
For fine-grained access, Windows machines also support software restriction policies. You can restrict specific programs based on their file system path, digital signature, zone of origin and MD5 hash.
In a highly controlled environment where users need to run only a limited number of programs, software restric-tion policies can be used to enumerate a small number of allowed programs and deny everything else. Lists of known spyware DLLs, EXEs, Browser Helper Objects (BHOs) and other related spyware elements are available at the Spyware Data Web site and are also included in freeware version of Spybot-S&D.
4. Deploy Alternative Browsers
Some enterprises want to avoid the problems of IE altogether, opting to use a competing browser, such as Mozilla's Firefox. However, other browsers have security flaws as well that could lead to the installation of spyware.
If you plan such a transition, don't underestimate the cost of the change. Test your apps carefully to make sure they work in non-IE browsers. Many supposedly "browser-independent" Web apps crash and burn when rendered in non-IE environments, making for some expensive redevelopment work.
A few private enterprises and government agencies have implemented a two-browser solution, using Firefox for routine Web surfing with a more restrictive environment for IE. In this scenario, using GPOs, IE uses a specific Web proxy with draconian rules that limit access to only certain Web sites running those IE-specific applications with a defined business need. The main Web page of internal business apps would include a link that invokes IE, loading the appropriate start page. In a sense, IE is restricted via the proxy to a limited number of trusted sites.
Or, if you can move entirely off of IE, you can define the GPO setting for "Don't run specified Windows appli-cations." Add "iexplore.exe" to this list to prevent users from launching IE. In case your users mysteriously squirm around that setting, you could again use GPO to change the default home page for IE to an internal Web site that tells your users not to run IE and points them to the preferred alternative browser.
5. Take Advantage of Network-based IPS
Many of the network-based IPSes now have signatures that can detect and block spyware.
Antispyware signatures in tools like TippingPoint's (3Com) UnityOne and McAfee's IntruShield are effective in quashing spyware. They attempt to match specific signatures associated with the spyware installation process or communication with the spyware's controller. Because of the risk of accidentally blocking network traffic with a false positive, these network-based signatures tend to be less sensitive than the detection capabilities of host-based scanners. Still, they provide network-based signatures that augment host-based scanners.
Bleeding Snort offers Snort-based malware rules for IDS/IPS tools. This list contains signatures for almost 1,000 common spyware and other malware samples. With a Snort sensor on outbound HTTP traffic, you can use Snort to identify where spyware is installed in your network.
6. Enlist Outbound Web Proxies
Many large enterprises use a proxy for their outbound Web traffic, giving them a central point for controlling, logging, analyzing and filtering employees' surfing habits. But few organizations take advantage of these capabilities.
Some organizations are using Web proxies to block or detect spyware by running a commercial AV and antispyware scanning tool against the proxy's HTTP cache. Whenever the tool discovers known spyware specimens, it can block access to its site or alert the operations team as to which clients might be infected. Configured to run every hour, such a scan provides fairly quick notice of a potential infection without greatly impacting performance.
Also, many spyware programs alter the browser's user-agent string, a behavior you can use to detect installations. Every Web site the infected machine visits will receive the spyware's special user-agent string instead of the browser's default value. Some spyware/adware companies do this so that any participating Web sites associated with the spyware can easily recognize infected systems, allowing the companies to get paid for driving traffic to particular sites.
Another Bleeding Snort project turns this custom user-agent field against the spyware companies by offering a list of the most common user-agent types associated with spyware and aggressive advertisers. Some organizations are using custom filters at their outbound Web proxies or custom signatures in a network-based IPS/IDS based on the Bleeding Snort Spyware User-Agents list. When malicious user-agent types are discovered, users are directed to an internal Web site with instructions on how to proceed.
A handful of organizations are taking this user-agent idea further. For outbound proxy, network-based IPSes/ IDSes can log the user-agent string. You can then use a script to maintain a list of each unique internal IP address accessing the Internet, associate them with user-agent type and monitor for changes. If a given IP changes to another user-agent type in a predefined 24-hour span, there's a significant likelihood that it has been infected. Because it doesn't rely on a prepopulated spyware list, this approach can detect unknown spyware. Spyware User-Agent Detection (SUAD), a free script released by Intelguardians, can analyze Squid proxy logs for this suspicious behavior.
7. Leverage Startup Scripts
A final spyware detection tactic involves using Windows domains to deploy a client script that scans for common spyware files, processes and registry keys during system startup and user logon.
Data, rules and signatures for such scripts are available, including the Spyware Data Website, the Spybot S&D package and the Bleeding Snort malware rule list. When the startup script locates a spyware specimen, it either alerts the user with a dialog box or notifies a security manager.
Organizations have deployed in-house scripts, essentially creating their own customized antispyware scanning capability. Such scripts are typically configured to delete the spyware automatically; some organizations prefer to notify an admin for manual inspection and removal.
No Easy Replacements
Obviously, not every organization will employ each of these tactics, but you should consider the approaches that best suit your needs and infrastructure.
These strategies work in conjunction with enterprise antispyware products. Together, they create synergistic layers of antispyware defense that will help reduce your exposures.