" deny" rule getting bypassed

[Rick_H]

I have an Action:DENY policy setup at the top of the ruleset for inbound traffic from WAN1 to DMZ. The source address for this policy is a group which consists of some geography-based networks and " bad addresses" that come up frequently in the IPS. However, this policy doesn' t ever seem to get matched and hosts I have explicitly added to the blacklist group--or even as their own entry--are matched against policies further down in the chain. I know this has to be something easy, but after staring at it for a couple of days I' m just not seeing it. Hopefully one of you fellows can see what I' m missing. This is on a FortiGate 80C running FortiOS 5.0.7 (build 3608). I' ve attached a screenshot of the rule set, but the relevant bits of code are here:

 config firewall address
     edit " all" 
     next
     edit " outside.blacklist.121.139.0.0" 
         set subnet 121.139.0.0 255.255.0.0
     next
     edit " outside.blacklist.96.8.126.97" 
         set subnet 96.8.126.0 255.255.255.0
     next
     edit " outside.blacklist.108.61.91.211" 
         set subnet 108.61.91.0 255.255.255.0
     next
 end
 config firewall addrgrp
     edit " outside.blacklist.All" 
         set member " outside.blacklist.96.8.126.97"  " outside.blacklist.108.61.91.211"  " outside.blacklist.121.139.0.0"  [geography-based lists]
     next
 end
 
 config firewall policy
     edit 53
         set srcintf " wan1" 
         set dstintf " dmz" 
         set srcaddr " outside.blacklist.All" 
         set dstaddr " all" 
         set schedule " always" 
         set service " ALL" 
         set logtraffic all
     next
     edit 26
         set srcintf " wan1" 
         set dstintf " dmz" 
         set srcaddr " all" 
         set dstaddr " nat.inbound.rounding" 
         set action accept
         set schedule " always" 
         set service " HTTP"  " HTTPS" 
         set utm-status enable
         set av-profile " MainAV" 
         set ips-sensor " protect_http_server" 
         set profile-protocol-options " default" 
     next
     edit 37
         set srcintf " wan1" 
         set dstintf " dmz" 
         set srcaddr " all" 
         set dstaddr " nat.inbound.smtp" 
         set action accept
         set schedule " always" 
         set service " SMTP" 
         set utm-status enable
         set av-profile " MainAV" 
         set spamfilter-profile " MSPS Email Filter" 
         set ips-sensor " protect_email_server" 
         set profile-protocol-options " default" 
     next
     edit 42
         set srcintf " wan1" 
         set dstintf " dmz" 
         set srcaddr " all" 
         set dstaddr " nat.inbound.owa" 
         set action accept
         set schedule " always" 
         set service " HTTPS"  " HTTP" 
         set utm-status enable
         set av-profile " MainAV" 
         set ips-sensor " protect_http_server" 
         set profile-protocol-options " default" 
     next
     edit 49
         set srcintf " wan1" 
         set dstintf " dmz" 
         set srcaddr " all" 
         set dstaddr " nat.inbound.rdsgate" 
         set action accept
         set schedule " always" 
         set service " HTTPS"  " RDS_external_UDP" 
         set utm-status enable
         set av-profile " MainAV" 
         set ips-sensor " protect_http_server" 
         set profile-protocol-options " default" 
     next
     edit 51
         set srcintf " wan1" 
         set dstintf " dmz" 
         set srcaddr " all" 
         set dstaddr " nat.inbound.remote" 
         set action accept
         set schedule " always" 
         set service " HTTPS" 
         set utm-status enable
         set av-profile " MainAV" 
         set ips-sensor " protect_http_server" 
         set profile-protocol-options " default" 
     next
 end
 

These policies have been in place for sometime, yet this morning I have had the same IP address showing up in my IPS logs quite a bit:

Message meets Alert condition The following intrusion was observed: " PHP.CGI.Argument.Injection" . date=2014-08-08 time=10:18:04 devname=fw01 devid=FGT80C3911608826 logid=0419016384 type=ips subtype=signature level=alert severity=high srcip=96.8.126.97 dstip=[DMZ address of host in policy 42 above] srcintf=" wan1" dstintf=" dmz" policyid=42 identidx=0 sessionid=13078459 status=dropped proto=6 service=http count=1 attackname=" PHP.CGI.Argument.Injection" srcport=33113 dstport=80 attackid=31752 sensor=" protect_http_server" ref=" http://www.fortinet.com/ids/VID31752" incidentserialno=513620505 msg=" web_server: PHP.CGI.Argument.Injection,"

The source IP in this message is in my blacklist and I' ve tried specifying both it as a host and a /24 which included the address. Yet, inbound traffic from this host still seems to whiff past the deny policy and match against the next policy in the list instead. Any idea what I' m missing here? Any help at all is appreciated. Cheers, Rick

[Dave_Hall · Accepted solution]

If you are trying to block countries by geo, I would do it via local-in-policy., e.g.

config system global
    set gui-local-in-policy enable
end
config firewall address
    edit "block-country-netherlands"
        set associated-interface "wan1"
        set type geography
        set country "NL"
    next
    edit "block-country-brazil"
        set associated-interface "wan1"
        set type geography
        set country "BR"
    next
    edit "block-country-lithuania"
        set associated-interface "wan1"
        set type geography
        set country "LT"
    next
    edit "block-country-sweden"
        set associated-interface "wan1"
        set type geography
        set country "SE"
    next
    edit "block-country-china"
        set associated-interface "wan1"
        set type geography
        set country "CN"
    next
    edit "block-country-russia"
        set associated-interface "wan1"
        set type geography
        set country "RU"
    next
end
config firewall addrgrp
    edit "block-countries-group"
        set member "block-country-brazil" "block-country-china" "block-country-lithuania" "block-country-netherlands" "block-country-russia" "block-country-sweden"
    next
end
config firewall local-in-policy
    edit 0
        set intf "wan1"
        set srcaddr "block-countries-group"
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

[Raquel_Rellebo]

Hi rick,

I have the same issue with the client and to resolve it, we set the destination address of the virtual IP address(mapping). Configuring destination address set to "all" will not work. To test, try to add one virtual IP in the logs that is being attacked by the blocked IP and then test if it will be blocked.

I would like to explore fmurray suggestion to enable match-vip "set match-vip enable", please let us know if that configuration will also work.

Thanks,

Raquel

[Marklar]

I'm having the same problem with GEO Blocking. The only way it works is if the VIP is added explicitly, it will not follow any "Any" or "All" rules in the destination address field.

So I tried the "set match-vip enable" and it had no effect on this whatsoever.

There has to be a better way to block ALL traffic from ANY address or group I specify to ALL internal devices. I don't want china to even know I have a network behind my external IPs..

Any other ideas?

As a workaround, creating a VIP group and adding all VIPs to that group, then adding the VIP group as the destination works but it's counter-intuitive. I'm thinking of things like port-scanning and external > internal attacks, etc. Fortinet should have a quick, easy way to immediately block access to the ENTIRE protected internal network from a specific ip, iprange, geoip, etc. In my screenshot, the way that is setup *should* work, logically, but obviously it doesn't since VIP rules are processed before NAT. What i don't like about the VIP group solution is that it has to be managed. I should be able to say "hey Fortigate - block the entire world except the US", click save, and DONE. No management - it just starts working immediately and you cant accidentally forget about it. To me, that's the whole point of GEOIP blocking. Set it and forget it unless I want to explicitly allow certain IPs, then the global "block all" rule goes by the wayside.

China user: Hello fortigate, I am from China, can I scan your network?

Fortigate: Depends, lemme check to see if you're an allowed ip......nope, you're not. GTFO!

China user: Hello fortigate, I am your IT admin vacationing in China, am I blocked?

Fortigate: Absolutely not, come on in!

[Dave_Hall · Accepted solution]

If you are trying to block countries by geo, I would do it via local-in-policy., e.g.

config system global
    set gui-local-in-policy enable
end
config firewall address
    edit "block-country-netherlands"
        set associated-interface "wan1"
        set type geography
        set country "NL"
    next
    edit "block-country-brazil"
        set associated-interface "wan1"
        set type geography
        set country "BR"
    next
    edit "block-country-lithuania"
        set associated-interface "wan1"
        set type geography
        set country "LT"
    next
    edit "block-country-sweden"
        set associated-interface "wan1"
        set type geography
        set country "SE"
    next
    edit "block-country-china"
        set associated-interface "wan1"
        set type geography
        set country "CN"
    next
    edit "block-country-russia"
        set associated-interface "wan1"
        set type geography
        set country "RU"
    next
end
config firewall addrgrp
    edit "block-countries-group"
        set member "block-country-brazil" "block-country-china" "block-country-lithuania" "block-country-netherlands" "block-country-russia" "block-country-sweden"
    next
end
config firewall local-in-policy
    edit 0
        set intf "wan1"
        set srcaddr "block-countries-group"
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

[Marklar]

Dave Hall wrote:

If you are trying to block countries by geo, I would do it via local-in-policy., e.g.

config system global
    set gui-local-in-policy enable
end
config firewall address
    edit "block-country-netherlands"
        set associated-interface "wan1"
        set type geography
        set country "NL"
    next
    edit "block-country-brazil"
        set associated-interface "wan1"
        set type geography
        set country "BR"
    next
    edit "block-country-lithuania"
        set associated-interface "wan1"
        set type geography
        set country "LT"
    next
    edit "block-country-sweden"
        set associated-interface "wan1"
        set type geography
        set country "SE"
    next
    edit "block-country-china"
        set associated-interface "wan1"
        set type geography
        set country "CN"
    next
    edit "block-country-russia"
        set associated-interface "wan1"
        set type geography
        set country "RU"
    next
end
config firewall addrgrp
    edit "block-countries-group"
        set member "block-country-brazil" "block-country-china" "block-country-lithuania" "block-country-netherlands" "block-country-russia" "block-country-sweden"
    next
end
config firewall local-in-policy
    edit 0
        set intf "wan1"
        set srcaddr "block-countries-group"
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

Ok this is pretty slick..but there seem to be two issues:

1) The entries don't actually show in the gui.

2) It's still ignoring VIPs and allowing access to them.

For example - I tested by blocking my home IP and I lost connection to the FGT immediately after commiting the CLI changes. However, I have a VIP setup to RDP into my machine behind the FGT and that let me login.

Thanks for the help though that was a good tip to accomplish this in another way depending on how each users device is configured. Unfortunately, it looks like there is still no silver-bullet.

[Christopher_McMullan]

I've never seen match-vip *not* work. Is your VIP bound to 'any' interface, or one more specific? Just a guess...maybe it has to do with the specificity of the inbound VIP policy vs. the deny policy.

Maybe a few more screenshots and a flow trace to help out: shots of the ordering of the deny rule vis-a-vis the VIP policy, the VIP config itself (blurred/obfuscated as need be), etc.

And a flow trace:

diag debug reset

diag debug enable

diag debug flow show console enable

diag debug flow show function-name enable

diag debug flow filter addr w.x.y.z //--filter for a source or destination which makes the most sense here

diag debug flow trace start 5000

<test the rules, then...>

diag debug flow trace stop

diag debug flow filter clear

diag debug reset

diag debug disable

[Marklar]

I added more information and a workaround to my previous post above, but I also will try changing the VIP source with the match enable and report back. I thought this functionality was by design since VIPs are processed first but like other have posted, it's counter-intuitive to set the rules like I posted in the screenshot and have it NOT work.

[FatalHalt]

Christopher McMullan_FTNT wrote:

I've never seen match-vip *not* work. 

Regardless of it working or not, I think Marklar's point is completely valid. For whatever reason, this process feels so damn cumbersome and obtuse. Most things on the Fortigate, at least for me, are so easy to do, but this is just a pain in the ass every time. 

[Christopher_McMullan]

I also tested local-in policies as a possible solution (so I guess I lost the friendly race against Dave Hall to post on them), but they're only meant to control access to the FortiGate services, not forward traffic policies. Interface policies can also only apply UTM profiles - it doesn't seem they can block traffic based solely on source IP.

The best way to think of local-in policies is that the FortiGate has to not only be targeted at Layer-2 (which it would be as the Layer-3 gateway for all forward traffic), but at Layer-3 as well, and not to a VIP address. In other words, your Layer-3 destination needs to be the FortiGate. It's theoretically possible that if you used one of the IPs actually assigned to the FortiGate's interfaces, that it would block the traffic by using a local-in policy, but in this case, the VIP means the FGT replies to ARP requests for the VIP public address only, otherwise it is intended to forward the traffic through.

The reason they're not visible in the GUI is because the GUI local-in policy option is only for displaying the system-generated local-in policies, which are a summary ACL of all the allowaccess methods you specify per-interface (i.e., Administrative Access via HTTP, HTTPS, SSH, telnet, PING, etc., or 'set allowaccess x'). Custom local-in policies add to this list, but they're kept separate to help distinguish those you created yourself from the entries required for the CLI and GUI settings to actually work.

[trauthor · Accepted solution]

There are multiple posts in this forum related to VIP policy compromising security.  I have opened cases with FortiNet both for this issue and an additional issue.  I have also alerted appropriate parties.  To FortiNet's credit, they are working quickly to address this.  I have not yet seen an official public statement from FortiNet.  Please refer to the below correspondence to see if it pertains to your situation.  Thank you.

(O.P.:  not sure if it matters at this point, but I don't see a "set action deny" for rule 53 in the copy you took from the CLI.)

==========

Fw: FortiGate Security "Loophole" and Severe Bug

Two issues were discovered during FortiGate firewall product tests, the first a documentation issue which FortiNet has confirmed affects FortiOS 5.0.x and 5.2.x and the second a bug which affects any FortiGate "D" series in combination with FortiOS 5.0.10 (the FIPS 140 version; it is unknown whether other combinations of FortiOS and FortiGate are affected.)

1)  FortiGate Deny All rules do not deny all traffic.  What is documented:  "VIP rules" take precedence over "regular rules."  However, until two days ago (6/15/2015) after it was recently brought to their attention this was mentioned only briefly in a technical note and not in any of their standard documentation (the FortiOS handbook, admin guide, etc.)  It remains inexplicit that "VIP rules" also take precedence over "Deny All" rules.

- Here's the link to the technical note (taken from the support case):  http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33338

- Here's the link to the updated handbook, published 6/15/2015 (see page 956, "Exception to policy order (VIPs):")  http://docs.fortinet.com/d/fortigate-fortios-handbook-the-complete-guide 

The scenario documented in the stem support case is given below.  Rules appear in the same order they would after issuing the commands "config firewall policy" and "get."

=====

config firewall policy

edit 1

set srcintf "wan1"

set srcaddr "outside_blacklist"

set dstintf "dmz"

set dstaddr "all"

set action deny

set schedule "always"

set service "ALL"

set logtraffic all

next

edit 2

set srcintf "wan1"

set srcaddr "all"

set dstintf "dmz"

set dstaddr "nat_inside"

set action accept

set schedule "always"

set service "ALL"

set logtraffic all

next

end

=====

In the above example, "outside_blacklist" is a group of outside addresses and "nat_inside" is a VIP on the firewall.  As depicted, traffic will not follow the usual order of precedence.  Any traffic destined for "nat_inside" will ignore the Deny All in Rule 1 but match the Accept in Rule 2.  Below is the fix suggested by a FortiNet support engineer.

=====

config firewall policy

edit 1

set srcintf "wan1"

set srcaddr "outside_blacklist"

set dstintf "dmz"

set dstaddr "nat_inside"

set action deny

set schedule "always"

set service "ALL"

set logtraffic all

next

edit 2

set srcintf "wan1"

set srcaddr "all"

set dstintf "dmz"

set dstaddr "nat_inside"

set action accept

set schedule "always"

set service "ALL"

set logtraffic all

next

end

=====

Shown above, the change replaces the Deny All in Rule 1 with Deny "nat_inside."  This in effect restores the order of precedence.  (For an explanation, see the new section "Exception to policy order (VIPs)" in the handbook.  For the alternative fix, "match-vip," see the technical note.)  To summarize, FortiGate "VIP rules" are matched before "regular rules."  Most significantly, "VIP rules" are matched before "Deny All" rules.

The potential for a security "loophole" as described in the above case is compounded by:

a) a reasonable (until two days ago) expectation that a Deny or Deny All policy always denies blacklisted traffic in order of precedence; and

b) typical industry practice that only denied traffic gets logged.

Given these factors, a configuration error which would allow blacklisted traffic to enter a network undetected via an Accept rule is not unlikely.  [...]

2)  The secondary unit in a FortiGate "D" series active/passive cluster bricks (i.e., fails closed and must be re-imaged) after the first couple FIPS self-tests under certain conditions, two of them being:  when it can't contact the master; when it is given the master's configuration file.  Anyone with "D" series units will not be able to maintain an active/passive cluster in FIPS-CC mode.  An "emergency" code fix of FortiOS 5.0.10 is underway which will be released as 5.0.13.  We have been assured by FortiNet this will not affect the FIPS 140 certification of FortiOS.

[FatalHalt]

trauthor wrote:

There are multiple posts in this forum related to VIP policy compromising security.  I have opened cases with FortiNet both for this issue and an additional issue.  I have also alerted appropriate parties.  To FortiNet's credit, they are working quickly to address this.  I have not yet seen an official public statement from FortiNet.  Please refer to the below correspondence to see if it pertains to your situation.  Thank you.

Fantastic summary trauthor. From your post, I get the impression that Fortinet will be re-working the flow of traffic such that a deny would somehow take precedence, is this indeed the case?