[snort-devel] sfportscan and SYN scan with data

[Virgil Hemery <virgil.hemery () gmail com>]

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 () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel