signature for oversize https request

[rttsui]

Hi, is there a way that we can trigger an alarm when a https request exceeds a certain size?

Can I define a state.http type signature using parameters like the following? Does MaxRequestFieldLength take into consideration the fragmentation of application data by ssl?

- Direction = ToService

- MaxRequestFieldLength = 1000000

- servicePorts = 443

- AlarmThrottle = FireOnce

- MinHits = 1

- ResetAfterIdle = 15

- ThrottleInterval = 15

- WantFlag = TRUE

If this does not work, would you please suggest alternatives. Thanks.

[mcerha]

You can't use the STATE.HTTP engine to make this work. HTTPS is encrypted, so the sensor can't decode it directly. You'll need to use the STRING.TCP engine instead with the MaxInspectLength parameter. Here's an example.

Tune Signature Parameters : CSIDS Signature Wizard

___________________________________________________________________________

Current Signature: Engine STRING.TCP SIGID 25331

SigName: Long HTTPS Request

___________________________________________________________________________

0 - Edit ALL Parameters

1 - AlarmInterval =

2 - AlarmThrottle = FireOnce

3 - ChokeThreshold =

4 - Direction = ToService

5 - FlipAddr =

6 - LimitSummary =

7 - MaxInspectLength = 1000000

8 - MinHits = 1

9 - MinMatchLength =

10 - MultipleHits =

11 * RegexString = [\x00-\xFF]*

12 - ResetAfterIdle = 15

13 - ServicePorts = 443

14 - SigComment =

15 - SigName = Long HTTPS Request

16 - SigStringInfo =

17 - StripTelnetOptions =

18 - ThrottleInterval = 15

19 - WantFrag =

d - Delete a value

u - UNDO and continue

x - SAVE and continue

___________________________________________________________________________

[pheuch]

Just for my understanding. [\x00-\xFF]* should be equivalent to .* which means every byte or no byte. MaxInspectLength specifies how many bytes are inspected to get a hit, correct ? With this RegEx I would say 1 byte will fire the event.

I would suggest to use MinMatchLength or .{10000} for the regex instead.

[mcerha]

Yes, you are correct about the MinMatchLength vs. the MaxInspectLength. Thanks for correcting me. In regards to the "[\x00-\xFF]*", it is not the same as ".*". The ".*" will terminate on a \x0D or \x0A character. But since we are trying to determine the length of an encrypted payload which might contain a random \n or \n character, we need to be able to consume them instead of terminating the search.

[rttsui]

It never occurred to me that I can use the String.* signature engines for encrypted data. Your solutions/comments make sense to me. Thanks very much!

[rttsui]

Hi, I have been playing with the signature a bit, but can't seem to get it working properly.

I tried variations of the following regex string together with the MinMatchLength parameter, and got either syntax errors or no alarm was triggered when it should:

[\x00-\xFF]*

[\x00-\xFF]+

[\x00-\xFF{1,}

The following pattern works fine, but the maximum valid repetition number (that won't result in a syntax error) seems to be 126 ?

[\x00-\xFF]{126}[\x00-\xFF] with MinMatchLength 126

We are running v.3.1(3)S33. Hope you can help again.

Thanks.

[mcerha · Accepted solution]

I looked into this, and it doesn't look like this is going to really be feasible using a custom signature. First, you need to use the STRING.TCP engine for this. The STATE.HTTP engine needs context information in the HTTP stream in order to function properly. Because HTTPS is encrypted traffic, we don't have those cues. So, we are basically left with trying to count bytes in a HTTPS stream. Two problems here. First, the regex implementation in STRING.TCP is limited to ~512 states for performance reasons. So, we can only build a pattern to match up to 512 or so characters. This is obviously insufficient to track the large patterns you want. Second, we need some kind of unique termination condition, a pattern of characters, to end the regex pattern with. Due to the random nature of characters in the encrypted HTTPS data, we don't have a guarantee that our terminator will not appear unexpectedly in the stream giving us no good way to determine we've reached the end of the search. This signature will probably need to be coded in a new engine.

[rttsui]

Thanks for looking into it, and for the detail analysis.

Please do include this signature in your future release plans.

Thanks again.