Matching on numerical content that is vaiable

Rules
1

Hi

I’m trying to match on some content that can be varible. So the contect could be;

ID=1234, something else
or
ID=12345, something else
or
ID=1, something else
or
ID=12345678, something else

I could only see using regex for RPC traffic, is there a way to use regex like logic to then match on ‘ID=’ and then any number, i can then match on ‘, something else’.

many thanks

2

Hi Graham,

If I am understanding the question, ID= is static and the numerical values after are variable?

Up to what length are the numerical values?

Such content would generally speaking be sigged content wise like, content:"ID="; pcre:"/^[0-9]{1,8}/R";

the ^ indicating the beginning of the content to be matched, it is always a good idea to anchor (^ or $ for example) any pcre in signatures.

the [0-9] being the numbers expected (this ideally would be only the numbers you would expect in the field and not just a blanket 0-9).

the {1,8} is the number of times the [0-9] is expected to match. I just used the number based on what you used for examples above. Said another way this is essentially a lower and upper range for the preceding content to match.

Hopefully that helps

JT

3

Hi JT

Thanks for taking the time to reply.

JT>If I am understanding the question, ID= is static and the numerical values after are variable?

Correct

JT>Up to what length are the numerical values?

I it’s probably going to be like between 6 and 10 digits. I don’t know exactly at the moment.

I wasn’t clear, but this traffic isn’t pcre, it’s just some XML running over a TCP socket. Will the pcre in the signature still be valid ? I assumed that this was ONLY for pcre traffic ?

I’ll be testing this next week, so can validate the signaute then.

many thanks

4

pcre is just a way to match any range of content, regardless of protocol (e.g. http, tls, smb, rpc). So for you case, XML traffic over a tcp socket should work just fine.

Also, if I could suggest to keep in mind, for performance reasons, try to limit the port(s) in the signature (if this is just going to be raw tcp and not http or other parsed protocol) and try to use a good fast_pattern so you do have suricata checking too many packets unnecessarily.

JT

5

Hi JT

Thanks, I incorectly thought that I could only match PCRE traffic :slight_smile:

Really appreciate the help here.

many thanks