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

Adrian Falk adrianfalk2 at gmail.com
Thu Mar 19 14:22:05 UTC 2015


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/20150319/660df8d0/attachment-0002.html>


More information about the Oisf-devel mailing list