Advanced IP Defense Best Practices
Recommended practices for configuring policy rules, managing exceptions, tuning connectivity, and maintaining Advanced IP Defense effectiveness.
| Where Can I Use This? | What Do I Need? |
|---|
- PAN-OS 12.2 and later
- Strata Cloud Manager
- PAN-OS 12.1.x and 11.2.x (EDL-based)
|
- Advanced IP Defense license
- Admin access to firewall or Strata Cloud Manager
|
Advanced IP Defense is most effective when you adopt an iterative approach to configuration. Start with the default profile for baseline protection, monitor the results, and refine your rules and exceptions based on observed traffic patterns. The following best practices help you maximize threat detection while minimizing false positives and operational disruption.
Policy Rule Best Practices
When creating policy rules, layer them from high-confidence threats to lower-confidence categories. Block high-confidence threats such as Malware C2 and Abuse immediately, alert on medium-confidence categories such as Anonymizers & Proxies to gain visibility before enforcing, and allow Netblock Owner traffic that represents your known cloud infrastructure.
The following examples demonstrate common policy rule patterns.
- Block direct-to-IP malware C2—Create a rule that matches both Malware C2 AND Direct-to-IP Detection with the action set to Block and log severity set to High. This prevents malware from establishing command-and-control connections using hardcoded IP addresses that bypass DNS inspection.
- Alert on anonymizer traffic—Create a rule that matches Anonymizers & Proxies (such as Tor, VPN, or proxy services) with the action set to Alert and log severity set to Medium. This helps you identify users or systems attempting to bypass security controls before you decide whether to block.
- Allow cloud provider traffic—Create a rule that matches Cloud Provider (such as AWS, Azure, or Google Cloud) with the action set to Allow and log severity set to Informational. This ensures legitimate business traffic to cloud services is not blocked by broader rules.
- Block high-risk IPs with cloud exceptions—Create a rule that matches High-Risk AND NOT Cloud Provider with the action set to Block and log severity set to High. The NOT operator carves out legitimate traffic to shared cloud infrastructure without requiring a separate allowlist entry.
After creating policy rules, monitor the Advanced IP Defense logs to verify that your rules are functioning as expected. Adjust rule criteria and actions based on observed traffic patterns and security requirements. Consider creating exceptions for legitimate traffic that may be incorrectly matched by policy rules.
Cache-Miss Behavior Best Practices
When the firewall encounters an IP that is not in its local cache, it queries the Advanced IP Defense cloud service. If the cloud service does not respond within the configured timeout (default: 100 ms), the firewall fails open and skips Advanced IP Defense evaluation for that session. The cache-miss behavior setting in the profile controls this behavior.
- Start with fail-open (default)—Use the default cache-miss behavior during initial deployment to ensure business continuity. This prevents the firewall from blocking legitimate traffic while the cache warms up.
- Use strict enforcement selectively—For high-security zones (such as internet-facing DMZ zones), consider configuring the profile to drop traffic on cache miss. Only enable strict enforcement after confirming stable cloud connectivity and acceptable timeout rates.
- Monitor cache-miss rates—Track how frequently the firewall fails open due to cache misses. A high miss rate may indicate that the cloud lookup timeout is too low, network connectivity is unstable, or traffic volume exceeds the cache capacity.
- Allow caches to warm up after deployment—Immediately after deployment or a reboot, the local cache is empty and most lookups result in cache misses. Attributes are cached for 300 seconds (5 minutes) for threat-related categories and 86,400 seconds (24 hours) for Netblock Owner categories. Allow time for caches to populate before evaluating detection effectiveness.
Exception and Allowlist Best Practices
Use exceptions to exclude known-legitimate traffic that your policy rules may incorrectly match. Start with narrow, specific exceptions and expand only if needed. Regularly review your exceptions to remove outdated entries that may create security gaps.
The following examples demonstrate common exception patterns.
- Allow known DNS servers—Create an IP-based exception for your organization's DNS servers (for example, 8.8.8.8 and 8.8.4.4 for Google DNS) to exclude them from Advanced IP Defense policy rules. This allows internal DNS clients to use these servers without triggering attribute-based enforcement.
- Allow direct-to-IP protocols by port—Create port-based exceptions for protocols that legitimately connect directly to IP addresses (for example, port 5060 for SIP, port 3478 for STUN, port 1883 for MQTT, port 6881 for BitTorrent). This prevents direct-to-IP false positives for traffic that doesn't use DNS resolution by design.
- Allow specific infrastructure by EDL—Create an EDL-based exception using a dynamic list of your cloud infrastructure IPs. This allows legitimate business traffic to your own services without being blocked, and the EDL updates automatically as your infrastructure changes.
- Allow a specific service on a specific port—Create an IP-port pair exception for a known service (for example, 10.0.0.5:8443) when you need granular control. This excludes only traffic to that specific IP on that specific port from enforcement.
Allowlist entries have a priority order from highest to lowest: direct-to-IP ports, direct-to-IP IPs, direct-to-IP IP-port pairs, generic IP subnets, and generic individual IPs. If the firewall's available memory cannot hold the full allowlist, lower-priority entries are dropped first. The cloud service always retains the complete allowlist, so IPs dropped from the local copy are still checked during cloud lookups on a cache miss.
Monitor the Advanced IP Defense logs after creating exceptions to verify they are functioning as expected. Adjust exception criteria based on your security requirements and observed traffic patterns.
Direct-to-IP Detection Best Practices
Direct-to-IP detection identifies outbound connections that bypass DNS resolution, a technique commonly used by malware to establish C2 channels or exfiltrate data. Effective deployment requires understanding how the firewall tracks DNS resolution history and where false positives can occur.
- Understand coarse-grained attribution—The firewall cannot attribute DNS traffic to specific endpoints. As long as any host resolves any domain to an IP, subsequent connections from any host to that IP are not flagged as direct-to-IP. This coarse-grained approach reduces false positives for shared IP environments (such as CDNs and cloud hosting).
- Account for DNS TTL expiration—After a DNS record's TTL expires, a 300-second grace period applies before the IP is considered "unseen" in DNS. This grace period accounts for transmission delays and clients that use slightly-expired cache entries. Connections made after the grace period to the same IP without a new DNS resolution are flagged as direct-to-IP.
- Allowlist legitimate D2IP protocols—Protocols such as BGP, SIP, STUN, RTSP, CoAP, and MQTT connect directly to IPs by design. Use direct-to-IP allowlists to prevent false positives for these protocols. The default direct-to-IP allowlist includes common D2IP protocol ports and well-known service IPs, but you may need to add custom entries for your environment.
- Deploy on internet-facing zones first—Direct-to-IP detection is most valuable on zones where outbound C2 traffic is likely. Start with internet-facing zones and expand to internal zones only after validating false positive rates.
Connectivity Best Practices
Reliable connectivity to the Advanced IP Defense cloud service is critical for real-time threat detection. Tune your connectivity settings based on your network environment and monitor for degradation over time.
- Standard connectivity—For firewalls with direct internet access, use the default cloud lookup timeout of 100 milliseconds. Ensure DNS servers are configured and can resolve cloud service domain names. No proxy settings are needed.
- Proxy server environments—If your firewall is deployed behind a corporate proxy, configure the proxy server address, port, and authentication credentials. Enable the option to use proxy for inline cloud services. Test connectivity after configuration to verify the firewall can reach the cloud service through the proxy.
- High-latency networks—Increase the cloud lookup timeout to 200 milliseconds or higher to accommodate network latency. A higher timeout reduces fail-open scenarios but may add latency to traffic processing. Monitor timeout rates in the logs and adjust as needed.
- Redundant DNS—Configure both primary and secondary DNS servers. This ensures that if the primary DNS server becomes unavailable, the firewall can still resolve Advanced IP Defense cloud service domain names.
Monitor cloud service connectivity status regularly. If you experience connectivity issues, verify that network routing, security policies, and proxy settings are configured correctly. Adjust the cloud lookup timeout based on your network conditions and performance requirements.
Ongoing Maintenance
Advanced IP Defense configuration is iterative. After initial deployment, follow these maintenance practices to keep your deployment effective.
- Monitor threat logs regularly to identify blocked threats and validate that policy rules are working as intended.
- Review and refine rules as your network evolves and new services are deployed.
- Remove outdated exceptions that may create security gaps.
- Upgrade to PAN-OS 12.2 or later when possible to gain full profile-based controls, direct-to-IP detection, and granular attribute-based enforcement. PAN-OS 12.1.x and 11.2.x EDL-based deployments provide baseline protection but don't support real-time lookup or attribute-level rules.
- Create additional profiles for different security zones if you need different enforcement policies for different parts of your network (for example, stricter rules for internet-facing zones, more permissive rules for internal zones).
