[Oisf-devel] Problems detecting app-layer session (re-sending as smaller size email)

[Adrian Falk]

Any progress on fixing this evasion issue where Suricata does not
successfully detect app-layer session for a registered port?  I just
brought up the latest Suricata code from git and still see this issue.

Is there a bug# so I can track this issue?

Thanks.

On Thu, Mar 19, 2015 at 10:22 AM, Adrian Falk <adrianfalk2 at gmail.com> wrote:

> I believe the following will work:
>
> -simple port number: if a tcp port is a registered port, then its the
> corresponding app-layer protocol (what you mentioned)
> -app-layer-detection: if  the registered port is tcp dest-port then its
> to-server, if registered port is tcp src-port then its to-client
>
> Thanks.
>
> On Sat, Mar 14, 2015 at 5:53 AM, Victor Julien <victor at inliniac.net>
> wrote:
>
>> Sorry for the late reply.
>>
>> On 02/15/2015 04:06 PM, Adrian Falk wrote:
>> > I'm having trouble detecting an app-layer session for a registered port.
>> > This only happens when the pcap file I feed to Suricata has the
>> > following characteristics/errors as shown below in the Wireshark output
>> > below. With a clean pcap file there is no issue.
>> >
>> > The following two packets (21 and 25) from Wireshark capture shows the
>> > packets Suricata sees as the first 2 packets for this session. Packet
>> > (21) is actually to-server but Suricata classifies it as to-client.
>>
>> Yeah this is currently a known issue. I'm planning to add support for
>> determining the direction of the flow based on 2 more properties in case
>> the start of the stream was missed:
>>
>> - simple port number: if one port is 80 it's likely http
>> - app-layer detection: if start of the stream is "GET /blah" it's likely
>> to server
>>
>>
>> > 21 2.927665 192.168.2.8 192.168.2.12 TCP 60[TCP Acked unseen segment]
>> > netinfo-local >..
>> > 25 3.217648 192.168.2.12 192.168.2.18 TCP 60[TCP Previous segment not
>> > captured]
>> >
>> > In the following Suricata log, it shows how packet 25 processing fails
>> > to find probing parser for either port even though it logs that it finds
>> > the probing parser for source port. I print a DEBUG statement that
>> > indicates pp_port_sp->sp = (nil). And then it never even attempts to
>> > detect this session again, throughout the run.
>> >
>> > 15/2/2015 -- 09:48:17 - <Debug> - Entering ... >>
>> > 15/2/2015 -- 09:48:17 - <Debug> - Returning: 0 ... <<
>> > 15/2/2015 -- 09:48:17 - <Debug> - Returning pointer (nil) of type
>> > AppLayerProtoDetectProbingParserPort * ... <<
>> > 15/2/2015 -- 09:48:17 - <Debug> - toclient - No probing parser
>> > registered for dest port 1033
>> > 15/2/2015 -- 09:48:17 - <Debug> - Returning pointer 0x27738b0 of type
>> > AppLayerProtoDetectProbingParserPort * ... <<
>> > 15/2/2015 -- 09:48:17 - <Debug> - toclient - Probing parser found for
>> > source port 20000
>> > 15/2/2015 -- 09:48:17 - <Debug> - DEBUG:pp_port_sp->sp = (nil)
>> > 15/2/2015 -- 09:48:17 - <Debug> - toclient - No probing parsers found
>> > for either port
>> > 15/2/2015 -- 09:48:17 - <Debug> - toclient, mask is now 00000000
>> > 15/2/2015 -- 09:48:17 - <Debug> - Returning: 0 ... <<
>> >
>> > Any help would be much appreciated.
>>
>> Not sure if there is an easy workaround, other than implementing what I
>> have in mind above.
>>
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>> _______________________________________________
>> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Participate:
>> http://suricata-ids.org/participate/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>> Redmine: https://redmine.openinfosecfoundation.org/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20150723/14e10970/attachment.html>