blocking policy

[bfakhriddi]

I created address group with specific IPs of the ransomware group to block, created policy to block from WAN to LAN with that source address group. Do i need to move this policy to the top because of its more specific then others allowing policies? 

[emnoc]

ANS: yes

Did you run "diag debug flow" and see what policy-id is matching? Your new policy needs to be higher and more specific policy are always placed 1st

Ken Felix

[TecnetRuss]

Yes, the Deny policy needs to be at the top of the list because they are evaluated top down with the first (top-most) matching policy (Deny or Allow) being the policy that is applied, regardless of whether a more specific policy lower down also matches.

Also note that specifically for WAN to LAN policies where NAT is involved you have to also do one of two extra steps:

[ol]

If you have the policy's destination set to "all" the policy won't work unless you have "match-vip" enabled in the policy.  Right-click the policy in the list and select "Edit in CLI" then type "set match-vip enable" then "end".

Alternatively, set the destination of the policy to be your VIP object(s).[/ol]

Russ

NSE7

[bfakhriddi]

Yes I have destination set to all , but why do I need match-vip enabled if I dont have VIP setup? I have just a address group of 4 public ip to block coming from WAN.  

I found this one https://kb.fortinet.com/kb/documentLink.do?externalID=FD46540    has nothing about VIPs, confused. 

[TecnetRuss]

Assuming you're using IPv4 and NAT (public IPs on WAN side and private IPs on LAN site), if you don't have any VIP's set up then you probably don't need any WAN to LAN policies at all then.  A WAN to LAN deny policy isn't required or going to have any effect since all unsolicited inbound traffic is already denied.

If you're using IPv6 then "match-vip" isn't required.

Russ

NSE7

[bfakhriddi]

I aggre with u that evrything is denied unless you allow in firewall, but still  this https://www.mirazon.com/fortios-5-4-blocking-geographic-regions/   doesn't make any sense then? 

[TecnetRuss]

Those sorts of Deny policies make sense above other WAN to LAN VIP policies that allow unsolicited inbound traffic (port forwarding).

Here's the KB article that mentions match-vip:

Firewall does not block incoming (WAN to LAN) connection even though deny policy (fortinet.com)

If you don't have WAN to LAN policies then you can always block outgoing (LAN to WAN) traffic to unwanted countries or destinations too.  I also recommend using the Internet Services Database entries in the Destination of a Deny policy to block outgoing traffic to the following (may vary depending on your FortiOS version):

[ul]

Botnet-C&C.Server

Phishing-Phishing.Server

Spam-Spamming.Server

Malicious-Malicious.Server

Tor-Relay.Node[/ul]

Russ

NSE7

[emnoc]

On block and match-vip I wrote about this a few years back

http://socpuppet.blogspot.com/2016/02/this-is-reminder-for-set-match-vip.html

Ken Felix

[Toshi_Esumi]

Majority of ransomware is delivered in phishing email. Then if it's not filtered by something inspecting the content of email then the recipient of the email carelessly opened an attachment or click a link to download a ransomware, it would start copying itself to all reachable devices.

I don't know what kind of address list you got, but unless your address list is to block incoming email, I would apply whatever the blocking policy you created with the addresses to in-to-out direction to block any downloading from those sites.