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