13.2. TCP Settings

Home Prev	cOS Core 14.00.17 Administration Guide	Next

TCP Option Sizes

Verifies the size of TCP options. This function acts in the same way as IPOptionSizes described above.

Default: ValidateLogBad

TCP MSS Min

Determines the minimum permissible size of the TCP MSS. Packets containing maximum segment sizes below this limit are handled according to the next setting.

Default: 100 bytes

TCP MSS on Low

Determines the action taken on packets whose TCP MSS option falls below the stipulated TCPMSSMin value. Values that are too low could cause problems in poorly written TCP stacks.

Default: DropLog

TCP MSS Max

Determines the maximum permissible TCP MSS size. Packets containing maximum segment sizes exceeding this limit are handled according to the next setting.

Default: 1460 bytes

Using the TCP MSS Max setting is also discussed in relation to MTU issues in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324736206

TCP MSS VPN Max

As is the case with TCPMSSMax, this is the highest Maximum Segment Size allowed. However, this setting only controls MSS in VPN connections. This way, cOS Core can reduce the effective segment size used by TCP in all VPN connections. This reduces TCP fragmentation in the VPN connection even if hosts do not know how to perform MTU discovery.

This setting must be less than the maximum IPsec MTU size and the maximum packet size handled by the Ethernet interface.

Default: 1400 bytes

TCP MSS On High

Determines the action taken on packets whose TCP MSS option exceeds the stipulated TCPMSSMax value. Values that are too high could cause problems in poorly written TCP stacks or give rise to large quantities of fragmented packets, which will adversely affect performance.

Default: Adjust

TCP MSS Log Level

Determines when to log regarding too high TCP MSS, if not logged by TCPMSSOnHigh.

Default: 7000 bytes

TCP Auto Clamping

Automatically clamp TCP MSS according to MTU of involved interfaces, in addition to TCPMSSMax.

Default: Enabled

TCP Zero Unused ACK

Determines whether cOS Core should set the ACK sequence number field in TCP packets to zero if it is not used. Some operating systems reveal sequence number information this way, which can make it easier for intruders wanting to hijack established connections.

Default: Enabled

TCP Zero Unused URG

Strips the URG pointers from all packets.

Default: Enabled

TCP Option WSOPT

Determines how cOS Core will handle window scaling options. These are used to increase the size of the window used by TCP; that is to say, the amount of information that can be sent before the sender expects ACK. They are also used by OS Fingerprinting. WSOPT is a common occurrence in modern networks.

Default: ValidateLogBad

Note that the issues that can arise with TCP window scaling is further discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324735770

The article also discusses the TCP window scale log event.

TCP Option SACK

Determines how cOS Core will handle selective acknowledgment options. These options are used to ACK individual packets instead of entire series, which can increase the performance of connections experiencing extensive packet loss. They are also used by OS Fingerprinting. SACK is a common occurrence in modern networks.

Default: ValidateLogBad

TCP Option TSOPT

Determines how cOS Core will handle timestamp options. As stipulated by the PAWS (Protect Against Wrapped Sequence numbers) method, TSOPT is used to prevent the sequence numbers (a 32-bit figure) from "exceeding" their upper limit without the recipient being aware of it.

This is not normally a problem. Using TSOPT, some TCP stacks optimize their connection by measuring the time it takes for a packet to travel to and from its destination. This information can then be used to generate resends faster than is usually the case. It is also used by OS Fingerprinting. TSOPT is a common occurrence in modern networks.

Default: ValidateLogBad

TCP Option ALTCHKREQ

Determines how cOS Core will handle alternate checksum request options. These options were initially intended to be used in negotiating for the use of better checksums in TCP. However, these are now rarely used and generally not understood by modern systems. cOS Core cannot understand checksum algorithms other than the standard algorithm.

Note that this TCP option is made obsolete by RFC-6247 and only some network equipment will make use of it.

Default: StripLog

TCP Option ALTCHKDATA

Determines how cOS Core will handle alternate checksum data options. These options are used to transport alternate checksums where permitted by ALTCHKREQ above. Normally never seen on modern networks.

Note that this TCP option is made obsolete by RFC-6247 and only some network equipment will make use of it.

Default: StripLog

TCP Option CC

Determines how cOS Core will handle connection count options.

Note that this TCP option is made obsolete by RFC-6247 and only some network equipment will make use of it.

Default: StripLogBad

TCP Option Other

Specifies how cOS Core will deal with TCP options not covered by the above settings. These options usually never appear on modern networks.

Default: StripLog

TCP SYN/URG

Specifies how cOS Core will deal with TCP packets with SYN (synchronize) flags and URG (urgent data) flags both turned on. The presence of a SYN flag indicates that a new connection is in the process of being opened, and an URG flag means that the packet contains data requiring urgent attention. These two flags should not be turned on in a single packet as they are used exclusively to crash computers with poorly implemented TCP stacks.

Default: DropLog

TCP SYN/PSH

Specifies how cOS Core will deal with TCP packets with SYN and PSH (push) flags both turned on. The PSH flag means that the recipient stack should immediately send the information in the packet to the destination application in the computer.

These two flags should not be turned on at the same time as it could pose a crash risk for poorly implemented TCP stacks. However, some Apple MAC systems implement TCP in a non-standard way, meaning that they always send out SYN packets with the PSH flag turned on. This is why cOS Core normally removes the PSH flag and allows the packet through despite the fact that such packets would be dropped if standards were strictly followed.

Default: StripSilent

TCP SYN/RST

The TCP RST flag together with SYN; normally invalid (strip=strip RST).

Default: DropLog

TCP SYN/FIN

The TCP FIN flag together with SYN; normally invalid (strip=strip FIN).

Default: DropLog

TCP FIN/URG

Specifies how cOS Core will deal with TCP packets with both FIN (Finish, close connection) and URG flags turned on. This should normally never occur, as it is not usually attempted to close a connection at the same time as sending "important" data. This flag combination could be used to crash poorly implemented TCP stacks and is also used by OS Fingerprinting.

Default: DropLog

TCP URG

Specifies how cOS Core will deal with TCP packets with the URG flag turned on, regardless of any other flags. Many TCP stacks and applications deal with Urgent flags in the wrong way and can, in the worst case scenario, cease working. Note however that some programs, such as FTP and MS SQL Server, nearly always use the URG flag.

Default: StripLog

TCP ENC

Specifies how cOS Core will deal with TCP packets with either the Xmas or Ymas flag turned on. Setting this to the value StripLog will strip these flags.

Default: Ignore

TCP Reserved Field

Specifies how cOS Core will deal with information present in the "reserved field" in the TCP header, which should normally be 0. This field is not the same as the Xmas and Ymas flags. Used by OS Fingerprinting.

Default: DropLog

TCP NULL

Specifies how cOS Core will deal with TCP packets that do not have any of the SYN, ACK, FIN or RST flags turned on. According to the TCP standard, such packets are illegal and are used by both OS Fingerprinting and stealth port scanners, as some firewalls are unable to detect them.

Default: DropLog

TCP Sequence Numbers

Determines if the sequence number range occupied by a TCP segment will be compared to the receive window announced by the receiving peer before the segment is forwarded.

TCP sequence number validation is only possible on connections tracked by the state-engine (not on packets forwarded using a FwdFast rule set entry).

Possible values are:

Ignore - Do not validate. Means that sequence number validation is completely turned off.
ValidateSilent - Validate and pass on.
ValidateLogBad - Validate and pass on, log if bad.
ValidateReopen - Validate reopen attempt like normal traffic; validate and pass on.
ValidateReopenLog - Validate reopen attempts like normal traffic; validate, log if bad.
ReopenValidate - Do not validate reopen attempts at all; validate and pass on.
ReopenValidLog - Do not validate reopen attempts at all; validate, log if bad.

Default: ValidateLogBad

Notes on the TCPSequenceNumbers setting:

The log messages tcp_seqno_too_high and tcp_seqno_too_low are generated when out of sequence packets are detected. If sequence validation is turned off, these messages will not be generated. This is discussed further in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324735772
The default ValidateLogBad (or the alternative ValidateSilent) will allow the de-facto behavior of TCP reopen attempts, meaning that they will reject reopen attempts with a previously used sequence number.
ValidateReopen and ValidReopenLog are special settings giving the default behavior found in older cOS Core versions where only reopen attempts using a sequence number falling inside the current (or last used) TCP window will be allowed. This is more restrictive than ValidateLogBad/ValidateSilent, and will block some valid TCP reopen attempts. The most significant impact of this will be that common web-surfing traffic (short but complete transactions requested from a relatively small set of clients, randomly occurring with an interval of a few seconds) will slow down considerably, while most "normal" TCP traffic will continue to work as usual.
Using either ValidateReopen or ValidateReopenLog is, however, not recommended since the same effect can be achieved by disallowing TCP reopen attempts altogether. These settings exist mostly for backwards compatibility.
ReopenValidate and ReopenValidLog are less restrictive variants than ValidateLogBad or ValidateSilent. Certain clients and/or operating systems might attempt to use a randomized sequence number when reopening an old TCP connection (usually out of a concern for security) and this may not work well with these settings. Again, web-surfing traffic is most likely to be affected, although the impact is likely to occur randomly. Using these values instead of the default setting will completely disable sequence number validation for TCP reopen attempts. Once the connection has been established, normal TCP sequence number validation will be resumed.

Allow TCP Reopen

Allow clients to reopen TCP connections that are in the closed state. Using this setting is also discussed in a Clavister Knowledge Base article at the following link:

https://kb.clavister.com/354856423

Default: Disabled

TCP SYN Fragmented

This setting determines how a fragmented SYN packet is handled. By default, such packets are dropped and a log message generated. Changing this setting to Ignore or Log means that fragmented TCP SYN packets are acceptable and this could make a denial-of-service (DOS) attack more successful since the full TCP handshake would not have to be completed.

Default: DropLog

TCP SYN with data

This setting determines how a SYN packet with an accompanying data payload is handled. Such a packet is unusual and does not comply with the RFCs but can occur in rare circumstances when equipment tries to send data more efficiently. By default, such packets are dropped and a log message generated. Note that the TCP SYN Fragmented check is processed before this check.

Default: DropLog