Bug #4702
openSYN/ACK dropped when client does not support tcp 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 about 2 years ago
- Assignee set to OISF Dev
- Target version set to 8.0.0-beta1
Updated by Victor Julien 6 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 3 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 7 days 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 7 days 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 5 days ago
Do you have a pcap of a complete session like this?
Updated by Victor Julien 1 day 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