[Snort-users] Incorrect IP Flags Values in database output.

Joel Esler jesler at ...1935...
Mon Aug 15 20:53:56 EDT 2011


Hopefully the barnyard folks will see this thread and comment on their code. 

Sent from my iPhone

On Aug 15, 2011, at 20:34, kareem at ...15353... wrote:

> I think that I originally found this running barnyard2.  It looks like there is a lot of code reuse between barnyard2 and snort.  Decode.c and spo_database.c are used in both and the versions appear to be very similar.  Although the unified2 output is correct, the problem then propagates into barnyard. I still get an invalid pcap from base. 
> 
> Thanks to both of you for the fast response.
> 
> Kareem
> 
> On Aug 15, 2011, Joel Esler <jesler at ...1935...> wrote:
> 
> That being said, we are depreciating the spo_database.c output plugin in an upcoming version of Snort.  If you are using it now, I suggest moving over to unified2 and using something like a barnyard2 module to process the unified2 files.
> 
> I had a post on the blog back in June about it.
> 
> http://blog.snort.org/2011/06/snorts-output-methods.html
> 
> We are planning on End-of-Lifeing the spo_database.c module, the Aruba module, and the prelude module.  We've tried to contact the authors of the latter two modules warning them of this for the past several months, to no avail, so hopefully if they are reading this list, they'll see this email.
> 
> Joel
> 
> 
> 
> 
> 
> 
> 
> On Aug 15, 2011, at 6:11 PM, Russ Combs wrote:
> 
> 
> 
> On Mon, Aug 15, 2011 at 3:50 PM, <kareem at ...15353...> wrote:
> I have been playing around with snort and noticed that the output data did not alway match up with the test packets that I was sending.  I would snort a valid packet and then look at the result that I got from barnyard and I noticed that the IP Flags in the packets I got from barnyard had a different value then the packets that I sent into the system.  I dug into the code and I think that I see where the mistake is, but  I have to admit that I am not much of a programmer, so I could be wrong.  I am looking at the source code for 2.9.0.2.  In the decode.c file the frag flag gets set as follows:
> 
>    3321     if(p->frag_offset || p->mf)
>    3322     {
>    3323         /* set the packet fragment flag */
>    3324         p->frag_flag = 1;
>    3325         p->ip_frag_start = pkt + hlen;
>    3326         p->ip_frag_len = (uint16_t)ip_len;
>    3327         pc.frags++;
>    3328     }
>    3329     else
>    3330     {
>    3331         p->frag_flag = 0;
>    3332     }
> 
> So its either on or off and looks to me like this setting used as an indicator if the packet is a fragment.  But in the output plugin source, spo_database.c, then sets the IP flags in the database using p->frag_flag.  
> 
>    1886                 ret = SnortSnprintf(query->val, MAX_QUERY_LENGTH,
>    1887                                     "INSERT INTO "
>    1888                                     "iphdr (sid, cid, ip_src, ip_dst, ip_ver, ip_hlen, "
>    1889                                     "       ip_tos, ip_len, ip_id, ip_flags, ip_off,"
>    1890                                     "       ip_ttl, ip_proto, ip_csum) "
>    1891                                     "VALUES (%u,%u,%lu,%lu,%u,%u,%u,%u,%u,%u,%u,%u,%u,%u)        ",
>    1892                                     data->shared->sid,
>    1893                                     data->shared->cid,
>    1894                                     (u_long)ntohl(p->iph->ip_src.s_addr),
>    1895                                     (u_long)ntohl(p->iph->ip_dst.s_addr),
>    1896                                     IP_VER(p->iph),
>    1897                                     IP_HLEN(p->iph),
>    1898                                     p->iph->ip_tos,
>    1899                                     ntohs(p->iph->ip_len),
>    1900                                     ntohs(p->iph->ip_id),
>    1901                                     p->frag_flag,
>    1902                                     ntohs(p->frag_offset),
>    1903                                     p->iph->ip_ttl,
>    1904                                     GET_IPH_PROTO(p),
>    1905                                     ntohs(p->iph->ip_csum));
> 
> So the output is alway zero if the packet is not a fragment, even if the don't fragment bit is set.  Am I looking at this wrong?
> 
> Your interpretation of the code is correct.  Not sure what the database expects to see there, but it isn't reserved + don't_frag + more_frags.
> 
> Thanks
> 
> Kareem 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 
> Please see http://www.snort.org/docs for documentation
> 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 
> Please see http://www.snort.org/docs for documentation
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20110815/eb43eb81/attachment.html>


More information about the Snort-users mailing list