From bsiamine at yahoo.fr Wed May 3 05:40:54 2006 From: bsiamine at yahoo.fr (bsila amine) Date: Wed, 3 May 2006 14:40:54 +0200 (CEST) Subject: [Bro] analyzer Message-ID: <20060503124054.44854.qmail@web26701.mail.ukl.yahoo.com> Hi can any one please tell me the procedure to add a new protocol analyzer. Thanks ___________________________________________________________________________ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services pr?f?r?s : v?rifiez vos nouveaux mails, lancez vos recherches et suivez l'actualit? en temps r?el. Rendez-vous sur http://fr.yahoo.com/set From robin at icir.org Wed May 3 09:01:52 2006 From: robin at icir.org (Robin Sommer) Date: Wed, 3 May 2006 09:01:52 -0700 Subject: [Bro] analyzer In-Reply-To: <20060503124054.44854.qmail@web26701.mail.ukl.yahoo.com> References: <20060503124054.44854.qmail@web26701.mail.ukl.yahoo.com> Message-ID: <20060503160152.GD998@net.informatik.tu-muenchen.de> On Wed, May 03, 2006 at 14:40 +0200, bsila amine wrote: > can any one please tell me the procedure to add a new > protocol analyzer. The best way to see how an analyzer works is to take a look at one of the more simple existing analyzers. For a TCP protocol, the finger analyzer is a good starting point (it's in Finger.{h,cc}; you can ignore anything related to trace rewriting). For UDP the NTP analyzer makes a good example. Note that in the near future the analyzer interface will change, as we're working on a more general analyzer architecture (which is, e.g., able to analyze protocols independent of their well-know ports). It will be easy to convert analyzers to the new interface though. Which protocol do you want to add? Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org From salom123 at ok.kz Wed May 10 06:47:53 2006 From: salom123 at ok.kz (salom123 at ok.kz) Date: Wed, 10 May 2006 19:47:53 +0600 Subject: [Bro] about Bro Message-ID: Hi Bro-Team, Wanted to make it clear... For example I am running the Bro as follows, bro -r mt -w And in the location where I am running this line it generates the files: - alarm.log, - ftp.log, - weird.log, - etc... Which one I have to take into account when I will be looking for labeled attacks? I mean, I already have the set of attacks (for example DARPA 1999 Training data, Week 2 data). Now, which file I have to look for the attacks, to find out if the Bro found any attacks? For the current time I am looking for the alarm.log file to see if the Bro found correct ones. Am I doing right? Thanks in advance. Also wanted to make it clear for example in SNORT for analyzing the tcpdump files i am writing, snort -r -c /etc/snort/snort.conf -l And now i want to do the same but with Bro, what i am writing is bro -r mt -w Am I doing it right? If not, please can you explain it to me? Thanks in advance. regards. From salom123 at ok.kz Wed May 10 07:25:15 2006 From: salom123 at ok.kz (salom123 at ok.kz) Date: Wed, 10 May 2006 20:25:15 +0600 Subject: [Bro] question on packages Message-ID: Hi Bro-Team, really sorry for asking this, but i am new to unix/linux environment. Please can you write all the needed packages that the OS should already have prior to installing the Bro system. What I mean is not only libpcap, tcpdump, etc... but I want to see the all packges like list of c compilers, bison, etc... It would be really cool for those who just want to install it and test the Bro on specific data. Thanks in advance. regards. From christian at whoop.org Wed May 10 08:19:43 2006 From: christian at whoop.org (Christian Kreibich) Date: Wed, 10 May 2006 16:19:43 +0100 Subject: [Bro] about Bro In-Reply-To: References: Message-ID: <1147274384.28616.126.camel@strangepork> Hi, you should check out the manuals at http://www.bro-ids.org/manuals.html to learn about the meaning of the individual log types. Note that Bro, like any other IDS, will need careful tuning in case you want it to alarm you of all the attacks labelled in the DARPA set. On Wed, 2006-05-10 at 19:47 +0600, salom123 at ok.kz wrote: > Hi Bro-Team, > > Wanted to make it clear... For example I am running the Bro as follows, [...] Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From christian at whoop.org Wed May 10 08:29:30 2006 From: christian at whoop.org (Christian Kreibich) Date: Wed, 10 May 2006 16:29:30 +0100 Subject: [Bro] question on packages In-Reply-To: References: Message-ID: <1147274970.28616.137.camel@strangepork> Hi again, just run ./configure and look at its output. It'll guide you through what you need. Also check ./configure --help for the optional features. The requirements are actually really quite basic and any typical development-type package configuration should be fine. We do not currently release binary packages, however, adding a spec file for RPMs, for example, would be pretty trivial. If any skilled packagers are reading this and interested in giving it a shot, get in touch -- we're lacking cycles for the additional maintenance overhead. On Wed, 2006-05-10 at 20:25 +0600, salom123 at ok.kz wrote: > Hi Bro-Team, > > really sorry for asking this, but i am new to unix/linux environment. > > Please can you write all the needed packages that the OS should already have prior to installing the Bro system. > > What I mean is not only libpcap, tcpdump, etc... but I want to see the all packges like list of c compilers, bison, etc... It would be really cool for those who just want to install it and test the Bro on specific data. Thanks in advance. > > regards. > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From jyjung at csail.mit.edu Wed May 10 12:13:42 2006 From: jyjung at csail.mit.edu (Jaeyeon Jung) Date: Wed, 10 May 2006 15:13:42 -0400 Subject: [Bro] logarithm or exponential function for .bro? Message-ID: <20060510191342.GA3608@csail.mit.edu> Hi, What is the best way to compute log (x) or exp (x) (and get the double-precision result) in a Bro policy? I notice that large-conns.bro has logarithm() implemented, but this returns the integer logarithm. Thanks! Jaeyeon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20060510/aec46728/attachment.bin From rpang at cs.princeton.edu Wed May 10 12:19:27 2006 From: rpang at cs.princeton.edu (Ruoming Pang) Date: Wed, 10 May 2006 15:19:27 -0400 Subject: [Bro] logarithm or exponential function for .bro? In-Reply-To: <20060510191342.GA3608@csail.mit.edu> References: <20060510191342.GA3608@csail.mit.edu> Message-ID: Hi, I cannot find any log/exp implementation in bro.bif. But you are encouraged to add your own (see src/bro.bif for examples). And if you do so, please send your code to us. :-) Thanks, Ruoming On 5/10/06, Jaeyeon Jung wrote: > Hi, > > What is the best way to compute log (x) or exp (x) (and get > the double-precision result) in a Bro policy? I notice > that large-conns.bro has logarithm() implemented, but > this returns the integer logarithm. > > Thanks! > Jaeyeon > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > > From jyjung at csail.mit.edu Wed May 10 14:21:40 2006 From: jyjung at csail.mit.edu (Jaeyeon Jung) Date: Wed, 10 May 2006 17:21:40 -0400 Subject: [Bro] logarithm or exponential function for .bro? In-Reply-To: References: <20060510191342.GA3608@csail.mit.edu> Message-ID: <20060510212140.GA22652@csail.mit.edu> Hi Ruoming, Thanks for the pointer (bro.bif). Added two functions, exp and log, in bro.bif as below. (Also tested them with a simple test.bro script.) -- Jaeyeon # The exp function returns the value of e (the base of natural log) # raised to power d. function exp%(d: double%): double %{ return new Val(exp(d), TYPE_DOUBLE); %} # The log function returns the natural logarithm of d. function log%(d: double%): double %{ return new Val(log(d), TYPE_DOUBLE); %} On Wed, May 10, 2006 at 03:19:27PM -0400, Ruoming Pang wrote: > Hi, > > I cannot find any log/exp implementation in bro.bif. But you are > encouraged to add your own (see src/bro.bif for examples). And if you > do so, please send your code to us. :-) > > Thanks, > Ruoming > > On 5/10/06, Jaeyeon Jung wrote: > > Hi, > > > > What is the best way to compute log (x) or exp (x) (and get > > the double-precision result) in a Bro policy? I notice > > that large-conns.bro has logarithm() implemented, but > > this returns the integer logarithm. > > > > Thanks! > > Jaeyeon > > > > > > _______________________________________________ > > Bro mailing list > > bro at bro-ids.org > > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20060510/7ab3e8e2/attachment.bin From vern at icir.org Mon May 15 13:57:22 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 15 May 2006 13:57:22 -0700 Subject: [Bro] new Bro CURRENT release 1.1 Message-ID: <200605152057.k4FKvMgg034508@jaguar.icir.org> Bro release 1.1 is now available from: ftp://bro-ids.org/bro-1.x-current.tar.gz This becomes the new CURRENT release. It contains a significant number of new features and bug fixes, per the appended change log. Vern -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1.1 Mon May 15 10:50:33 PDT 2006 - Bro now supports a "when" statement for taking action upon something becoming true asynchronously (Robin Sommer). This provides a powerful new mechanism with numerous applications. Syntax: when '(' ')' [timeout '{ '}'] where the first can be a single statement or a block enclosed in {}'s, but the set associated with "timeout" must be enclosed in {}'s (to reduce ambiguities in Bro's grammar). Bro executes the first statement when becomes true. If you give a timeout and the condition has not been satisfied before it expires, Bro executes the second statement instead. A simple example: global t: table[addr] of count; event connection_established(c: connection) { local orig = c$id$orig_h; if ( orig !in t ) { t[orig] = 1; when ( t[orig] == 5 ) print fmt("%s has established 5 connections", orig); timeout 1 hr { print fmt("%s has NOT established 5 connections", orig); delete t[orig]; } } else ++t[orig]; } Notes: - The condition may be evaluated more than once, and at arbitrary times. - When the when-body is executed, the condition is guaranteed to be still satisfied. - Expression reevaluation is primarily triggered by modifications to globals. However, reevaluations do not take place immediately but potentially at a later point. This means that if we change a global to a value which would execute the trigger but then change it back, the change may go unnoticed. - Inside the condition you may introduce new locals. For example, when ( (local x = foo()) && x == 42 ) ... Such an assignment always yields true as its expression value (but the assignment might be delayed, for example if foo() is a delayed function call - see below). Delaying function calls ======================= Functions called inside the condition of a when-clause may delay their results until they're ready. This works for both script-level and built-in functions. For script-level functions, there is a new construct, "return ", to delay a function's result. When used, the function returns at the time the when-stmt's condition becomes true, and it yields the value that the when-stmt's body then returns. Toy example: global X: table[string] of count; function a() : count { # This delays until condition becomes true. return when ( "a" in X ) { return X["a"]; } timeout 5 min { return 0; } } event bro_init() { # Installs a trigger which fires if a() returns 42. when ( a() == 42 ) { print "Yippie!"; } X["a"] = 42; } There's also a new built-in function which can delay lookup_addr(host: addr) performs asynchronous DNS address->hostname lookups. Example: local h; addr; [...] when (local name = lookup_addr(h)) { print h, name; } See the function gen_hot_notice_with_hostnames() in conn.bro for a more worked-out example of using the "when" clause to translate the local address in SensitiveConnection notices to a hostname (contributed by Brian Tierney). This functionality is activated by redef'ing xlate_hot_local_addr to T. Here is the full evaluation model of a when's condition: - The condition may be evaluated more than once, at arbitrary times. - It is always fully evaluated, no matter whether some former evaluation has been suspended by a delaying function call. - All function calls which do not delay are always *fully* executed each time the condition is evaluated. - Function calls which delay are only executed *once*; their result is cached and re-used in the case the condition is evaluated again. - The condition is guaranteed to be true when the body is executed (potentially using cached function results) - By default Bro now uses a configuration similar to what used to be activated using reduce-memory.bro, along with some additional state timeouts that are new (Robin Sommer and Vern Paxson). This allows for better state management out-of-the-box, at the cost of some precision of analysis and resilience to evasion. In particular, the intent is to move towards being able to run Bro continuously without inexorably growing the amount of memory used until exhaustion. You can access a configuration similar to the previous default state management settings by loading heavy-analysis.bro. It turns on a load-prefix of "heavy", so when you load XXX.bro, a file heavy.XXX.bro will also be automatically loaded if present. Note that, as was the case for reduce-memory, you need to load heavy-analysis prior to other files for it to have effect. - The new module clear-passwords.bro monitors login/FTP/IRC/POP traffic for cleartext passwords (Jason Lee). - The new script service-probe.bro looks for remote hosts that repeatedly connect to the same service on local hosts (for a configurable set of services and connection sizes) in order to detect brute-forcing attacks such as password-guessing (Jim Mellander). - A new ARP analyzer generates three events: event arp_request(mac_src: string, mac_dst: string, SPA: addr, SHA: string, TPA: addr, THA: string); event arp_reply(mac_src: string, mac_dst: string, SPA: addr, SHA: string, TPA: addr, THA: string); event bad_arp(SPA: addr, SHA: string, TPA: addr, THA: string, explanation: string); with a corresponding policy script arp.bro (Chema Gonzalez and Vern Paxson). It writes logs to arp.$BRO_LOG_SUFFIX. It has not been tested much yet. - Bro Lite changes (Jason Lee): - default user for is now user 'bro' - now uses the correct sysctl on FreeBSD 6 - now uses the correct Perl path if site-report.pl not installed into '/usr/local/bro' - no longer prompts to encrypt email unless you pick to email reports - The default Bro Lite install now only checkpoints Bro once a week (Brian Tierney). - Implicit Bro file extensions (such as .bro for policy scripts and .sig for signatures) are now searched for first rather than only if the non-extension-version of the file doesn't exist (Vern Paxson). For example, running "bro -r trace mt" now first searches $BROPATH for "mt.bro" before searching for "mt", whereas it used to do these in the other order. - There's now a simpler mechanism for redef'ing variables on the command-line (Christian Kreibich). Any command line arguments of the form = are now expanded into policy code of the form "redef var=val;", where is wrapped in quotation marks if the value appears to be a string and doesn't have quotation marks already. This works with strings with whitespace such as foo="Hello World"; however, note that it means you can't use the mechanism to redef an enum value. - The Bro distribution now includes (and builds by default) Christian Kreibich's Broccoli library (Bro C Client Library), which enables programs to communicate with running Bro's (Christian Kreibich and Jason Lee). Configure with --disable-broccoli to turn this off. - Built-in functions log(x: double): double and exp(x: double): double which do natural logarithms and their inverses (Jaeyeon Jung). - The new built-in function gethostname() returns the local host's name (Jason Lee & Robin Sommer). - The new built-in function reading_traces() returns true if Bro is reading trace files (Robin Sommer). - The new built-ins suspend_processing() and continue_processing() provide script-level control for instructing the event engine to stop or resume processing packets (Robin Sommer). This is useful for coordinating simultaneous processing by multiple Bro's. - Email notices are now by default sent via /bin/mail, with "[Bro Alarm]" in the subject. - redef'ing a function now replaces the existing body rather than supplementing it (Robin Sommer), which was a bug. - You can now configure Bro to process encapsulated IP packets either by setting, as before, a fixed encap_hdr_size (for VLANs), or setting parse_udp_tunnels to T (Ruoming Pang). For the latter, you specify a UDP tunnel port using udp_tunnel_port (the previous variable "tunnel_port" has gone away); or you can leave it set to its default of 0/udp, in which case Bro will look for IP encapsulated in UDP packets on any port. - Added a simple form of profiling based on sampling the work done per-packet (Vern Paxson). The event engine generates a event load_sample(samples: load_sample_info, CPU: interval, dmem: int) event every load_sample_freq packets (roughly; it's randomized), where load_sample_freq defaults to 20. "samples" is simply a set[string]; it contains the names of the functions, event handlers, and their source files that were accessed during the processing of the sampled packet, along with an estimate of the CPU cost of processing the packet and (currently broken) memory allocated/freed. - Bro now includes experimental support for Endace DAG cards (Gregor Maier and Robin Sommer). To activate, configure with --with-DAG=/path/to/dagtool/installation and use "dag0" as the network interface. You may need to configure the card with the dagtools first. In general, if dagsnap works, Bro should work as well. - Log rotation has changed in a number of ways (Mark Dedlow & Robin Sommer): * The new variable log_rotate_base_time: string, if defined, specifies that logs should be rotated at log_rotate_base_time + i * rotate_interval intervals. Format is as a string in 24-hour time, "%H:%M", e.g, "12:00". This format may change in the future to instead be a Bro time type. * RotateLogs::date_format can be redefined to change format of timestamps in rotated files. * RotateLogs::build_name() can be redefined to implement an arbitrary naming scheme for rotated files. Note, this code has not been extensively tested. - Bro now by default builds a version of malloc bundled with its distribution (Vern Paxson & Brian Tierney). - The syntax for the clone operator now looks like a function call, "copy(x)" (Vern Paxson). - The new flag DNS::logging (default F), if T, disables generation of dns.log (which is often uninteresting and very large), though it still performs analysis leading to NOTICEs (Robin Sommer). - A new global, hostile_domain_list, has been added to dns.bro which lists domains to be flagged if A or MX records are queried (Scott Campbell). - Added globals dns_skip_all_{auth,addl} to skip all DNS AUTH/ADDL processing (Vern Paxson). Skipping these is on (true) by default, because such processing is quite expensive. - backdoor.bro now turns off by default some detectors that from experience have too many false positives, or (such as for HTTP) too many uninteresting true positives (Brian Tierney). In addition: - the module now generates a BackdoorFound notice for each backdoor - the new variable dump_backdoor_packets (default F) if set causes the packet that triggered the backdoor detection to be written to backdoor-packets/: