Attach an Anti-Spyware profile to all security policy rules that allow data center traffic. The Anti-Spyware profile detects command-and-control (C2) traffic initiated from spyware installed on a server or endpoint, including categories such as adware, backdoor, browser-hijack, data theft, and keylogging, and prevents compromised systems from establishing an outbound connection from your network.

Clone the predefined strict Anti-Spyware profile and edit it. To ensure availability for business-critical applications, take safe transition steps as you move from your current state to the best practice profile. If you have a sinkhole set up to which you can send traffic for analysis, enable DNS sinkhole with packet capture to help you track down the endpoint that attempted to resolve the malicious domain. The best practice Anti-Spyware profile retains the default Action to reset the connection when the firewall detects a medium, high, or critical severity threat, and enables single packet capture (PCAP) for those threats.

Don’t enable PCAP for informational activity because it generates a relatively high volume of that traffic and it’s not particularly useful compared to potential threats. Apply extended PCAP (as opposed to single PCAP) to high-value traffic to which you apply the alert Action. Apply PCAP using the same logic you use to decide what traffic to log—take PCAPs of the traffic you log. Apply single PCAP to traffic you block. The default number of packets that extended PCAP records and sends to the management plane is five packets, which is the recommended value. In most cases, capturing five packets provides enough information to analyze the threat. If too much PCAP traffic is sent to the management plane, then capturing more than five packets may result in dropping PCAPs.

The best practice Action on DNS Queries is to block or to sinkhole DNS queries for known malicious domains and when you don’t have visibility into DNS queries, and to enable PCAPs.

Enabling DNS sinkhole identifies potentially compromised hosts that attempt to access suspicious domains by tracking the hosts and preventing them from accessing those domains. Enable DNS sinkhole when the firewall can’t see the originator of the DNS query (typically when the firewall is north of the local DNS server) so that you can identify infected hosts. Don’t enable DNS sinkhole when the firewall can see the originator of the DNS query (typically when the firewall is south of the local DNS server; in this case, the firewall’s blocking rules and logs provide visibility into the traffic) or on traffic you block.

In addition to protecting hosts with DNS sinkholing, attach the best practice Anti-Spyware profile to all security policy rules that allow traffic to identify infected hosts as traffic leaves the network and to stop attackers by preventing compromised systems from communicating with the malicious C2 network. If a system can’t communicate with the C2 network, the C2 network can’t control the system. For example: