[Bro] TCP options of a SYN packet

Thomas Tan thomastan81 at gmail.com
Thu Dec 10 06:40:36 PST 2015


Dear Daniel and Jame,

Thank you so much for your comments and advice. I had been away for a quite
few days and just got time to check the emails. I will try to write my
simple analyzer and will come back to you later.

Best regards,

Thomas

On 4 December 2015 at 01:07, James Swaro <james.swaro at gmail.com> wrote:

> > I agree TCPRS is not the place.
>
> Agreed. I would like TCPRS to be useful in this case, but the feature
> falls out of the scope of design of TCPRS.
>
> It might not be difficult to write a simple analyzer that looks only at
> syn packets and produces the events that Thomas is looking to generate. A
> simple analyzer may not need to retain packets like TCPRS does and would
> have a much faster execution and lower memory footprint because it doesn't
> need to do retrospective analysis on the connection.
>
> James Swaro
>
>
>
> On Thu, Dec 3, 2015 at 5:16 PM, Daniel Guerra <daniel.guerra69 at gmail.com>
> wrote:
>
>> I agree TCPRS is not the place.
>> When i look at the analyzer TCP.cc <http://tcp.cc>, i miss
>> some options available from /usr/include/netinet/tcp.h
>>
>> # define TCPOPT_EOL             0
>> # define TCPOPT_NOP             1
>> # define TCPOPT_MAXSEG          2
>> # define TCPOLEN_MAXSEG         4
>> # define TCPOPT_WINDOW          3
>> # define TCPOLEN_WINDOW         3
>> # define TCPOPT_SACK_PERMITTED  4               /* Experimental */
>> # define TCPOLEN_SACK_PERMITTED 2
>> # define TCPOPT_SACK            5               /* Experimental */
>> # define TCPOPT_TIMESTAMP       8
>> # define TCPOLEN_TIMESTAMP      10
>> # define TCPOLEN_TSTAMP_APPA    (TCPOLEN_TIMESTAMP+2) /* appendix A */
>>
>> It would be nice to have them available when needed. OS fingerprint can
>> be done
>> on how it was constructed, the order is free and each kernel treats the
>> rules different.
>> This can tell you what type of os  you see, but some are universal.
>> But if you want to detect two or more devices and want to relate the
>> traffic to the device,
>> you really need the timestamp.
>> It could also provide a method to detect cooked packets or a virus that
>> creates its own packets.
>> And I think it is actually very cheap because you are sure you only get 1
>> syn (beside retrans)
>> per connection and that is way less than HTTP for example.
>>
>> Regards,
>>
>> Daniel
>>
>> On 03 Dec 2015, at 20:14, James Swaro <james.swaro at gmail.com> wrote:
>>
>> As you noted already, TCPRS doesn't provide that type of behavior. The
>> options of interest to TCPRS are limited and only reported via the
>> TCPRS::conn_config event, which certainly does not fit your needs. That
>> said, extending the TCPRS plugin, or the TCP analyzer within bro doesn't
>> seem to be something that is out of the realm of possibility here.
>>
>> As Seth mentioned above, generating an event for every syn is potentially
>> expensive. SYN retransmissions may generate duplicate records.
>>
>> You could create a new event in the source for syn options, but I'm not
>> aware of any bro constructs that would (easily) allow for providing the
>> options in the order they are observed in the header(Seth,Vlad,Daniel -
>> please chime in here).  It might be possible to send (ID, value) tuples to
>> the script with a new event, given that the tuples are inserted into a
>> vector in the order they are observed in the header. Once in the script,
>> you could convert the ID (option identifier) into the string representation
>> and create a single string that could easily be parsed.
>>
>> Example record:
>> > 10.0.0.1 2000 10.0.0.2 2001 TCPOPT_MAXSEG=3,TCPOPT_WSCALE=1
>>
>> Obviously, the output format is dictated by the bro script, so that isn't
>> terribly important here since that would be up to your design.
>>
>> I'm sure you are already aware of issues with fingerprinting, but some
>> values might differ within the same OS depending if the kernel has been
>> modified or kernel config options have been modified from their default
>> values.
>>
>> If this type of approach interests you, let me know.
>>
>>
>> James Swaro
>>
>>
>>
>> On Thu, Dec 3, 2015 at 4:36 AM, Thomas Tan <thomastan81 at gmail.com> wrote:
>>
>>> Hi James,
>>>
>>> Thanks for you reply. You are right. I am looking into OS specific
>>> behaviors. How can I use your plug-in to get TCP options from a SYN packet?
>>>
>>> Your help will be very much appreciated.
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>> On 3 December 2015 at 05:49, James Swaro <james.swaro at gmail.com> wrote:
>>>
>>>> I'm sorry I didn't see this earlier. I'm curious. Why is the order of
>>>> the options important? Are you searching for OS specific behavior?
>>>>
>>>> James Swaro
>>>>
>>>>
>>>>
>>>> On Wed, Dec 2, 2015 at 4:29 PM, Thomas Tan <thomastan81 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Vlad,
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>> I am aware of the support of p0f in Bro. You are right. The original
>>>>> p0f v2 fingerprints are out-dated. In my work, I am not using the p0f v2
>>>>> fingerprints but collecting OS fingerprints from network connections
>>>>> initiated by remote machines. A multi-class classifier will be applied to
>>>>> assign these OS fingerprints to their respective OS types.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Thomas
>>>>>
>>>>> On 2 December 2015 at 22:26, Vlad Grigorescu <vladg at illinois.edu>
>>>>> wrote:
>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> Bro has p0f support built-in. See:
>>>>>>
>>>>>> https://www.bro.org/sphinx/scripts/base/bif/event.bif.bro.html#id-OS_version_found
>>>>>>
>>>>>> That being said, the original p0f fingerprints are very out of date,
>>>>>> and
>>>>>> it's possible that Bro will stop supporting p0f in the future. I did
>>>>>> some research on the fingerprints with the Windows XP end of life, and
>>>>>> ended up leveraging some of Bro's other capabilities to write a much
>>>>>> better detection:
>>>>>>
>>>>>> https://github.com/bro/bro/blob/master/scripts/policy/frameworks/software/windows-version-detection.bro
>>>>>>
>>>>>> Generally, I think the interest is in moving up the stack and
>>>>>> performing
>>>>>> this kind of fingerprinting at a higher, more reliable, layer.
>>>>>>
>>>>>>   --Vlad
>>>>>>
>>>>>> Thomas Tan <thomastan81 at gmail.com> writes:
>>>>>>
>>>>>> > Dear Seth,
>>>>>> >
>>>>>> > Actually, I am writing a module using the outputs from Bro to detect
>>>>>> > Operating Systems running on remote host machines. I need to get the
>>>>>> > fingerprints of these OS for classification. I want to know if
>>>>>> there is any
>>>>>> > means to obtain p0f-like OS fingerprints.
>>>>>> >
>>>>>> > Best regards,
>>>>>> >
>>>>>> > Thomas
>>>>>> >
>>>>>> > On 2 December 2015 at 17:34, Seth Hall <seth at icir.org> wrote:
>>>>>> >
>>>>>> >>
>>>>>> >> > On Dec 2, 2015, at 10:41 AM, Thomas Tan <thomastan81 at gmail.com>
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> >  It cannot get TCP options and the order of the options down
>>>>>> from a SYN
>>>>>> >> packet.
>>>>>> >>
>>>>>> >> It sounds like you might want to write your own plugin but it
>>>>>> might even
>>>>>> >> be possible that that’s not enough and you’d have to add a feature
>>>>>> to Bro’s
>>>>>> >> core to generate an event only for SYN packets. (although you
>>>>>> generally
>>>>>> >> have to be very careful about even generating an event for a
>>>>>> single packet).
>>>>>> >>
>>>>>> >>   .Seth
>>>>>> >>
>>>>>> >> --
>>>>>> >> Seth Hall
>>>>>> >> International Computer Science Institute
>>>>>> >> (Bro) because everyone has a network
>>>>>> >> http://www.bro.org/
>>>>>> >>
>>>>>> >>
>>>>>> > _______________________________________________
>>>>>> > Bro mailing list
>>>>>> > bro at bro-ids.org
>>>>>> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>>>> <http://mailman.icsi.berkeley.edu/mailman/listinfo/bro>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bro mailing list
>>>>> bro at bro-ids.org
>>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>>> <http://mailman.icsi.berkeley.edu/mailman/listinfo/bro>
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> Bro mailing list
>> bro at bro-ids.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20151210/92e0aec3/attachment-0001.html 


More information about the Bro mailing list