New Member

Solved

" deny" rule getting bypassed

Forum|Forum|12 years ago
August 8, 2014
34 replies
73370 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

emnoc

New Member

What I would do is to run diag debug flow against a known entry or temporary add an entry into the addr-group Generate traffic inbound to a service and 1 > see what fwpolicy-ID is being match 2> see if it matches or hit the fwpolicy for the blacklist ( policyID 53 ) Yo do know that you have another means for blacklist traffic by GEO-IP depending on code.

FatalHalt

New Member

Edit: Oops, misread the original post and saw that you showed what policy 42 was. Other thing I would do would be look in your logs and filter by policy 53, see if there is ANY traffic that gets matched to it.

Rick_HAuthor

New Member

Emnoc, the only reason I haven' t debugged is because I thought my rules were cut and dry. Silly I know. This will be my next step. FatalHalt, Nothing shows up in the logs matching against policy 53. :/ Netmin, I' ve always used dots in my names without issue, but I will try renaming the relevant objects. I' m willing to try anything at this point.

netmin

New Member

I just saw all these dots in the names and remembered this and would replace them by - or _ (better don' t use spaces).

A name can contain numbers (0-9), uppercase and lowercase letters (A-Z, a-z), spaces, and the special characters - and _

FatalHalt

New Member

I would normally agree, your rules look fine from this side, though it' s possible some of the geo stuff isn' t playing well, haven' t done much with that myself. I would start debugging per Emnoc' s post. I' ve always used dots in my names as well, didn' t realize it was against convention.

netmin

New Member

While it may appear to work (for you), this statement:

Improper naming can cause problems that are hard to diagnose.

tells me to not even consider using different special characters, as results seem to be unpredictable.

emnoc

New Member

I don' t use " ." ( dots ) also but don' t think that' s the problem. What I do per fortinet BCP is, you don' t use or let me say you can' t uses certain characters; & Ampersand alligator mouth greater or lesser < > ' single or " double quotes These are typically XSS vulnerability characters, and depending on fortios version, it will warn you of such e.g The string contains XSS vulnerability characters I don' t believe a " dot " is a XSS vulnerability character. It' s been that way for ages iirc maybe Ede will shed some light and wisdom.

netmin

New Member

It is not so much about XSS but rather to rule out an unknown variable. While speculative to a certain degree, comments in this forum, i.e. here, indicate that things can get messed up quickly. Just imagine what happened if the labels/names get truncated at illegal characters, under certain conditions, when the text configuration is compiled into the running config...you never known unless you have written the configuration parser.

ede_pfau

SuperUser

The docs clearly state that these characters are allowed: a-z A-Z 0-9 space - (minus) _ (underscore) There are input field where other chars are allowed (even [<>" ' ]) because it needs to be, e.g. LDAP names, or passwords. This has been in place since at least v3.00 and has (to my knowledge) not altered up to 5.0 and 5.2. Edit: While this may be the official intention we have seen a LOT of trouble if spaces are used in object names. Sometimes accepted by the GUI they are not handled well during runtime. I' d say there is a widespread agreement to avoid spaces in names altogether, just to not have to try and error if it works in a particular case or not.[/Edit] So in short: while " ." (dot) is not explicitely disallowed it is not allowed generally. Of course, in FQDN you will want to use it, and you can. BEST PRACTICE would be to stick to the allowed chars in naming. Be aware that different objects have length limitations as well! One quite funny would be the name of a phase 1 IPsec VPN in Interface Mode which is used as a Dial-In VPN. FortiOS will append " _<n>" for each concurrent tunnel, and so with 10 or 100+ tunnels you may cross the length limit for an interface (which is 16 chars). Those higher numbered tunnels will never connect... Lately with FOS 5.2 Fortinet has switched from static length identifiers to dynamically allocated names. Which may or may not be a good thing (every magic comes at a price). If available, one could have a look at the " Maximum Values" matrix for FOS 5.2 to see if object name length limits have changed as well.

FortiAdam

New Member

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

New Member

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

emnoc

New Member

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

New Member

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

New Member

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

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO