[Bro] TCP options of a SYN packet
Daniel Guerra
daniel.guerra69 at gmail.com
Thu Dec 3 15:16:14 PST 2015
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <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 <mailto: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 <mailto:seth at icir.org>> wrote:
> >
> >>
> >> > On Dec 2, 2015, at 10:41 AM, Thomas Tan <thomastan81 at gmail.com <mailto: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/ <http://www.bro.org/>
> >>
> >>
> > _______________________________________________
> > Bro mailing list
> > bro at bro-ids.org <mailto: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 <mailto: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/20151204/de46fd96/attachment-0001.html
More information about the Bro
mailing list