[Bro] TCP options of a SYN packet
James Swaro
james.swaro at gmail.com
Thu Dec 3 16:07:32 PST 2015
> 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/20151203/789983c2/attachment.html
More information about the Bro
mailing list