Jason Ish [Wed, 10 Jun 2026 22:53:57 +0000 (16:53 -0600)]
ftp: add active and passive data tests
Some observations:
- On the data channel, ftpdata_command:retr matches in the to_client
direction, for passive and active.
- On the data channel, ftpdata_command:stor matches in the to_server
direction. This matches the direction of the file, but it is the
client that send the STOR request. Does this make sense?
- On the data channel, file_data matches in the direction of the TCP
connection to differs for active and passive mode. This almost seems
counter intuitive to how ftpdata_command works. But a direction is not
required here so I'm not sure it matters much to rule writers.
pcap-file-stdin: read pcap from stdin via /dev/stdin
Feed a one packet pcap into Suricata via /dev/stdin to exercise the
non-seekable file handling fix in OISF/suricata#15384 for Bug #8464.
Without the fix InitPcapFile calls setvbuf on the FILE underlying the
pcap handle after libpcap has already consumed the pcap header, glibc
cannot recover on a non-seekable fd, the first pcap_next_ex returns
-1, and no packets are decoded.
The test overrides the default invocation with a command that pipes
input.pcap into Suricata reading from /dev/stdin. The rule alerts on
a deterministic content match in the TCP payload, and the check
asserts that exactly one alert with sid 1 lands in eve. On the pre
fix code the run produces zero alerts and the test fails. On the
fixed code one alert is observed and the test passes.
dhcp: add overload-3 test using Wireshark canonical capture
Companion to dhcp-option-52-overload (overload value 2, sname only). This adds a second test using PRIV_bootp-both_overload.pcap from the Wireshark sample collection, which exercises overload value 3 (both sname and file overloaded) on a single DHCP DISCOVER -- the canonical
reference capture for BOOTP option overload.
The Wireshark sample only carries Option 56 (DHCP Message) in the overloaded areas, which the EVE DHCP logger does not currently emit, so this test does not assert on the overloaded-area content itself. It does verify the parser cleanly processes a real-world overload=3 packet without dropping the event and that the inline-option fields (dhcp_type, id, client_mac, lease_time) still surface correctly -- a regression guard for the Option 52 overload code path. Bug: #8538.
Add a verification test that runs Suricata over a pcap where the server places dns_servers, routers and a domain inside the BOOTP sname continuation area while flagging Option Overload (52) value 2 in the standard options block. The test asserts that the EVE DHCP events for both the OFFER and the ACK now expose those
overloaded values and that the parallel non overloaded flow in the same capture still reports its inline values.
These test the engine's behavior with ips acting as firewall-like, and
with the introduction of the firewall mode, were ambiguous, in the
firewall directory.
Jason Ish [Sun, 10 May 2026 19:41:37 +0000 (21:41 +0200)]
tls: add pre8 issuer zero lua test
Add a pre-8 variant based on tests/tls/tls-issuer-zero, modified to
enable a Lua TLS rule for certificate info access with an issuer
containing a zero.
tests/lua-sandbox-alloclimit-bypass: regression test for LuaAlloc ptr==NULL alloc_limit bypass
The ptr==NULL (new allocation) path in LuaAlloc does not check
alloc_limit before allocating. A single large string.rep() call
bypasses the configured security.lua.max-bytes limit while the
realloc path (ptr!=NULL) correctly enforces it.
Test asserts:
- no alert fires (script should be blocked by limit)
- stats.detect.lua.memory_limit_errors == 1
Both assertions fail on affected versions (7.0.15, 8.0.4).
Fix: add alloc_limit check to ptr==NULL path in util-lua-sandbox.c
Ticket: #8507
[Modifications by JI]
- Set min-version to 9; remove lua as a requirement.
- Add ticket number.
Jason Ish [Fri, 29 May 2026 21:19:02 +0000 (15:19 -0600)]
tests: test for delayed tx clean with pass rule
Ticket: #8619
A memory leak is not directly assertable, so the accumulation is made
observable through a parser that bounds its live transactions. The pcap
is a single CLDAP (LDAP-over-UDP) flow with four complete
request/response pairs plus three trailing requests with no response.
With ldap.max-tx lowered to 4, correct cleanup frees each completed pair
and the live-transaction list never exceeds the cap. Under the bug the
completed transactions are never freed, the list grows past max-tx, and
the LDAP parser raises too_many_transactions, logged as an anomaly
record independent of detection (which is why it survives the pass
rule).
The check asserts the too_many_transactions anomaly is absent: the test
fails on the buggy code and passes once cleanup is fixed.
Add a firewall regression test for default app-layer accept:tx policies with
HTTP pipelining.
The pcap contains a full TCP conversation where two HTTP requests are carried
in the same client packet. The firewall defaults accept the first transaction
at request-complete with accept:tx, while a request_line rule should still
inspect and block the second transaction.
The test expects the /foo/ request to produce the drop alert. Current affected
Suricata branches miss that alert because the default accept:tx for the earlier
transaction accepts the packet and bypasses inspection of the later
transaction.
test: check for untested keywords in firewall mode
Add suricata-verify tests for keywords that emit 'has not been tes
for firewall rules' warnings. Tests are consolidated into 3 test cases.
- firewall-keyword-icode: tests icode with ICMP echo traffic
- firewall-keyword-http: tests pcre, urilen, dataset with HTTP traff
- firewall-keyword-tls: tests tls.cert_chain_len with TLS cert chain
These tests validate that the keywords function correctly in firewal
mode and can be used to justify adding SIGMATCH_SUPPORT_FIREWALL to
each keyword in the engine.
Jeff Lucovsky [Tue, 21 Apr 2026 14:46:05 +0000 (10:46 -0400)]
tests: add test cases for bug 8489
Issue: 8489
Three test cases:
- bug-8489-01: two commands with max-tx=1 (limit exceeded) raises the
too_many_transactions anomaly and fires the corresponding alert.
- bug-8489-02: six commands under max-tx=10 raise no anomaly and no
alert (negative regression).
- bug-8489-03: burst of commands exceeding the limit followed by a new
command after a server response — verifies the flow keeps parsing
after the event fires, so later commands are still logged.
Each test has a response_command_too_long rule alongside the
too_many_transactions rule so the to_client FTP parsing path stays
active; without a to_client app-layer-event signature Suricata skips
response parsing and the max-tx check does not fire.
Flowbits are used in this test to control the number of alerts per signature.
They were removed under the incorrect assumption of being unnecessarily
used as they were not checked anywhere.
projects / thirdparty / suricata-verify.git / log
