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 endThese 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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
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.
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.
PCNSE
NSE
StrongSwan
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.
set match-vip enableYeap fmurrray get a big thumbs up. The set match-vip enable is so easily missed Some times you need a fresh set of eyes.
PCNSE
NSE
StrongSwan
The match-vip feature allows the FortiGate unit to log virtual IP traffic that gets implicitly dropped.
PCNSE
NSE
StrongSwan
...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?
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'
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1087 | |
752 | |
446 | |
226 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.