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

Virgil Hemery virgil.hemery at ...2499...
Sun Apr 24 12:48:07 EDT 2011

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 &
             // 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20110424/bf587b84/attachment.html>

More information about the Snort-devel mailing list