Logging, local-in-policy, and weirdness

[tanr]

A question re local-in-policy, logging, security policies, and possibly zones.

We've got two ISPs, so separate wan interfaces for each, collected into a zone for firewall rules.  Local in policy blocks (or should block) a number of services (like telnet) to these wan interfaces, like so:

config firewall local-in-policy edit 1     set intf "wan-zn"     set srcaddr "all"     set dstaddr "all"     set action deny     set service "Svcs-LI-Block-For-Wan"     set schedule "always"     set status enable end

I still see a bunch of logs blocking these services, where the policy ID usually matches one of our lan_to_wan policies, but sometimes matches the default deny policy.

Questions:

[ol]

My understanding is that when local-in-policy blocks something, there is no log entry created.  Correct?

I assume the logs I'm seeing are for attacks from the wan that are attempted as part of a session initiated from our lan, since otherwise they should be getting blocked by either the local-in-policy or the default deny policy, not the lan_to_wan policies? 

How would the telnet attempts, for example, have gotten through to where the default deny rule had to handle them, as opposed to local-in-policy?

Any suggestions on how to track this backwards?  For example, I'd like to figure out specific websites users are visiting that then use the connection to try such an attack.  I'd really like to figure out the attacks that seem to be bypassing local-in-policy which are getting blocked by the default deny.[/ol]

Thanks.

[packetpusher]

The local-in policy is used to restrict/ allow access to services residing on the firewall only.

[emnoc]

You need to  enable logging  for local-in-policies

e.g

set local-in-allow enable

[ede_pfau]

As already posted, local-in policies are only effective for traffic reaching one of the FGTs port addresses, i.e. the WAN address. They are meant to restrict access to the FGT management servers, which could be HTTP, HTTPS, SSH or telnet. Notice that you cannot specify a destination interface like in a regular policy - the destination is always the FGT itself.

In order to attack an internal server you would need to allow incoming traffic in the first place. That is, a policy from WAN to LAN. This is quite uncommon and usually requires a VIP to translate a public destination address to an internal, private address. You usually handle all security in this policy.

If there is no policy allowing some sort of traffic (even inbound) then it will hit the implicit final DENY policy, policy 0.

As far as I can see it, your problem is that you've allowing traffic in. Note that you do not need an inbound policy to allow traffic replies - policies allow/deny session setup, not traffic. You can surf the web from the LAN with an outbound policy only.

[tanr]

I checked my config log setting, and I've already got local-in-allow (and local-in-deny-broadcast and local-in-deny-unicast) enabled, as well as fw-policy-implicit-log.  So it looks like local-in-policy denies (and allows) should all be getting logged.

Looking at my local-in-policy, I have a guess for what I'm seeing.  I think the local-in-policy logs and the regular security policy logs both just write their policyid into the log.  The confusion was that my main local-in-policy deny rule and the main firewall lan_to_wan rule both have the same policy ID.  So in the logs it all looks the same.

I'll change the policy ids for my local-in-policy to be separate and identifiable and see what that gives me.  Will post my findings after I test this.

Regardless, I'm still seeing occasional denies for services that local-in-policy should be blocking, which are instead getting caught by the the default deny rule (policy ID of 0).  I would like to track backwards to find out how those are getting there.

[tanr]

@ede_pfau, our responses just crossed paths there.  I don't have an inbound wan_to_lan policy as we aren't hosting any servers.  And my local-in-policy denies most of what would hit the FortiGate from the wan directly, only allowing VPN connections from specific IPs.

I think the issue was/is simply the policyid for rules in the local-in-policy matching policyid for regular firewall rules.

[tanr]

Yep, that was it.  Logging just puts in a policyid field so the default display of the logs doesn't show any difference between local-in-policy and normal firewall policies.

I should have looked at the raw logs, which do have a  policytype field which is set to either "local-in-policy" or just "policy".

I've changed my policyid numbers for local-in-policy so its easy to tell them apart from the rest of the logs.

After filtering the rest out, I now think I see why I was getting some logs showing TELNET getting blocked by policyid=0 (default deny).  Those logs actually were local-in-policy logs (they had policytype=local-in-policy).  They were getting caught by, I assume, the local-in-policy default deny (whose policyid I can't unfortunately change).  The reason they fell through was that they were targeting a currently unused public IP for which I didn't have explicit local-in-policy rules.

[packetpusher]

Good catch! Always check with the raw logs