16 Rules for Deploying Access Rules

Original Article

Best Practices Firewall Policy for ISA Server 2004

1. A Computer does not have a brain. You should check your ISA Server configuration when its behavior doesn’t match your expectations.
2. Allow access selectively. Only allow access for users, sources, destinations, and protocols that you need, and check each rule carefully. Only use deny rules when you can’t control access with allow rules.
3. A deny rule must come before an allow rule when both apply to the same policy elements such as users or source IPs.
4. When you must use a deny rule, an explicit deny rule, such as a deny rule for a specific user or source IP, should be considered first.
5. Place rules that will have high match rates near the top of the rule base if you can do so without changing the effect of your firewall policy. These are rules that are very likely to be matched, such as rules that apply to “All users” or “All authenticated users”. This enables ISA Server to evaluate rules more efficiently.
6. Keep your firewall policy as simple as possible.
7. Never use an allow all to all rule in a production environment. ISA Server cannot control access if you do.
8. Don’t create a rule that duplicates a system policy rule.
9. Remember that every rule is evaluated independently. Though rules are evaluated in order, each one is evaluated on its own when the firewall is going through the rules.
10. Never allow access for all to Local host. The Internal network should be considered untrusted in this regard, too.
11. SecureNAT clients can’t be authenticated, so use Web proxy clients and Firewall clients when you require user authentication.
12. When possible, use IP-address-based rule elements over user-name-based elements, because they are evaluated more quickly.
13. Configure clients as Web proxy clients when you use domain name sets or URL sets in your rules. Otherwise, the access rule maybe ignore by failed reverse domain name resolution, and may cause a slow response.
14. Only use application filtering (such as the HTTP filter) when you real need it. Use of the filters may affect performance.
15. Remember that there is a deny all rule at the base of the firewall policy.
16. Finally, always test your policy in a laboratory environment before testing and then using it in production.