Best practice stopping attacks from outside

[btenberge]

I noticed the default action for the new "NAT Slipstreaming Detection" signatures are set to Alert.

How come they are not set to Drop or something else that stops this attack in its tracks?

Also, is there a best practice on protecting against attacks, such as this one, in general? Or does it come down to personal/company preference?

For example, do I create exceptions on the used Vulnerability Protection profiles and change the action there? Or is there a better way?

What would be the best and safest action to use in these cases, Drop, Block IP (client or server?), or Reset [client|server|both]?

When do I use Reset client, Reset server or Reset both and why do I use this instead of Drop or Block IP?

I read the documentation about the differences between these actions, but I still don't understand it enough to pick the right action all the time. I'm still thinking in dropping unwanted traffic the old fashioned way.

[mivaldi · Accepted solution]

When we produce signatures in a rush because the general public really needs a protection, we don't have the luxury of time to FP soak our signatures, so we release default actions that by default are not set to block, so that mission-critical environments can at the very least set their actions to 'default' without risking service downtime due to an unexpected false positive detection. For non mission critical environments we recommend as a best practice to reset-both on Critical, High and Medium severity threats, and to set action default on Low and Informational severity threats.

In this case, the reset-both action for Medium severity threats would override the default alert action that shipped in the signature metadata.

The best-best practice that comes to mind in general for any types of threats is to block by Regions. You can block countries that pose a high risk from initiating traffic to your organization. There has to be of course, a business decision taken before you can block a whole country from being able to reach your organization. As a second rule you can also look into blocking countries that your devices should not reach-out to.

In the case of the actions, - Drop, Block IP (client or server?), or Reset [client|server|both]? - It really depends on what you want to achieve.

In the case of a Drop, the client initiating the traffic will have no feedback as to what happened, so if there is an application that does not function due to a firewall protection, there will not be any type of packet that can be traced for troubleshooting. The added benefit is that because there is no response, threat actors will also not know if there is a device there or not. In the case of a RST they can deduce that you have a firewall blocking the request, which can be considered by some as reconnaissance.

A problem with Drops is that the client and server will also not have any clue as to what went wrong, so they may continue trying to communicate with TCP retransmissions for example. The user experience may be that the application has 'hanged' or that a download 'stalled' but there is no clear-cut immediate closure of the connection. Injecting a RST to the client helps the user see that the connection was refused, and there is more immediate feedback about the situation. In the case of a RST to the server, the server will free-up that TCP resource faster, so sending a reset to a server will increase its availability of resources.

A block-IP is a hardware accelerated discard. It sends the source IP to a blacklist for a set period of time. The difference is that it won't only block a given session, but it blocks any connections sourced from that IP for the set time lapse. This is better used for sources that are attempting volumetric type attacks such as brute force of network floods, where the rapid succession of packets can begin to exhaust the firewall or server resources.

[btenberge]

Thank you, Mivaldi, for this elaborate explanation and answer!

I suppose reset-xxx is kinda like the Linux iptables Reject equivalence, it makes so much more sense now.