" 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

[FortiAdam]

I think what we' re all forgetting here is the fact that NAT rules apply before stateful packet inspection happens. If you want to block that traffic you need to make a rule that blocks it to that specific VIP. Here is a reminder of how ingress traffic is handled by the firewall: 1. Denial of Service Sensor 2. IP integrity header checking 3. IPSec connection check 4. Destination NAT 5. Routing and then it goes on to stateful packet inspection and security profiles.

[netmin]

Policy #53 doesn' t look too bad to achieve the same, given the definition of service " ALL" is still at it' s default.

[emnoc]

But he didn' t mention any of the above nor is that applicable on the rule that he posted? He need to do a diag debug flow and find what policy-ID is being match and then look at the ordering. Also policy ID #53 is at the top of the list has nothing to do with A VIP nor with NAT ( DNAT ) If we feel a " ." Is bad for an fw-address, than he can re-write the address with no dot, add it to the policy again and re-check. It' s really that simple.

[FortiAdam]

From emnoc:

But he didn' t mention any of the above nor is that applicable on the rule that he posted? He need to do a diag debug flow and find what policy-ID is being match and then look at the ordering. Also policy ID #53 is at the top of the list has nothing to do with A VIP nor with NAT ( DNAT )

I' m going to have to disagree with you on that emnoc. The policies that he is trying to keep the suspect IPs from using have a destination of " nat.inbound.xxx" which I can only surmise to be a VIP. As I said in my previous post which you attempted to discount, if you want to block traffic to a VIP you must make a specific policy for such because the policy ID 53 will never get hit before any policy with a VIP regardless of their order! Reconsider what you attempted to quote me on and decide whether it has validity or not. Based on the documentation provided by Fortinet, destination NAT will happen before any stateful packet inspection is done so that traffic will always be accepted unless you create a policy blocking traffic to that specific VIP. I can assure you that I have run into this exact issue in the past and was easily able to block certain source IPs only when using the specific VIP (or VIP group if you have a lot of them) as the destination. Policy 53 should really look like this: config firewall policy edit 53 set srcintf " wan1" set dstintf " dmz" set srcaddr " outside.blacklist.All" set dstaddr " nat.inbound.rounding" " nat.inbound.smtp" " nat.inbound.owa" " nat.inbound.rdsgate" " nat.inbound.remote" set action deny set schedule " always" set service " ALL" set logtraffic all next In most circumstances using " any" would be fine but in this case it appears Destination NAT is being used and in turn those policies will always get hit first before any normal stateful firewall policy.

[fmurray]

On the CLI, for each policy try adding: set match-vip enable. for example: #config firewall policy (policy)# edit 585 (585)# set match-vip enable (585)# show edit 585 set srcintf " External" set dstintf " COA_Internal" set srcaddr " attackers" set dstaddr " all" set schedule " always" set service " ANY" set logtraffic enable set match-vip enable

[emnoc]

set match-vip enable

Yeap fmurrray get a big thumbs up. The set match-vip enable is so easily missed Some times you need a fresh set of eyes.

[netmin]

This one sounds interesting, but according to what it does per documentation, it should not change how the policy in question is getting bypassed?

The match-vip feature allows the FortiGate unit to log virtual IP traffic that gets implicitly dropped.

[emnoc]

Actually that part of the definition here' s the full text per fortinet docs If you want to explicitly drop a packet that is not matched with a firewall polic y and write a log message when this happens, you can add a general policy (source and destination address set to ANY) to the bottom of a policy list and configure the firewall policy to DENY packets and record a log message when a packet is dropped. In some cases, when a virtual IP performs destination NAT (DNAT) on a packet, the translated packet may not be accepted by a firewall policy. If this happens, the packet is silently dropped and therefore not matched with the general policy at the bottom of the policy list. To catch these packets, enable match-vip in the general policy. Then the DNATed packets that are not matched by a VIP policy are matched with the general policy where they can be explicitly dropped and logged. So with this enable we can match the " all" with regardless of the VIP. It very easy to miss.

[netmin]

I don' t see what this text states differently

...If this happens, the packet is silently dropped and therefore not matched...To catch these...

So silently dropped or dropped explicitly with logging...or what?

[simonorch]

I'm bringing this one back up to add a couple of points as this behaviour is a real nasty 'gotcha' and i came across it for the first time this week.

It's not just a destination address of 'all' that wont get matched but any address object other than the VIP due to the behaviour described earlier with a DNAT VIP triggering a policy match before any other regular address object rules.

But the thing i really wanted to warn about is the default behaviour of a deny rule in 5.2.2 towards a website, which is to display a firewall notification in the browser. fair enough on the inside, but you don't want that being displayed to users on the outside\internet. I did a quick test on a box running 5.0.7 and an upgraded box on 5.2.2 and they don't display this behaviour, but on a 500D cluster i have with a customer which was installed with 5.2.2 from the ground up this was the default behaviour as per the cli guide, which states.

block-notification {enable | disable} Enable to display Fortinet Bar in browser when a site is blocked. Fortinet Bar must be enabled in firewall profile-protocol-options. enable

but which is enabled by default anyway even if the Fortinet bar isn't enabled

So, if you are using deny rules on the WAN side for websites, you need to add 'set block-notification disable'