Firewall Action

[vvserpent]

Hi,

The security auditor came to our office to check the Firewall Policies.  The guy suggests to configure the Firewall Access Rule to "DROP" the unwanted traffic instead of "DENY". 

When setup Firewall Access Rule, I can select "ACCEPT" or "DENY" only.

Is it possible to configure the Fortinet Firewall do "DROP" instead of "DENY" ? 

Regards,

[ede_pfau]

As far as I know packets are dropped silently when they match a DENY policy. If the auditor envisions that denied traffic always terminated by a RST handshake, and dropped traffic is just discarded without any answer, then FOS uses implicit DROP policies.

This is quite easily confirmed by sniffing the destination interface.

[omega]

Like so many things this seems possible via CLI.

Look into:

http://kb.fortinet.com/kb....do?externalID=FD36465

[ede_pfau]

Nice find!

In the article they state "TCP - will send TCP Reset like before". So by default TCP is denied by sending an RST (not silently dropped as I presumed.

The rest of the article describes how to make denials more verbose by invoking an ICMP message - just the opposite of what OP is looking for.

[omega]

Not sure if the article really is correct.

You might have try and sniff the traffic to be sure.

[romanr]

The Article seems to be a bit misleading....

A Fortigate will alway DROP traffic with default configuration when DENY is specified!

TCP RST and ICMP unreachable will only happen, when explicitly configured!

Br,

Roman

[vvserpent]

Hi,

The auditor using the nmap to scan the NAT-IP / Interface IP on the Firewall and found the Firewall "REJECTED" the access to the Port-8000.  I don't have Port-8000 configured on the associated IP addresses, those access denied by the Firewall default rule.  

I tied to access the port-8000 of the NAT IP and found it is rejected immediately. 

Hence I ask question on the Firewall Action. 

[emnoc]

What is he  trying to hit ? A local  address ? or  VIP ?  or something behind the firewall?

The only  actions allow are accept or deny ( no drop ) . I would double check in sys global that you don't have  "set reset-sessionless-tcp enable" just to be sure nothing weird is going on

FTNT suggestion status == disable for this set variable in global and that should be the default btw.

FWIW;

Packets should be silent drop if no matching fwpolicy if you have the action DENY it could send RST back to the originator,  but I believe that behavior is  current for current FortiOS versions.

You can easy test this behavior by or the expect results by executing the following;

1: setting a fwpolicy with a DENY and send a TCP syn an look for the reset ( yes|no ....should be a NO )

2: next send a TCP syn after  removing the deny ( no RST will be sent to originator )

3: reapply fwpolicy in item#1 but change the status to disable in the firewall policy and re-check for any  TCP-RST

( repeat all against a fwpolicy with a VIP  as the dstaddr )

During the above  and by using the    diag sniffer packet as indicate in the article, BUT you really should  be using the   diag debug flow ( it's your friend ) & by inspecting the final action by looking for the   action of drop  == drop for the fwpolicyid that's being  inspected, that would  ensure the flow is dropped ( silently btw )

It will also  show you any tcp-syn and any thing sent back to the client.

And lastly make sure you do this with no IPS sensors , or anything that might trigger the  firewall to send a client-side RST which is also a bad  practice to deploy  btw .

BTW never heard of a auditor nmap a firewall. They should stick to what they know best and not thinking they know what a firewall is or does  or how a FGT works ;)

[vinch100]

I had the same question while migrating from a Juniper SSG to a Fortigate : some rules on the Juniper where on Deny and some on Reject... here are the diag sniffer output with different options (FortiOS 5.2.8, trace date : 23 aug 2016) : DENY, default configuration => Fortigate drops the packet 1.078313 192.168.1.53.63832 -> 1.1.1.1.443: syn 4173360399 2.008337 192.168.1.53.63833 -> 1.1.1.1.443: syn 1676512847 2.050116 192.168.1.53.63835 -> 1.1.1.1.443: syn 2467315773 3.050474 192.168.1.53.63836 -> 1.1.1.1.443: syn 684741667 "send-deny-packet enable" => Fortigate sends a TCP-Reset 97.416539 192.168.1.53.65347 -> 1.1.1.1.443: syn 478702364 97.416557 1.1.1.1.443 -> 192.168.1.53.65347: rst 0 ack 478702365 97.506485 192.168.1.53.65346 -> 1.1.1.1.443: syn 3910892227 97.506498 1.1.1.1.443 -> 192.168.1.53.65346: rst 0 ack 3910892228 97.507918 192.168.1.53.65348 -> 1.1.1.1.443: syn 1161633155 97.507927 1.1.1.1.443 -> 192.168.1.53.65348: rst 0 ack 1161633156 "deny-tcp-with-icmp enable" and "send-deny-packet enable" => Fortigate sends an ICMP unreachable packet 1.975005 192.168.1.53.63809 -> 1.1.1.1.443: syn 196952655 1.975022 1.1.1.1 -> 192.168.1.53: icmp: host 1.1.1.1 unreachable - admin prohibited filter 1.975024 1.1.1.1 -> 192.168.1.53: icmp: host 1.1.1.1 unreachable - admin prohibited filter 2.064487 192.168.1.53.63807 -> 1.1.1.1.443: syn 3013198366 2.064506 1.1.1.1 -> 192.168.1.53: icmp: host 1.1.1.1 unreachable - admin prohibited filter 2.064507 1.1.1.1 -> 192.168.1.53: icmp: host 1.1.1.1 unreachable - admin prohibited filter

I hope this helps

[emnoc]

Good post. keep in mind the default is to silently drop ( quiet ). Sending  TCP_resets or icmp would be noise  and could be DoS since those packets are sent by the firewall causing waste of CPU cycles.

I believe you have a global setting to enable sending of tcp-reset  still ( have to check ) also  tcp_resets would not be applicable for non TCP/protocol for the obvious reason.

IMHO you will never ever send a tcp reset for a deny policy ( I can't think of one validate case that would warrant it )

ken