reset-client vs. reset-server

[Sly_Cooper]

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?

[Brandon_Wertz · Accepted 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.

https://isc.sans.edu/forums/diary/Silent+Drop+vs+Reject+Firewall+rules/966/

[Brandon_Wertz]

Some other points to consider:

https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to-secur...

[reaper]

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

[Sly_Cooper]

---

@Brandon_Wertz wrote:

Some other points to consider:

https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to-secur...

---

The link is dead.

[Brandon_Wertz]

@Sly_Cooper hahaha, wow, it was active when I posted it.  Sorry about that

[Sly_Cooper]

Does anyone know what happens with the other side of the connection when you use reset-client or reset-server action?

[reaper]

The other side experiences a 'silent drop', meaning no notification is sent at all and the packets just dissapear.

[Sly_Cooper]

---

@reaper wrote:

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?

[reaper]

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)