03-22-2018 06:24 AM
I found some best practices documentation on the fuel group site and they recommend drop over deny. So I would be interested to see how people are configuring their fire wall more drops or denies and why?
03-22-2018 07:21 AM
A drop is silent, you simply discard the packet and don't tell anyone about it. This is great for most siatuations as you don't generate more traffic on your network and outsiders who may potentially be scanning you are non the wiser
A deny sends a notification to the sender that something happened and their packet was rejected
This could be helpful in providing a 'friendly' user experience as some applications will be able to pop up an error message telling the user their connection was rejected (instead of timing out, causing the user to have to wait and possibly keep trying), and tell applications to stop trying to connect.
My inbound rules are all drop while my outbound ones are deny (for rules that only trigger on App-ID, eg. "block ftp", you can also pick from 'reset-client', 'reset-server' and 'reset-both' depending which ones are 'internal' and deserve a notification)
I wrote a couple things regarding this, fyi:
https://live.paloaltonetworks.com/t5/Tutorials/Configurable-Deny-Action/ta-p/76613
03-22-2018 07:21 AM
A drop is silent, you simply discard the packet and don't tell anyone about it. This is great for most siatuations as you don't generate more traffic on your network and outsiders who may potentially be scanning you are non the wiser
A deny sends a notification to the sender that something happened and their packet was rejected
This could be helpful in providing a 'friendly' user experience as some applications will be able to pop up an error message telling the user their connection was rejected (instead of timing out, causing the user to have to wait and possibly keep trying), and tell applications to stop trying to connect.
My inbound rules are all drop while my outbound ones are deny (for rules that only trigger on App-ID, eg. "block ftp", you can also pick from 'reset-client', 'reset-server' and 'reset-both' depending which ones are 'internal' and deserve a notification)
I wrote a couple things regarding this, fyi:
https://live.paloaltonetworks.com/t5/Tutorials/Configurable-Deny-Action/ta-p/76613
03-22-2018 07:41 AM
Don't fear the reaper !! So I guess it good for load on your firewall and stretches the days of logs out but could reduce information
03-22-2018 07:42 AM
yes there are many pages on this stuff...
we opted for similar to @reaper.
untrust to trust... drop
trust to untrust, mostly drop but with a few overlapping policy denies for specific hosts and users
for trust to untrust diagnostics, deny (block all policy session start... not logging to paranormal) is a must, as and when required..
i prefer this to messing around with the default zone policies...
03-22-2018 08:00 AM
Are you referring to the zone protection policies when you say default zone policies?
03-22-2018 08:08 AM
No sorry...
the intrazone-default and interzone-default security policies .
you can overide these and enable logging but i prefer to use my own policy to "block all" from my test PC IP address.
if i see any traffic using this policy, then i know one of the many above it is not working properly.
if you get my drift...
03-22-2018 11:01 AM
Great info as always @reaper
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
