Bug #4539
closedftp-data protocol not detected in autofp runmode
Description
The ftp-data protocol couldn't be detected by suricata in autofp runmode.
I use this ftp pcap file (input.pcap) as my test case:
https://github.com/OISF/suricata-verify/blob/master/tests/output-eve-ftp-data/input.pcap
If I use single runmode:
suricata -r input.pcap --runmode single
The eve.json file will contains ftp-data protocol
$ jq 'select(.app_proto == "ftp-data") | .fileinfo' eve.json
null
{
"filename": "temp.txt",
"sid": [
100010004
],
"gaps": false,
"state": "CLOSED",
"sha256": "db84caf61a8664263fe33a31aff60ca256f84ab1e88d70f753d0769b897f6252",
"stored": true,
"file_id": 19,
"size": 1164,
"tx_id": 0
}
If I use default runmode, which is autofp
suricata -r input.pcap --runmode autofp
The eve.json file contains no ftp-data protocol at all:
$ jq 'select(.app_proto == "ftp-data") | .fileinfo' eve.json # empty result
Here is the build info:
This is Suricata version 6.0.2 RELEASE
Features: 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: none
Atomic intrinsics: 1 2 4 8 byte(s)
64-bits, Little-endian architecture
GCC version 9.3.0, C version 201112
compiled with _FORTIFY_SOURCE=2
L1 cache line size (CLS)=64
thread local storage method: _Thread_local
compiled with LibHTP v0.5.37, linked against LibHTP v0.5.37
Suricata Configuration:
AF_PACKET support: yes
eBPF support: no
XDP support: no
PF_RING support: no
NFQueue support: yes
NFLOG support: no
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: yes
hiredis async with libevent: yes
Prelude support: no
PCRE jit: yes
LUA support: yes, through luajit
libluajit: yes
GeoIP2 support: yes
Non-bundled htp: yes
Hyperscan support: yes
Libnet support: yes
liblz4 support: yes
Rust support: yes
Rust strict mode: no
Rust compiler path: /usr/bin/rustc
Rust compiler version: rustc 1.48.0
Cargo path: /usr/bin/cargo
Cargo version: cargo 1.46.0
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: yes
Profiling enabled: no
Profiling locks enabled: no
Plugin support (experimental): yes
Development settings:
Coccinelle / spatch: no
Unit tests enabled: no
Debug output enabled: no
Debug validation enabled: no
Generic build parameters:
Installation prefix: /usr
Configuration directory: /etc/suricata/
Log directory: /var/log/suricata/
--prefix /usr
--sysconfdir /etc
--localstatedir /var
--datarootdir /usr/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: yes
CFLAGS -g -O2 -fdebug-prefix-map=/build/suricata-jYUFp4/suricata-6.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -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
Updated by Victor Julien over 4 years ago
This is because in autofp mode these flows will run in their own threads, and they just run their packets as fast as possible. This can cause packets from the data channel to be processed before the packets from the control channel. In single mode this won't happen and in real traffic scenarios with workers this shouldn't happen either, unless some threads are extremely congested.
Updated by Victor Julien over 3 years ago
- Has duplicate Bug #5205: FTP-data unrecognized depending on multi-threading added
Updated by Victor Julien over 3 years ago
- Related to Bug #3728: ftp file extraction failure added