Bug #4702
closedtcp: SYN/ACK dropped when client does not support timestamps
Description
Description:¶
Seems to be introduced by the fix of the following issue.
https://redmine.openinfosecfoundation.org/issues/3286
Basically, when the client sends a TCP SYN without timestamps, and the SYN/ACK contains the timestamps, then suricata rejects the SYN/ACK packet.
The intention of the original fix seems to avoid the "faked" RST/ACK or FIN/ACK to be seen by suricata as the end of flow, but also seems to reject legit ACKs from a server that does support tcp timestamps to a client that does not.
Steps to reproduce:¶
- Have the tcp timestamps turned off (on linux that is sysctl -w net.ipv4.tcp_timestamps=0)
 - Run the following curl command over suricata in IPS mode to initiate a connection to a Microsoft server.
curl -v 'https://vlscppe.microsoft.com
 - Wait for the connection timeout
 
Log:¶
[2340] 23/9/2021 -- 04:50:14 - (stream-tcp.c:1397) <Debug> (StateSynSentValidateTimestamp) -- ssn 0x7fd2e46240e0: BAD TSECR echo 1 recv 0
Also attached the pcap, not very useful but to see the tcp options of the SYN, and SYN/ACK.
Build info:¶
This is Suricata version 6.0.3 RELEASE
Features: DEBUG UNITTESTS NFQ PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LUA HAVE_LUAJIT HAVE_LIBJANSSON TLS TLS_C11 MAGIC RUST 
SIMD support: SSE_4_2 SSE_4_1 SSE_3 
Atomic intrinsics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 10.2.1 20210110, C version 201112
compiled with -fstack-protector
compiled with _FORTIFY_SOURCE=2
L1 cache line size (CLS)=64
thread local storage method: _Thread_local
compiled with LibHTP v0.5.38, linked against LibHTP v0.5.38
Suricata Configuration:
  AF_PACKET support:                       yes
  eBPF support:                            yes
  XDP support:                             yes
  PF_RING support:                         no
  NFQueue support:                         yes
  NFLOG support:                           yes
  IPFW support:                            no
  Netmap support:                          no 
  DAG enabled:                             no
  Napatech enabled:                        no
  WinDivert enabled:                       no
  Unix socket enabled:                     yes
  Detection enabled:                       yes
  Libmagic support:                        yes
  libnss support:                          yes
  libnspr support:                         yes
  libjansson support:                      yes
  hiredis support:                         no
  hiredis async with libevent:             no
  Prelude support:                         no
  PCRE jit:                                yes
  LUA support:                             yes, through luajit
  libluajit:                               yes
  GeoIP2 support:                          yes
  Non-bundled htp:                         no
  Hyperscan support:                       yes
  Libnet support:                          yes
  liblz4 support:                          yes
  HTTP2 decompression:                     no
  Rust support:                            yes
  Rust strict mode:                        no
  Rust compiler path:                      /root/.cargo/bin/rustc
  Rust compiler version:                   rustc 1.55.0 (c8dfcfe04 2021-09-06)
  Cargo path:                              /root/.cargo/bin/cargo
  Cargo version:                           cargo 1.55.0 (32da73ab1 2021-08-23)
  Cargo vendor:                            yes
  Python support:                          yes
  Python path:                             /usr/bin/python3
  Python distutils                         yes
  Python yaml                              yes
  Install suricatactl:                     yes
  Install suricatasc:                      yes
  Install suricata-update:                 not bundled
  Profiling enabled:                       no
  Profiling locks enabled:                 no
  Plugin support (experimental):           yes
Development settings:
  Coccinelle / spatch:                     no
  Unit tests enabled:                      yes
  Debug output enabled:                    yes
  Debug validation enabled:                no
Generic build parameters:
  Installation prefix:                     /suricata/install
  Configuration directory:                 /etc/suricata/
  Log directory:                           /var/log/suricata/
  --prefix                                 /suricata/install
  --sysconfdir                             /etc
  --localstatedir                          /var
  --datarootdir                            /suricata/install/share
  Host:                                    x86_64-pc-linux-gnu
  Compiler:                                gcc (exec name) / g++ (real)
  GCC Protect enabled:                     yes
  GCC march native enabled:                no
  GCC Profile enabled:                     no
  Position Independent Executable enabled: no
  CFLAGS                                   -DUNITTESTS -march=sandybridge -std=c11 -I${srcdir}/../rust/gen -I${srcdir}/../rust/dist
  PCAP_CFLAGS                               -I/usr/include
  SECCFLAGS                                -fstack-protector -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
  Files
Updated by Philippe Antoine over 2 years ago
- Assignee set to OISF Dev
 - Target version set to 8.0.0-beta1
 
Updated by Victor Julien 8 months ago
- Status changed from New to Assigned
 - Assignee changed from OISF Dev to Victor Julien
 - Priority changed from Normal to Low
 - Target version changed from 8.0.0-beta1 to 8.0.0-rc1
 
Updated by Victor Julien 5 months ago
- Priority changed from Low to Normal
 - Target version changed from 8.0.0-rc1 to 9.0.0-beta1
 
Updated by Victor Julien 2 months ago
- Status changed from Assigned to Feedback
 
This seems to be compliant to RFC 7323
A TCP MAY send the TSopt in an initial <SYN> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in <SYN,ACK> only if it received a TSopt in the initial <SYN> segment for the connection. Once TSopt has been successfully negotiated, that is both <SYN> and <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST> segment for the duration of the connection, and SHOULD be sent in an <RST> segment (see Section 5.2 for details).
https://datatracker.ietf.org/doc/html/rfc7323#section-3.2
Any reason to be more liberal that this?
Updated by tug tugtug 2 months ago
Victor Julien wrote in #note-4:
This seems to be compliant to RFC 7323
[...]
https://datatracker.ietf.org/doc/html/rfc7323#section-3.2Any reason to be more liberal that this?
We encountered this issue while some traffic to servers owned by Microsoft violates the RFC, thus felt like this might be a widespread issue.
I guess one could argue that it is up to Microsoft to fix their server, but at the end of day, customers are impacted because of suricata being in the path, so we had to loose the check on this one.
Updated by Victor Julien 2 months ago
Do you have a pcap of a complete session like this?
Updated by Victor Julien 2 months ago
- Status changed from Feedback to In Review
 - Target version changed from 9.0.0-beta1 to 8.0.1
 - Label Needs backport to 7.0 added
 
Updated by tug tugtug about 2 months ago
- File tsecr.pcap tsecr.pcap added
 
I attached a pcap.
One can also reproduce this in a linux vm/container with:
sudo sysctl -w net.ipv4.tcp_timestamps=0 curl https://vlscppe.microsoft.com
Updated by Victor Julien about 2 months ago
- Status changed from In Review to Resolved
 
https://github.com/OISF/suricata/pull/13817
Thanks @steventang , I've turned the pcap into this test https://github.com/OISF/suricata-verify/pull/2646/commits/7265011b80eca99f657b6d4da71426366d602958
Updated by Victor Julien about 2 months ago
- Subject changed from SYN/ACK dropped when client does not support tcp timestamps to tcp: SYN/ACK dropped when client does not support timestamps
 
Updated by Victor Julien about 2 months ago
- Status changed from Resolved to Closed