[Snort-devel] [snort-devel] sfportscan and SYN scan with data

Russ Combs rcombs at ...402...
Mon Apr 25 09:51:34 EDT 2011


Virgil - can you send your conf and pcap that demonstrates the issue?

Thanks
Russ

On Sun, Apr 24, 2011 at 12:48 PM, Virgil Hemery <virgil.hemery at ...2499...>wrote:

> Hi. I noticed that the following command:
> # nmap -sS target --data-length N
>
> which sends SYN probes to target with N bytes of random data,
>
> is detected by sfportscan as a Filtered PortScan with a Priority Level
> equal to 0, which means a lot of connection attempts have been tracked but
> no negative answers were received , despite the presence of many closed
> ports on the target that sent RST back. The following code, from the
> ps_tracker_update_tcp function, checks the p->ssnptr session pointer to
> determine whether the packet p belongs to a session created by steam5, so it
> can use its session flags to handle the packet properly.
>
>     if(p->ssnptr && stream_api)
>     {
>         session_flags = stream_api->get_session_flags(p->ssnptr);
>
>         if((session_flags & SSNFLAG_SEEN_CLIENT) &&
>            !(session_flags & SSNFLAG_SEEN_SERVER) &&
>            (portscan_eval_config->include_midstream || !(session_flags &
> SSNFLAG_MIDSTREAM))) // session SYN
>         {
>              // connection_count += 1
>         }
>         else if(p->packet_flags & PKT_STREAM_TWH) { // session ACK
>         {
>             // connection_count -= 1
>         }
>         else if((p->packet_flags & PKT_FROM_SERVER) &&
>                 (p->tcph && (p->tcph->th_flags & TH_RST)) &&
>                 (!(p->packet_flags & PKT_STREAM_EST) ||
>                 (session_flags & SSNFLAG_MIDSTREAM))) // session RST
>         {
>              // priority_count += 1
>         }
>     }
>
> In fact, SYN packets containing data generally don't create stream5 TCP
> sessions (it depends on the policy configuration), so RST answers from
> closed ports are dropped because they don't belong to any existing TCP
> session. But those packets still have a session pointer, as Stream5 created
> a low session data structure (NewLwSession function) for the SYN with data,
> which has been copied to p->ssnptr. I don't know precisely why, but as a
> result RST answers have only the session flag SSNFLAG_SEEN_CLIENT so they
> are considered as "session SYN" packets and increase the connection counter
> instead of the priority counter.
>
> Would it be possible to fix this behavior ? How ?
>
> Best regards.
> Virgil.
>
>
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20110425/8a9a5644/attachment.html>


More information about the Snort-devel mailing list