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

TCP Segment limit enforcement

Does anyone have any details regarding "TCP Segment limit enforcement" is? We are running R80.10 take 70 on all devices.

We recently had an issue where our Checkpoint was causing a slowdown in all traffic, which was solved by failing over the cluster. 

After that I was looking through the logs and saw millions of matches on the IPS protection "TCP Segment limit enforcement".

We did not have any network events, or loops, during this issue. Some traffic would make it fine, as it was seemingly random as to what the Checkpoint would drop.

I did find a seeming related SK but it is only for R77: sk114529

Traffic is dropped by IPS protection "TCP Segment Limit Enforcement" due to attack "TCP segment out ... 

6 Replies
PhoneBoy
Admin
Admin

The SK is still relevant for R80.10 (even though it is not marked as such).

Threat
Description
For every TCP segment that passes through the Security Gateway, the Security Gateway 
retains a copy of the segment until it receives an acknowledgment that the segment was received.
This buffered data occupies space in the Security Gateway's memory.
IPS Protection
Description
This IPS protection enforces a limit on the number and size of buffered segments per connection.
When a connection reaches one of these limits, the Security Gateway will not accept new segments
for this connection until buffered segments are acknowledged.

Bottom line: IPS is "holding" some TCP traffic back until the remote end acknowledges receipt.

Most TCP/IP stacks handle this situation ok, so applications may not notice an issue (except perhaps as a delayed response).

0 Kudos
Michael_Gonnaso
Participant

Interesting. Ok so it does apply.

What is the risk we are attempting to mitigate or control with this IPS protection?

I understand you wouldn't want hosts to send more data than the window, but a host generally would reject the extra data anyways. Same with unacknowledged data.

PhoneBoy
Admin
Admin

Some TCP/IP stacks don't handle this overflow condition gracefully Smiley Happy

Also you might be able to figure out what the remote IP stack is by playing with these windows.

0 Kudos
Michael_Gonnaso
Participant

Ok awesome, thank you for the information.

It sounds like it is best for inspecting traffic from external sources, and generally not all internal traffic.

Always assess your risks and understand what the protection is mitigating/controlling. 

Albert_Wilkes
Collaborator

Regarding impact after disabling a protection: I believe to have read somewhere and/or logically think that disabling this protection will basically allow an attacker to bypass ALL your layer 7 protections in URLF, APCL, IPS, DLP, AV etc.. This is because you would allow passthrough of packets (i.e. bytes, URLs, malware) that contain data that the CP parser can't put into context anymore. Say a signature for an attack that you configured in IPS to block TCP traffic consists of 10bytes, the way to bypass a protection would be to send the first (say) 9 bytes, then transmit enough data to exceed the sliding window buffer in the firewall's TCP implementation (say 32kb), then send the last byte of the 10bytes. They would potentially be reassembled by the communication partner which doesn't have to deal with thousands of simultaneous sessions and therefore might have a much bigger TCP receive window.

Happy to be proven wrong...

On another note, I seem to work with some customers that only saw this protection being triggered from R80.10 but we're still investigating.

0 Kudos
Trey_Havener
Participant

Is there any way to bypass this protection between 2 gateways in a tunnel?  One of our remote sites is having all kinds of issues with this being triggered by a couple of different applications.  The Gateway at the remote site is a 1470 running 77.20.85 which is fairly up to date for that model. But that's not the side triggering it.  Our 5400s seem to be the ones barking about it which are running 80.20 Take 47.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events