Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Equipe_reseau
Participant

Find the TCP-out-of-state packets

Jump to solution

Hello all,

Can you help me to find the TCP out of state packets inside the logs ? It relates to the long story. Before, we "uncheck" drop tcp out of state packets, to allow them pass via the firewall. Now, we would like to enhance security by enabling drop tcp out of state packet but we need to identify which connection is currently out of state in order to add inspection exception

 

Thank you very much.

 

More information: The security gateway is in version R80.30

0 Kudos
1 Solution

Accepted Solutions
Timothy_Hall
Champion
Champion

I think this kernel variable may allow you to monitor packets that are out of state (even if they aren't dropped), but it does not appear to be documented.  Use at your own risk or perhaps ask TAC, default value is 0:

fw_tcp_out_of_state_monitor = 0

Edit: My guess (confirm this with TAC) is that if this variable is set to 1 and both "drop out of state TCP" and "log on drop" is checked, out of state TCP packets will be logged but not actually dropped as the enforcement is placed in "monitor" mode. 

This could be an interesting technique for sites that have had "drop out of state TCP" unchecked for a long time, and are afraid to recheck it because of what it might break.  If my guess is correct the  "drop out of state TCP" and "log on drop" boxes could be checked in that situation, and this variable set to 1.  This would allow kind of a "preview" of what would happen in the logs if the checkbox was to be rechecked, but without actually breaking anything.  

 

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com

View solution in original post

0 Kudos
5 Replies
Vladimir
Champion
Champion

Those should be dropped by default, if you did not change the "Global Properties -> Stateful Inspection -> Drop Out of state TCP packets" property.

If you are not seeing those in the logs it may be because your "catch all" rule is not configured to log, or that you are not logging Implied rules (also, a settings in "Global Properties").

0 Kudos
Equipe_reseau
Participant

Hi Vladimir,

Thank you for your reply.

Yes, the default behavior for TCP out of state packets is dropped. However, it has been a while we allowed them passing via our firewall. Now, due to security requirement, we would like to track which source/dest (connections) is out-of-state, adđing exception into protocol inspection then enable the drop

Thank you

0 Kudos
Vladimir
Champion
Champion

You may better track the cause for the out of state packets, perhaps look into the asymmetric routing issues and improper antispoofing.

This being said, do look into logging for the Implied rules (should be enabled), catch-all  drop logging and the logging setting on specific rules.

That last one, may perhaps, need to be set "per connection" instead of session to log the out of state packets.

 

0 Kudos
Equipe_reseau
Participant

Hi,

Thus that i need to enable logging on implies rules ? but at the moment, all the tcp out state packets are not dropped, we must identify which connection is out of state first, then add per network and enable the global drop

Thank you

0 Kudos
Timothy_Hall
Champion
Champion

I think this kernel variable may allow you to monitor packets that are out of state (even if they aren't dropped), but it does not appear to be documented.  Use at your own risk or perhaps ask TAC, default value is 0:

fw_tcp_out_of_state_monitor = 0

Edit: My guess (confirm this with TAC) is that if this variable is set to 1 and both "drop out of state TCP" and "log on drop" is checked, out of state TCP packets will be logged but not actually dropped as the enforcement is placed in "monitor" mode. 

This could be an interesting technique for sites that have had "drop out of state TCP" unchecked for a long time, and are afraid to recheck it because of what it might break.  If my guess is correct the  "drop out of state TCP" and "log on drop" boxes could be checked in that situation, and this variable set to 1.  This would allow kind of a "preview" of what would happen in the logs if the checkbox was to be rechecked, but without actually breaking anything.  

 

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com

View solution in original post

0 Kudos