- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
I had an interesting discussion with @soporteseguridad the other day where we tried to figure out some unexpected packets he was seeing on his external router.
The security policy was set to block all SMB packets, based on their service port, rather than the application. The external router, however, was still picking up packets with destination port 445 so we wanted to figure out why.
The firewall will treat sessions differently depending on how the security policy has been set up and which decissions have been made in favor of alternatives: When a policy is created to block a specific application, the only way for the firewall to find out which application is used in a specific session, is to let packets tricke through and a session to be established. Once the session has been established, the firewall will be able to identify an application based on the payload of the packets and how the session behaves. For example if the server sends a response 220 and the client replies with an ack, the application will be FTP, if the client sends out an HTTP GET, it's going to be web-browsing.
For this stage to be reached, however, the TCP handshake needs to be allowed through, even though the security policy eventually is set to block the application.
If the security policy is set to 'any' application and has only services (or another 'any' in the services) with the action set to drop, the SYN packets will be immediately dropped upon receipt because there is no need to identify the application,
One exception to this last policy behavior is when the securtity policy action is set to 'Deny'. This is where 'the devil is in the details':
The drop action simply drops all packets silently, the Deny action implies a reset action, which may be desirable in some scenarios, but there are also separate reset actions for each direction:
So what makes 'Deny' so special?
The 'Deny' action applies an action that is preferred per specific application. Some applications can be silently dropped after being identified while others may be better served by being sent a reset to terminate the session.
So, choose wisely when deciding which actions to apply to your security policies; several different ones are available to allow you more control over how to handle specific applications.
You can follow the original discussion here: PA SMB deny behaviour
Last year I had a similar discussion about the other options in the firewall action, you can check it here: reset-client vs. reset-server
Reaper out
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subject | Likes |
---|---|
5 Likes | |
3 Likes | |
2 Likes | |
2 Likes | |
2 Likes |
User | Likes Count |
---|---|
11 | |
2 | |
2 | |
2 | |
2 |