[Oisf-devel] Problem identifying direction correctly for app-layer preprocessor

[Adrian Falk]

Found and fixed problem (for my app layer module) as follows when
ProbingParser sees toclient packet as first packet:

In AppLayerParserRegisterParserAcceptableDirection() call from my app layer
module, make third parameter equal to (STREAM_TOCLIENT | STREAM_TOSERVER),
earlier I had it as only (STREAM_TOSERVER) and it couldn't deal with seeing
a toclient packet as first packet.

Modbus developers may want to make a similar change to deal with an
unsolicited packet from client as first packet seen by Suricata.

Thanks.



On Mon, Jan 5, 2015 at 6:10 PM, Adrian Falk <adrianfalk2 at gmail.com> wrote:

> I could use help on how Suricata deals with app-layer protocol packets
> when its sees a toclient packet as the first protocol packet.
>
> 1. From looking at the debug logs, for my new app-layer-protocol, I
> observe that in the registered ProbingParser if the first protocol packet
> seen is toclient then the registered Parse function is never invoked and no
> "app layer state" is allocated. Also, the registered ProbingParser is never
> invoked for the other direction. In short, Suricata fails to inspect any of
> these protocol packets even though it sees them and logs them at the TCP
> layer.
>
> 2. Anoop mentioned that this functionality needs to be implemented. Is
> there an example of such functionality implemented? If not are there any
> plans to implement?
>
> Thanks.
>
> On Sun, Dec 28, 2014 at 4:01 PM, Adrian Falk <adrianfalk2 at gmail.com>
> wrote:
>
>> Thanks Anoop.
>>
>> Is there an example of how to implement what you suggest?
>>
>> From what I see, the field 'first_data_dir' would need to be reset
>> appropriately after parsing the packet to identify direction. But where
>> should this protocol specific functionality be implemented (to parse
>> packet) that also has access to the structure containing 'first_data_dir'.
>> Or, is there some other easier way?
>>
>> Thanks.
>>
>> On Sun, Dec 28, 2014 at 11:33 AM, Anoop Saldanha <anoopsaldanha at gmail.com
>> > wrote:
>>
>>> On Sun, Dec 28, 2014 at 12:30 AM, Adrian Falk <adrianfalk2 at gmail.com>
>>> wrote:
>>> > I'm working on an app-layer preprocessor for a TCP-based protocol,
>>> modeled
>>> > after Modbus.
>>> >
>>> > While running different traffic through my app-layer preprocessor I
>>> notice
>>> > while replaying certain capture files the protocol packets identified
>>> are in
>>> > the wrong direction (a to-server packet is identified as a to-client
>>> > packet). I have also noticed that for certain other capture files the
>>> > preprocessor doesn't successfully identify any protocol packets
>>> although
>>> > such packets are present.
>>> >
>>> > I'm running Suricata as follows:
>>> > suricata -c /etc/suricata.yaml -r protocol.pcap
>>> >
>>> > I'm using suricata.2.0.4 with mostly default settings except I'm
>>> running
>>> > with 'midstream equal to true'.
>>> >
>>> > What function in RegisterXParsers() ensures that the protocol packets
>>> are
>>> > identified successfully and in the correct direction?
>>> >
>>>
>>> If you are picking the flow up midstream, there is no way atm to
>>> reverse the direction, if the stream layer sees the wrong direction
>>> first.  That's something that needs to be implemented along with
>>> picking the statrt offset for the next full/new app layer record, in
>>> the stream, so that the app layer parser can initiate parsing from
>>> that offset.
>>>
>>> --
>>> -------------------------------
>>> Anoop Saldanha
>>> http://www.poona.me
>>> -------------------------------
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20150106/833ad046/attachment-0002.html>