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 9 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 6 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 3 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 3 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 3 months ago
Do you have a pcap of a complete session like this?
Updated by Victor Julien 3 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 3 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 3 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 3 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