" deny" rule getting bypassed

Forum|Forum|11 years ago
August 8, 2014
21 replies
73357 views

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

Vs55852.jpg

Best answer by Dave_Hall

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

Show previous replies

trauthor

New Member

FYI

Congrats to the O.P. who started this thread and all those who responded. Please see a snippet of the official response from cert.org (the place US-CERT vulnerability requests go) pertaining to the rule precedence / match-vip documentation gap. Please note also that FortiNet has corrected the documentation, which was re-published on 6/15.

-----BEGIN PGP SIGNED MESSAGE----- [...]

Hello [redacted],

While we [...] do not intend to publish a vulnerability note on this issue, we have taken the following actions:

1) We have made US-CERT aware of the issue to notify potentially affected US departments and agencies.

2) We have sent Fortinet our recommendation that in addition to the documentation updates, they should notify their customers.

In response, Fortinet said that they will "take the necessary steps to document the issue more clearly."

Regards,

[redacted] Vulnerability Analysis Team ======================================================================

CERT Coordination Center [...]

djwilliams

New Member

I was hoping for some clarification on one point. The implicit Deny "ALL" at the bottom is always matched regardless of any policy or policy order above it correct? If it makes it to the bottom of the policy list without matching something it will match the implicit. Is it safe to say then that "match-vip" is disabled by default on all policies EXCEPT the implicit deny?

Marcelo_Clementeen

New Member

Thanks for the feedback.
My question is:
I need the port2 (WAN) of the fortigate to make available the public 5 ips, because I can only ping the ip when enabled in the interface configuration of Fortigate. 
Being from within the fortigate I can ping all public IPs, but only outside the gateway (200.222.166.1). 
Thank you for your help

Sign up

Login with SSO

Login to the community

Login with SSO