Project

General

Profile

Actions
Copy link

Feature #3894

open

Option "ttl" exclusive range behavior is non-intuitive

Added by Jeff Barber about 4 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Community Ticket
Target version:
TBD
Effort:
Difficulty:
Label:

Description

The check for the "ttl" option when a range is specified is very non-intuitive.

Example:
ttl:33-64 A packet with TTL of 64 does NOT match. The check in the code (src/detect-ttl.c around line 87) is:

else if (mode == DETECT_TTL_RA && (pttl > dttl1 && pttl < dttl2))

Using ">=" and "<=", respectively -- the inclusive range -- would be much more intuitive (and compatible with snort).

Actions
Copy link
 #1

Updated by Philippe Antoine over 1 year ago

  • Tracker changed from Bug to Feature
  • Assignee set to Community Ticket
  • Target version set to TBD
  • Affected Versions deleted (5.0.3, 6.0.0beta1)

This is now the generic standard for all integer keywords cf DetectUintModeRange in the code

I guess it is easy to add a DetectUintModeRangeInclusive to the rust enumeration, add the matching logic, and add a parsing logic with a new way to specify this inclusiveness like <=>

Actions
Copy link

Also available in: Atom PDF