Deny All / Logging / Not Working

Question

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 · Answer

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

Sign up

Login with SSO

Login to the community

Login with SSO