Deny all before allow policy

@Dave You can' t be serious! A server is a general purpose machine, not built to discard more than a few connection attempts. All in contrast to a firewall. I' ve seen many servers which failed after 10 hostile login attempts because their OS simply wasn' t engineered to handle thousands. For your other advice I would agree: best practice is to weigh the effort of ' allow few, deny all' vs. ' deny few, allow all' . If the administration of country lists is too much hassle you might overlook a hole in the fence. @Noot: What I would really like to contribute is that I would place the blocking policy on the direction ' internal' ->' wan' as well - connections to hacker sites initiated by your users (clicking links in phishing emails, ' closing' ads etc.) would effectively be harmless.

@Dave You can' t be serious! A server is a general purpose machine, not built to discard more than a few connection attempts. All in contrast to a firewall. I' ve seen many servers which failed after 10 hostile login attempts because their OS simply wasn' t engineered to handle thousands.

My seriousness is pretty much limited to knowing there are web server software supposedly designed to handle thousands of IP connections and that there direct/in-direct solutions to blocking IP addresses based on country origin from ever getting/connecting to your web server. But given a choice, hands down I would go with a dedicated hardware/firewall/security appliance solution for protecting a web server. The way I was looking at Scott' s problem is his company has tasked him to use their fgt to protect their internal web server -- if the fgt is not powerful enough for the task he may consider an alternate route to the solution, even if it is not idea solution or best practice......at least until he company buys better hardware. :)

Thanks for the input guys. Thing is, I already have the deny all for China at the top of our WAN1->Internal list. It' s not working though.. Running v5 GA Patch 5 firmware. Again, if I lock down the allow policies more it works as expected. I' ve actaully got a Group created for a slew of countries that we simply don' t want accessing our services. No reason for them too so we' d like to take the proactive approach and just deny everything matched regardless of the allow policies below it. I' ve tried adding the international deny policy as " any/any" - same result. I hadn' t tried slapping it on internal -> WAN1 though. I' ll see what happens. This is my first go with Fortigate' s and having coming from Cisco I just figured a Deny all at the beginning would stop all matches through out the rest of the policy list. Maybe that' s not the case though. EDIT: Tried applying the Deny rule to the Internatinal group on internal -> WAN1 -- same results

Well, it depends on how you use it and how you test it. I can imagine that testing access from the WAN side from a country like China is not easy to do. This kind of access is blocked by a ' WAN' ->' internal' policy. Besides, even if the IP-to-country list of FortiGuard is updated periodically it may not cover 100% of the address space. And, if I had to run a server in China I would try to use a proxy abroad these days... In principle, the FGT is a stateful firewall. Policies decide if a session can be established at all. The direction given by the source/destination interface pair determines who opens a session. Traffic flows in both directions, in and out, once a session is established. This is in contrast to a packet filter which blocks all traffic strictly by looking at each packet. The reasoning behind this scheme is that in order to control traffic the firewall only has to control session setup. This is way more efficient than controlling each and every packet of a conversation that is already allowed.

Without the network topology, it' s hard to see where is the problem. The basic firewall features never failed me in the past. Instead of using the China IP group, you can create a policy with easy to test IP groups for easy verification. Also make sure your servers are connected to the interface your policy protects.