Re: Incorrect IP Flags Values in database output.

[Joel Esler <jesler () sourcefire com>]

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 () khan net> 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 () 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 () 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 () 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