topic Re: reset-client vs. reset-server in General Topics

reset-client vs. reset-server

Sly_Cooper — Wed, 20 Apr 2016 19:06:30 GMT

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?

Re: reset-client vs. reset-server

Brandon_Wertz — Wed, 20 Apr 2016 20:10:27 GMT

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/

Re: reset-client vs. reset-server

Brandon_Wertz — Wed, 20 Apr 2016 20:17:24 GMT

Some other points to consider:

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

Re: reset-client vs. reset-server

reaper — Thu, 21 Apr 2016 12:15:24 GMT

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

Re: reset-client vs. reset-server

Sly_Cooper — Thu, 28 Apr 2016 16:21:33 GMT

@Brandon_Wertz wrote:
Some other points to consider:

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

The link is dead.

Re: reset-client vs. reset-server

Brandon_Wertz — Fri, 29 Apr 2016 12:48:43 GMT

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

Re: reset-client vs. reset-server

Sly_Cooper — Tue, 03 May 2016 14:14:28 GMT

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

Re: reset-client vs. reset-server

reaper — Tue, 03 May 2016 14:17:24 GMT

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

Re: reset-client vs. reset-server

Sly_Cooper — Tue, 03 May 2016 17:08:35 GMT

@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?

Re: reset-client vs. reset-server

reaper — Wed, 04 May 2016 08:08:04 GMT

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)