Deny all before allow policy

[Noot]

I' m trying to block specific regions of the world from accessing our public services. Particularly, I' m testing access from China using http://www.websitepulse.com/help/testtools.china-test.html -- so far I added a policy that denies all sources orginating from China. That policy sits before our allow policy for http access to our internal web server. That metod doesn' t seem to work. I have to lock down our allow policy to only allow like US/Canada/Mexico sources in order for the access from China to be restricted. I was hoping adding a policy to deny all international source addresses before our allow policy would do the trick - is that not doable?

[Dave_Hall]

You did not specify which firmware your fgt is running on, so this is for 4.0 MR3.... 1. Create a firewall object type Geography for China. 2. Create a fw policy from WAN ->Internal, using the firewall object you just created as the source address. Set the Action to block. 3. Move this rule above any other existing WAN->Internal fw rule you may have.

[Dave_Hall]

I was hoping adding a policy to deny all international source addresses before our allow policy would do the trick - is that not doable?

You may want to rethink this strategy, considering the number of IP address checks you would be placing on the fgt each time a packet comes into the fgt (could be in the 10s of thousands. edit: ok may be not that many :-). If this fgt was acting mainly as a " firewall shield" for your internal web server I may consider it. But if the fgt is functioning as a general firewall/UTM appliance for your company you will want to minimize the IP checks, say create a fw object group of allowed countries then craft a fw policy that only allows those country IPs to that internal web server -- create another fw policy blocking everything else directed to that address. But personally, I would rather see if the web server software already has that country block capability and do the blocking/allowing that way.

[ede_pfau]

@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_Hall]

@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. :)

[Noot]

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

[ede_pfau]

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.

[vanc]

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.