Support #3833
closedSuricata 'content' keyword does not match on IP header data
Description
I'm tried matching an IP packet using the 'content ' keyword.
The IP header starts at offset 0xE, the "Packet ID" field is 0xabcd
at offset 0x11 and "flags" are 0x20, at offset 0x14
The rule I wrote is that, and it does not alert on the packet below:
alert ip any any -> any any (msg:"test"; priority:1; content:"|ab cd 20|"; sid:11005081;)
0000 f4 a9 97 d4 4e 62 08 00 27 8f 8a 93 08 00 45 00 ....Nb..'.....E. 0010 00 2c ab cd 20 00 40 04 2b 6e c0 a8 01 75 c0 a8 .,.. .@.+n...u.. 0020 00 cd 4f 00 00 64 00 01 00 00 40 00 72 97 7f 00 ..O..d....@.r... 0030 00 01 7f 00 00 01 00 00 00 00 ..........
However, If I try to match on bytes in the end of the IP header - the destination address "192.168.0.205" - "c0 a8 00 cd"
using the same type of rule rule
alert ip any any -> any any (msg:"test"; priority:1; content:"|c0 a8 00 cd|"; sid:11005081;)
I do get a an alert. Any idea why matching on the beginning of the IP header does not work, but on the end of the IP packet it does ?
-----------------------------------------
build info
root@tal-VirtualBox:/# suricata --build-info This is Suricata version 5.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 MAGIC RUST SIMD support: none Atomic intrinsics: 1 2 4 8 byte(s) 64-bits, Little-endian architecture GCC version 7.4.0, C version 199901 compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 thread local storage method: __thread compiled with LibHTP v0.5.32, linked against LibHTP v0.5.32 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 Old barnyard2 support: no 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.39.0 Cargo path: /usr/bin/cargo Cargo version: cargo 1.39.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 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) / gcc (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-8VZoRR/suricata-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -I${srcdir}/../rust/gen/c-headers PCAP_CFLAGS -I/usr/include SECCFLAGS -fstack-protector -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security root@tal-VirtualBox:/#
Updated by Victor Julien over 4 years ago
- Tracker changed from Bug to Support
- Description updated (diff)
Updated by Andreas Herz almost 3 years ago
- Status changed from New to Closed
Hi, we're closing this issue since there have been no further responses.
If you think this issue is still relevant, try to test it again with the
most recent version of suricata and reopen the issue. If you want to
improve the bug report please take a look at
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Reporting_Bugs