Project

General

Profile

Actions

Bug #404

closed

FN with suricata v121 and POP3 reply question

Added by rmkml rmkml about 12 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Hi,
Suricata not fire with this signature and joigned pcap file:
alert tcp any 110 -> any any (msg:"pop3 suricata reply"; flow:to_client,established; content:"-ERR"; nocase; depth:4; offset:0; classtype:misc-attack; sid:9116511; rev:1;)

but fire with this signature: (only changed depth)
alert tcp any 110 -> any any (msg:"pop3 suricata reply"; flow:to_client,established; content:"-ERR"; nocase; depth:53; offset:0; classtype:misc-attack; sid:9116511; rev:1;)

Im curious why first signature not fire ?
Of course, snort fire with two signatures.
Regards
Rmkml


Files

exemple_pop3_reply_suricata.pcap (1.08 KB) exemple_pop3_reply_suricata.pcap rmkml rmkml, 01/23/2012 02:04 PM
Actions #1

Updated by Anoop Saldanha about 12 years ago

rmkml rmkml wrote:

Hi,
Suricata not fire with this signature and joigned pcap file:
alert tcp any 110 -> any any (msg:"pop3 suricata reply"; flow:to_client,established; content:"-ERR"; nocase; depth:4; offset:0; classtype:misc-attack; sid:9116511; rev:1;)

but fire with this signature: (only changed depth)
alert tcp any 110 -> any any (msg:"pop3 suricata reply"; flow:to_client,established; content:"-ERR"; nocase; depth:53; offset:0; classtype:misc-attack; sid:9116511; rev:1;)

Im curious why first signature not fire ?
Of course, snort fire with two signatures.
Regards
Rmkml

This is not a bug per-se, but rather the way suricata works currently.

Suricata divides the payload inspection tasks into 2 parts and it's the same with sigs - sigs are divided as stream sigs, and sigs that require packet inspection(example dsize, id, flags, ack, etc.).

Now this sig you have here is a stream sig. Which means we will carry out inspection on the reassembled stream. Suricata has a default chunk size of 2560 which you can set from the yaml. Chunk size is the size of reassembled segments we would inspect. With the reassembled stream, offset and depth probably doesn't make much sense, which is why we don't see the first sig firing, since within this particular stream, "-ERR" doesn't lie in the first 4 bytes of the stream, but rather within the first 4 bytes of payload.

To test this, you can set the "toclient_chunk_size" to a small value, say 5 and see that the sig fires.

Actions #2

Updated by Victor Julien almost 12 years ago

  • Status changed from New to Closed
Actions #3

Updated by Anoop Saldanha almost 12 years ago

  • Assignee set to Anoop Saldanha
Actions #4

Updated by Anoop Saldanha almost 12 years ago

  • Target version set to 1.3beta2
Actions #5

Updated by Victor Julien almost 12 years ago

  • Status changed from Closed to Assigned
Actions #6

Updated by Victor Julien almost 12 years ago

  • Target version changed from 1.3beta2 to 1.3rc1
Actions #7

Updated by Anoop Saldanha almost 12 years ago

  • Status changed from Assigned to Resolved

This has been fixed now. You should see the alerts for the above case.

Suricata would now check every payload against offset/depth and the same applies for stream messages keeping in mind our app parsers evolving and being tuned to allow segment messages containing data pertaining to it's respective transaction, being inspected simultaneously along with it's transaction, in which case offset/depth inspection against it makes a lot of sense.

The patches are with Victor. Should see it shortly in the master.

Actions #8

Updated by Victor Julien almost 12 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF