Deny All / Logging / Not Working

[dsammich]

Anyone,

(I apologize this is a long read, but I had to explain a few things)

I am writing this as to attempt to figure out what one must do in order to really apply a 'DENY ALL' inbound rule on the WAN / public facing side.  I have read countless posts about the DENY all really not being deny all unless you specifically add the match-vip enable to the rule and that works, but wait... there is more!

First a little back history - I am evaluating FG as a reseller.  We have sold countless competing brands with descent success, but margins and price points are a different story and issue, so I have decided to try FG.  We bought several models for testing and I also have a couple at home on my commercial Internet pipe I have in my home office.  All has seemingly gone well, until recently.

I am not running any VIPs at home, so there are no services NATd.  No web servers, special devices, nothing is NATd.  I am only using the firewall to NAT to the outside interface my internal subnets (I have a few such as VOIP, WIFI, office VLAN, home VLAN, etc).  Again, just basic NAT and firewall stuff, and L2L VPN.  That's it.

In the recent weeks, I moved my office devices (phone, laptops, wifi) over to the FG (61E with 5.6.2 code).  Again, all has gone well and no real issues... but wait, keep reading!

Several nights ago, my Polycom VOIP phone started ringing constantly and it continued throughout the night and into the next day.  I opened a ticket with our VOIP engineering team, and they added some lines of XML code to my extension's config to block for the "SIP Vicious" scanning.  Once this was done and I rebooted my phone, the ringing has stopped.

However, I asked our VOIP team for a clarification about why this occurred.  They stated improper firewall configuration on my end will cause this.  I was like, uh, hang on a minute.  All I did was move from behind another vendor to FG and all I have are outbound policies - nothing inbound from the WAN side at all.

Further, I have policy #1 being a deny all from anything accept the US only.  Meaning, I created a negate rule that basically denies all traffic accept anything sourced from the US to simply cut down on as much as I can.  I noticed the rule was never blocking anything (byte count not increasing) and then I found out about the set match-vip enable on the rule, but since I don't have VIPs, this doesn't do any good as the byte count has sat at nothing hardly at all.

So - where I am concerned here is why someone was able to scan my firewall and use this SIP Vicious script against my phone?  I have had this same phone for 3 years behind two other firewall manufacturers and never, ever had a single issue like this. 

I want to know what the heck is going on.  I have installed hundreds of firewalls and simply want to know why and how this happened?  Why the deny all isn't really a deny all unless I have a VIP and then it's only pertaining to those VIPs.

I can watch the other firewalls and see a constant stream of Internet traffic being dropped where the source is outside (public) and inbound to my outside interface.  On the FG I cannot see anything and I know there is a litany of traffic as I have had this same block of IPs for 10 years and I see a ton on my other firewalls but Fortigate.

Can someone shed some light on why I am not seeing dropped traffic on the outside interface of this FG?  I followed specific posts about the GEO blocking and negate rule I used.  I purposely setup a VIP of RDP to a laptop and this is where you see the 160 byte count in the graphic I attached, so i know it dropped traffic while I had this VIP active for testing.

Gang, this is nothing new here and surely isn't rocket science.  The GEO blocking I have done, I have installed time and time again on other brands and it works great (yes, it's not a end all be all and I get it, but when someone doesn't need any traffic sourcing from Europe, Asia, Russia - I eliminate it using the GEO IPs). 

I have attached a graphic of the policies I have and would be nice to see some thoughts because I am a bit concerned right now!

[tanr]

Are you logging denies by local-in-policy?  That is responsible for most outside traffic that initiates a connection directly to the firewall.

You probably need to make a local-in-policy duplicate of your policy.outside.usonly policy that blocks all IPs in the ipv4.storm7labs.blocking.usonly group to better protect the FortiGates public IPs.  That would be something like:

config firewall local-in-policy

    edit 0     set intf wan1     set srcaddr ipv4.storm7labs.blocking.usonly     set dstaddr all     set service "Svcs-LI-Block-For-Wan"

    set action deny     set schedule "always" end

NOTE: Read up on local-in-policy before you edit it!  You can easily lock yourself out if you misconfigure it.

You can find a bunch of info on it in the documentation and the forums.

Assuming you are running 5.4.x (I wouldn't recommend 5.6.x yet) the CLI commands to turn on logging for local-in-policy (and the default deny policy) is:

config log setting

    set fwpolicy-implicit-log enable

    set local-in-allow enable

    set local-in-deny-broadcast enable

    set local-in-deny-unicast enable

    set local-out enable

end

I can't remember the GUI area to turn on visibility for local-in-policy.  To set the GUI so you can see local-in-policy (though you can only edit it in the CLI) from the CLI enter:

config system settings

   set gui-local-in-policy enable

end

[dsammich]

Ok, Yes, saw the local-in-policy and wasn't quite sure of the FG implementation of it.  So, when I create a local-in policy, can you see it in the GUI?  I created one using the USonly src address, can see it in the CLI, but not the GUI.   Is this one of those pieces where FG is half baked again in the GUI?

[dsammich]

One other item to this local-in-policy where it may not work is I am able to negate the srcaddr in the other policy, doesnt look like I am able to use the negate commands on the local-in?  This would mean that I would have to list every country I wanted to block and build a group for them. Thats the entire purpose of the negate command?

[tanr]

BTW, instead of entering "edit 0" to create a new local-in-policy entry, you might want to enter a larger number so that you can easily separate logs that are by local-in-policy from logs that are by regular security policies.  I recently changed all mine to be of the form 100XX (so, 10010, 10050, etc.) so that I can easily differentiate which policy resulted in a log entry without having to check the logs policytype.

Note that when you're editing from the CLI, "show" will only show you elements of the current object that differ from default settings.  In local-in-policy, "set action deny" is the default, so you won't see it unless you use "show full".

Documentation on Local In Policy

http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-firewall-52/Concepts/Security%20Polic...

KB Article on Local In Policy

http://kb.fortinet.com/kb/documentLink.do?externalID=FD33649 

Packet Flow diagram which mentions Local In Policy near the end

http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-life-of-packet-54/lop-packet-flow-ing...

[tanr]

Yeah, local-in-policy display in the GUI does seem half-baked.  I wish I could easily see and edit it from the GUI.

As to negating the srcaddr for local-in-policy, I don't think local-in-policy has srcaddr-negate, dstaddr-negate, or service-negate.  Those could be very useful, though.  A good NFR (New Feature Request) to send to Fortinet.

Rather than negate, my local-in-policy starts with policies to allow just a few specific IPs or subnets for specific services, then has policies to deny all other IPs for those services.  Note that policies are evaluated in order, not by ID!

BTW, an advance warning about one other gotcha if you start using VIPs.  Make sure to read up on match-vip (one discussion that touches on it is https://forum.fortinet.com/tm.aspx?m=112129) as specific deny rules involving DNAT may not match to VIP IPs the way you would think.

[ali40]

Dear, 

Have you been able to solve the issue ?  I am experiencing the same kind of problem, empty inbound logs, and the logs are showing only my outbound denied traffic.  I managed to configure a VIP that is mapped to an internal IP and created a rule to deny that VIP and now I can finally see the inbound traffic towards my fortigate, however my VPN stopped working because of the newly added policy  !

Please share your experience in case you have find a way to figure out a solution to this problem. 

Regards

Ali 

[darwin_FTNT]

Fix for local-in policy without src/dst/service negate option has been committed to FortiOS v6.6 b2297 (mantis 0682470).

Currently it is available in the cli only, and gui support may be added later.

Another work around (for older FortiOS version) is to allow only a specific ip address to access in local-in policy is to create 2 policies:

config firewall local-in-policy

edit 1

set src test-src set service test-service set action accept

next

edit 2 

set src all set service test-service set action deny

next

Local-in firewall policy (config firewall local-in-policy) controls access to socket connections of daemon/processes running inside Fortigate devices (e.g, ipsec-vpn, fortiview, etc.). Forward policy (config firewall policy) are used to control access to sockets between clients and servers outside fortigate devices (e.g., the router have to "forward" the packet to the next destination).

Both firewall policies are hooked into the netfilter chain (a logical networking bus for packets passing in the kernel).