How do you decide on the action for a particular threat? For drop, tcp will still retry. With recent what is the general practice, reset-both, reset-client or reset-server?
Solved! Go to Solution.
There's probably enough smart people on either fence to make a case for either deployment.
The old addage of "don't" respond is countered today with. "Well, if you don't get a response, you can probably assume there was a FW there." Also there comes the issue with resource exhaustion and just sending so much garabge traffic to a FW that it's having to account for the TCP sessions and sending those replies to source of the session.
It's really going to depend on your local security policy, your intent, and the "value" of what you're trying to protect.
in most cases i would probably only care for my internal resources, so for outbound connections i'd only reset the client's side and for inbound only the server's side. inside the organization a reset to both
The link is dead.
Some other points to consider:
The other side experiences a 'silent drop', meaning no notification is sent at all and the packets just dissapear.
So the remote side will "think" that the session is still ON and continue to send packets which will get dropped further?
Will it be advisable to use drop or reset-server in case of public facing dmz system? Reset-server will clean up the session on my server instead of waiting it to get cleaned after idle-timeout. Thoughts?
part of the consideration is also at which stage a session might get dropped:
-if you are going to block an application (say, facebook) a session already needs to have been started before we get to the point where we identify facebook and close the session
-if you are going to block a port (allow port 80 block everything else) the session gets stopped at the initial SYN packet
in the first scenario both parties have a socket dedicated to this connection, so receiving a reset allows either to free up the allocated resource faster. in the second scenario, only the client has an outbound socket, the server did not receive anything so has no resources in play
in the first scenario, you could decide if you want to let either side know and allow them to close the connection gracefully, in the second you only need to worry about the client (is it yours or not)
In case of a public facing DMZ you may want to mix things up a little and allow for legitimate clients that run into a block for some reason to receive a reset so their browser can pop up an error message while silently dropping ports that are not used to hamper port scans. a reset to the server can be useful if it is stretched for resources. (i'd also enable zone protection to ensure port scans are dealt with)
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 Live Community as a whole!
The Live Community thanks you for your participation!