From falletta at ftw.at Mon Jan 2 18:28:05 2006 From: falletta at ftw.at (Vincenzo Falletta) Date: Tue, 03 Jan 2006 03:28:05 +0100 Subject: [Bro] two questions Message-ID: <43B9E135.7060200@ftw.at> Hello again, this time two naive questions: 1) I use my own "onlyscan.bro" policy file: =================================== @load alarm @load tcp @load scan @load trw @load weird redef use_tagging = T; redef shut_down_all_scans = T; redef use_TRW_algorithm = T; redef skip_services += { 445/tcp, 135/tcp }; =================================== but, in the alarm.log file I still find alerts triggered by scanners at port 445/tcp and 135/tcp, and if I create a report with site-report.pl in the "Scans" section I also find entries related to scans at ports 445 and 135. How can I tell bro just to ignore this services? 2) How does the site-report.pl script choose the entries to be written in the Scan section of the report? Reading the manual I see that they should be ONLY the successful scans, but in the end of alarm.log file I have some entries like "ScanSummary: host x has scanned a total of 3241 hosts" and this does not appear in the report! Instead, in the report I have entries like "host y has scanned 100 hosts" so it's a lower value and seems related to the thresholds set in the variable "report_outbound_peer_scan" rather than being a total number of hosts scanned. I tried to read and understand the code but I'm not familiar with perl, and it would be easier to have some brief documentation or at least an explaination of the main functions involved, like "Bro::Report::Alarm::output_scans". Thanks for your attention. Vincenzo From dmvasil at ornl.gov Mon Jan 9 08:50:27 2006 From: dmvasil at ornl.gov (David Vasil) Date: Mon, 09 Jan 2006 11:50:27 -0500 Subject: [Bro] bro segfaults on startup Message-ID: <43C29453.6000400@ornl.gov> Hello, I have an x86_64 RHEL4u2 running a 2.6.14.2 kernel on which I compiled bro-1.0 with the following options: ./configure --prefix=/opt/bro And did a make install and make install-brolite to create a base configuration. After that I attempt to run /opt/bro/etc/bro.rc -start which results in the following: [root at endace bro]# etc/bro.rc start bro.rc: Running as non-root user bro bro.rc: Starting /opt/bro/etc/bro.rc: line 229: 6635 Segmentation fault "${BRO}" ${cmd_opts} 2>>"${info_log}" >>"${info_log}" .........bro.rc: Failed to start Bro .... FAILED [root at endace bro]# etc/bro.rc start bro.rc: Running as non-root user bro bro.rc: Starting /opt/bro/etc/bro.rc: line 229: 6721 Segmentation fault "${BRO}" ${cmd_opts} 2>>"${info_log}" >>"${info_log}" .........bro.rc: Failed to start Bro .... FAILED In dmesg the following is shown: bro[6635]: segfault at 00000000fffcf678 rip 0000000000561ef5 rsp 00000000fffcf650 error 4 bro[6721]: segfault at 00000000ffaafa58 rip 0000000000561ef5 rsp 00000000ffaafa30 error 4 In /var/log/messages the following is shown: Jan 9 11:38:34 endace su(pam_unix)[6598]: session opened for user bro by root(uid=0) Jan 9 11:38:35 endace kernel: bro[6635]: segfault at 00000000fffcf678 rip 0000000000561ef5 rsp 00000000fffcf650 error 4 Jan 9 11:38:40 endace bro.rc: Bro has failed to start. Unknown error, no messages recieved on STDERR or STDOUT Jan 9 11:38:40 endace bro.rc: Bro process failed on first start attempt. No further restart attempts will be made. Jan 9 11:38:41 endace su(pam_unix)[6598]: session closed for user bro Jan 9 11:41:16 endace su(pam_unix)[6684]: session opened for user bro by root(uid=0) Jan 9 11:41:16 endace kernel: bro[6721]: segfault at 00000000ffaafa58 rip 0000000000561ef5 rsp 00000000ffaafa30 error 4 Jan 9 11:41:21 endace bro.rc: Bro has failed to start. Unknown error, no messages recieved on STDERR or STDOUT Jan 9 11:41:21 endace bro.rc: Bro process failed on first start attempt. No further restart attempts will be made. Jan 9 11:41:22 endace su(pam_unix)[6684]: session closed for user bro Notice, info, and alarm logfiles are created in bro's logs directory, however, all of these files are empty. I also tried the bro-0.9a11 branch, and it behaved the exact same way. Am I missing something? Thanks! -- | David Vasil | Oak Ridge National Laboratory NCCS Division | High Performance Computing Systems Administrator | Bldg: 5600-A115 Phone: (865)241-5562 From vern at icir.org Mon Jan 9 23:41:33 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 09 Jan 2006 23:41:33 -0800 Subject: [Bro] bro segfaults on startup In-Reply-To: Your message of Mon, 09 Jan 2006 11:50:27 EST. Message-ID: <200601100741.k0A7fXPT009215@jaguar.icir.org> What happens if you run it by hand inside gdb? (Also, FWIW, I were to make a wild guess, it would be that this relates to permissions for reading the packet filter.) Vern From vern at icir.org Mon Jan 9 23:48:30 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 09 Jan 2006 23:48:30 -0800 Subject: [Bro] two questions In-Reply-To: Your message of Tue, 03 Jan 2006 03:28:05 +0100. Message-ID: <200601100748.k0A7mUV3009562@jaguar.icir.org> > redef skip_services += { > 445/tcp, > 135/tcp > }; You need to put these in both skip_services and skip_outbound_services. Yeah, I know, this isn't intuitive :-(. The configuration for scan.bro is pretty much a mess, and we have a rewrite of it pending, but haven't managed to get it fully together yet. Sorry about that ... > 2) How does the site-report.pl script choose the entries to be written > in the Scan section of the report? Reading the manual I see that they > should be ONLY the successful scans, but in the end of alarm.log file I > have some entries like "ScanSummary: host x has scanned a total of 3241 > hosts" and this does not appear in the report! Instead, in the report I > have entries like "host y has scanned 100 hosts" so it's a lower value > and seems related to the thresholds set in the variable > "report_outbound_peer_scan" rather than being a total number of hosts > scanned. Right, the summary is decoupled here. Jason or Roger will need to chime in here, as they're the ones who develop/maintain site-report.pl. Again, sorry about the confusion ... Vern From dmvasil at ornl.gov Tue Jan 10 05:55:00 2006 From: dmvasil at ornl.gov (David Vasil) Date: Tue, 10 Jan 2006 08:55:00 -0500 Subject: [Bro] bro segfaults on startup In-Reply-To: <200601100741.k0A7fXPT009215@jaguar.icir.org> References: <200601100741.k0A7fXPT009215@jaguar.icir.org> Message-ID: <43C3BCB4.1060003@ornl.gov> Vern Paxson wrote: > What happens if you run it by hand inside gdb? > > (Also, FWIW, I were to make a wild guess, it would be that this relates > to permissions for reading the packet filter.) > > Vern Which packet filter do you mean? Scott Campbell mentioned it may be a problem with the resolver library, as others have had similar problems in the past. Here is the output from strace, ltrace, gdb, ldd, and version information for suspect libraries: [strace -f bin/bro -i eth0 mt http ftp scan] open("/opt/bro/policy/scan.bro", O_RDONLY) = 9 ioctl(9, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffffa9a0e0) = -1 ENOTTY (Inappropriate ioctl for device) fstat(9, {st_mode=S_IFREG|0644, st_size=13655, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaab1000 read(9, "# $Id: scan.bro,v 1.11 2005/10/0"..., 8192) = 8192 open(".state/.bro-dns-cache", O_RDONLY) = -1 ENOENT (No such file or directory) sendto(4, ":\343\1\0\0\1\0\0\0\0\0\0\5j5004\rinktomisearch"..., 41, 0, NULL, 0) = 41 select(5, [4], NULL, NULL, {20, 0}) = 1 (in [4], left {19, 972000}) recvfrom(4, ":\343\201\200\0\1\0\1\0\5\0\5\5j5004\rinktomisearch"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("160.91.198.66")}, [16]) = 233 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 14764 detached [ltrace -f bin/bro -i eth0 mt http ftp scan] strcmp("/opt/bro/policy/scan.bro", "/opt/bro/policy/scan.bro") = 0 _Znwm(56, 0x8505a9, 0x709200, 0, 0x36b062f778) = 0x8f3dc0 malloc(80) = 0x8f3e00 strncpy(0x705a60, "\t", 127) = 0x705a60 strncpy(0x705a60, "# who knows why we see these, bu"..., 127) = 0x705a60 strncpy(0x705a60, "\n", 127) = 0x705a60 strncpy(0x705a60, "\n", 127) = 0x705a60 strncpy(0x705a60, "\t", 127) = 0x705a60 strncpy(0x705a60, "j5004.inktomisearch.com", 127) = 0x705a60 strlen(".state") = 6 _Znam(70, 0x8ded1e, 0xfeff64736073722d, 25972, 0xfefefefefefefeff) = 0x8f3e60 sprintf("\001\200\255\373\377\177", "") = 21 fopen(".state/.bro-dns-cache", "r") = 0 strlen("dns_mapping_valid") = 17 strlen("dns_mapping_unverified") = 22 strlen("dns_mapping_new_name") = 20 strlen("dns_mapping_lost_name") = 21 strlen("dns_mapping_name_changed") = 24 strlen("dns_mapping_altered") = 19 strcmp("GLOBAL", "GLOBAL") = 0 _ZNSsC1EPKcRKSaIcE(0x7fffffe91690, 0x571e25, 0x7fffffe91600, 0, 0x89d780) = 0x8f26c8 _ZNSsC1EPKcRKSaIcE(0x7fffffe91600, 0x8f26c8, 0x7fffffe915f0, 0, 0xfefefefefefefeff) = 0x8f3ec8 strlen("::") = 2 _ZNKSs5rfindEPKcmm(0x7fffffe91600, 0x5724c1, -1, 2, 0x36b062f6f8) = -1 _ZNSsC1EPKcRKSaIcE(0x7fffffe91680, 0x567aeb, 0x7fffffe915f0, 1, -2) = 0x8f3ef8 _ZN9__gnu_cxx18__exchange_and_addEPVii(0x8f3ec0, 0xffffffff, 6, 0, 0x36b062f6f8) = 0 _ZNSs4_Rep10_M_destroyERKSaIcE(0x8f3eb0, 0x7fffffe915f0, 6, 0, 0x36b062f6f8) = 0x36b062f640 _ZNKSs7compareEPKc(0x7fffffe91680, 0x567aeb, 0, 4, 0x36b062f6f8) = 0 strlen("dns_mapping") = 11 _ZN9__gnu_cxx18__exchange_and_addEPVii(0x8f3ef0, 0xffffffff, 274, 0, 0x73cbc0) = 0 _ZNSs4_Rep10_M_destroyERKSaIcE(0x8f3ee0, 0x7fffffe91640, 274, 0, 0x73cbc0) = 0x36b062f640 _ZN9__gnu_cxx18__exchange_and_addEPVii(0x8f26c0, 0xffffffff, 0x8f3ea0, 4, 0x73cbc0) = 0 _ZNSs4_Rep10_M_destroyERKSaIcE(0x8f26b0, 0x7fffffe91640, 0x8f3ea0, 4, 0x73cbc0) = 0x36b062f640 strlen("j5004.inktomisearch.com") = 23 _Znwm(16, 0x8ded1e, 6, 0, 0) = 0x8f3f10 _Znam(24, 41185, 0x36b062f620, -25, 0x36b062f6f8) = 0x8f3f30 strcpy(0x8f3f30, "j5004.inktomisearch.com") = 0x8f3f30 malloc(1064) = 0x8f3f50 memset(0x8f3f50, '\000', 1064) = 0x8f3f50 strncpy(0x8f3f58, "j5004.inktomisearch.com", 1026) = 0x8f3f58 __res_mkquery(0, 0x8f3f30, 1, 1, 0) = 41 send(4, 0x7fffffe90fd0, 41, 0, 32) = 41 select(5, 0x7fffffe91660, 0, 0, 0x7fffffe91650) = 1 recvfrom(4, 0x7fffffe910d0, 1024, 0, 0x7fffffe914d0) = 233 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ [gdb bin/bro] (gdb) run -i eth0 mt http ftp scan Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan Program received signal SIGSEGV, Segmentation fault. 0x0000000000561ef5 in __ns_initparse () (gdb) bt #0 0x0000000000561ef5 in __ns_initparse () Cannot access memory at address 0xffd2a510 [rpm -qif /lib64/libresolv-2.3.4.so] Name : glibc Relocations: (not relocatable) Version : 2.3.4 Vendor: Red Hat, Inc. Release : 2.13 Build Date: Fri 19 Aug 2005 08:34:11 PM EDT Install Date: Thu 10 Nov 2005 05:53:07 PM EST Build Host: crowe.devel.redhat.com Group : System Environment/Libraries Source RPM: glibc-2.3.4-2.13.src.rpm Size : 11474270 License: LGPL Signature : DSA/SHA1, Wed 21 Sep 2005 11:48:40 AM EDT, Key ID 219180cddb42a60e Packager : Red Hat, Inc. Summary : The GNU libc libraries. Description : The glibc package contains standard libraries which are used by multiple programs on the system. In order to save disk space and memory, as well as to make upgrading easier, common system code is kept in one place and shared between programs. This particular package contains the most important sets of shared libraries: the standard C library and the standard math library. Without these two libraries, a Linux system will not function. [ldd bin/bro] libresolv.so.2 => /lib64/libresolv.so.2 (0x00000036b0f00000) libz.so.1 => /usr/lib64/libz.so.1 (0x00000036b0b00000) libssl.so.4 => /lib64/libssl.so.4 (0x00000036a9a00000) libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00000036a9700000) libtermcap.so.2 => /lib64/libtermcap.so.2 (0x00000036b1900000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000036b2800000) libm.so.6 => /lib64/tls/libm.so.6 (0x00000036b0900000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036b2600000) libc.so.6 => /lib64/tls/libc.so.6 (0x00000036b0400000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00000036b1b00000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00000036b1f00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000036b1500000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00000036b1d00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000036b0700000) /lib64/ld-linux-x86-64.so.2 (0x00000036b0200000) Sorry for the long post, please let me know if I can provide any further information. Thank you for your help. -- | David Vasil | Oak Ridge National Laboratory NCCS Division | High Performance Computing Systems Administrator | Bldg: 5600-A115 Phone: (865)241-5562 From dmvasil at ornl.gov Tue Jan 10 05:58:00 2006 From: dmvasil at ornl.gov (David Vasil) Date: Tue, 10 Jan 2006 08:58:00 -0500 Subject: [Bro] bro segfaults on startup In-Reply-To: <20060109221120.GA3830@armada.mynetwork.net> References: <43C29453.6000400@ornl.gov> <20060109221120.GA3830@armada.mynetwork.net> Message-ID: <43C3BD68.20902@ornl.gov> Jean-Philippe Luiggi wrote: > Hello, > > Did you configure/check your "bro.cfg" (/opt/bro/etc/bro.cfg, i think) ? > > Best regards. Yes, I used brolite to configure bro.cfg and then went back to verify the configuration by hand. However, I am now trying to start bro by hand using the following command line option: bin/bro -i eth0 scan which produces the same problem. -- | David Vasil | Oak Ridge National Laboratory NCCS Division | High Performance Computing Systems Administrator | Bldg: 5600-A115 Phone: (865)241-5562 From jp.luiggi at free.fr Tue Jan 10 06:19:54 2006 From: jp.luiggi at free.fr (Jean-Philippe Luiggi) Date: Tue, 10 Jan 2006 09:19:54 -0500 Subject: [Bro] bro segfaults on startup In-Reply-To: <43C29453.6000400@ornl.gov> References: <43C29453.6000400@ornl.gov> Message-ID: <20060110141954.GA22324@armada.mynetwork.net> Hello, Did you check your "bro.cfg" (/opt/bro/etc/bro.cfg, i think) ? Best regards. On Mon, Jan 09, 2006 at 11:50:27AM -0500, David Vasil wrote: > Hello, I have an x86_64 RHEL4u2 running a 2.6.14.2 kernel on which I > compiled bro-1.0 with the following options: > > ./configure --prefix=/opt/bro > > And did a make install and make install-brolite to create a base > configuration. After that I attempt to run /opt/bro/etc/bro.rc -start > which results in the following: > > [root at endace bro]# etc/bro.rc start > bro.rc: Running as non-root user bro > bro.rc: Starting /opt/bro/etc/bro.rc: line 229: 6635 Segmentation fault > "${BRO}" ${cmd_opts} 2>>"${info_log}" >>"${info_log}" > ........bro.rc: Failed to start Bro > ... FAILED > [root at endace bro]# etc/bro.rc start > bro.rc: Running as non-root user bro > bro.rc: Starting /opt/bro/etc/bro.rc: line 229: 6721 Segmentation fault > "${BRO}" ${cmd_opts} 2>>"${info_log}" >>"${info_log}" > ........bro.rc: Failed to start Bro > ... FAILED > > In dmesg the following is shown: > bro[6635]: segfault at 00000000fffcf678 rip 0000000000561ef5 rsp > 00000000fffcf650 error 4 > bro[6721]: segfault at 00000000ffaafa58 rip 0000000000561ef5 rsp > 00000000ffaafa30 error 4 > > In /var/log/messages the following is shown: > Jan 9 11:38:34 endace su(pam_unix)[6598]: session opened for user bro > by root(uid=0) > Jan 9 11:38:35 endace kernel: bro[6635]: segfault at 00000000fffcf678 > rip 0000000000561ef5 rsp 00000000fffcf650 error 4 > Jan 9 11:38:40 endace bro.rc: Bro has failed to start. Unknown error, > no messages recieved on STDERR or STDOUT > Jan 9 11:38:40 endace bro.rc: Bro process failed on first start > attempt. No further restart attempts will be made. > Jan 9 11:38:41 endace su(pam_unix)[6598]: session closed for user bro > Jan 9 11:41:16 endace su(pam_unix)[6684]: session opened for user bro > by root(uid=0) > Jan 9 11:41:16 endace kernel: bro[6721]: segfault at 00000000ffaafa58 > rip 0000000000561ef5 rsp 00000000ffaafa30 error 4 > Jan 9 11:41:21 endace bro.rc: Bro has failed to start. Unknown error, > no messages recieved on STDERR or STDOUT > Jan 9 11:41:21 endace bro.rc: Bro process failed on first start > attempt. No further restart attempts will be made. > Jan 9 11:41:22 endace su(pam_unix)[6684]: session closed for user bro > > Notice, info, and alarm logfiles are created in bro's logs directory, > however, all of these files are empty. I also tried the bro-0.9a11 > branch, and it behaved the exact same way. Am I missing something? Thanks! > > -- > | David Vasil > | Oak Ridge National Laboratory NCCS Division > | High Performance Computing Systems Administrator > | Bldg: 5600-A115 Phone: (865)241-5562 > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From vern at icir.org Tue Jan 10 10:42:34 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 10 Jan 2006 10:42:34 -0800 Subject: [Bro] bro segfaults on startup In-Reply-To: Your message of Tue, 10 Jan 2006 08:55:00 EST. Message-ID: <200601101842.k0AIgYEx079129@jaguar.icir.org> > Which packet filter do you mean? I meant the libpcap. But: > Scott Campbell mentioned it may be a problem with the resolver library, > as others have had similar problems in the past. this is clearly the problem, given the traceback that terminates inside the resolver library: > (gdb) run -i eth0 mt http ftp scan > Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000561ef5 in __ns_initparse () > (gdb) bt > #0 0x0000000000561ef5 in __ns_initparse () > Cannot access memory at address 0xffd2a510 This may be a longshot, but in the past folks have worked around resolver problems on Linux but linking to /usr/lib/libresolv.a directly. Worth giving a try. FWIW, we run without problems on Red Hat 2.4.21. But we're not running 64-bit native, which it looks like you are. (Our glibc is a slightly older, but I don't imagine that matters.) Scott, do you recall any other fixes? Vern From scampbell at lbl.gov Tue Jan 10 11:01:58 2006 From: scampbell at lbl.gov (scott campbell) Date: Tue, 10 Jan 2006 11:01:58 -0800 Subject: [Bro] bro segfaults on startup In-Reply-To: <200601101842.k0AIgYEx079129@jaguar.icir.org> References: <200601101842.k0AIgYEx079129@jaguar.icir.org> Message-ID: <43C404A6.1040608@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vern Paxson wrote: >>Which packet filter do you mean? > > > I meant the libpcap. But: > > >>Scott Campbell mentioned it may be a problem with the resolver library, >>as others have had similar problems in the past. > > > this is clearly the problem, given the traceback that terminates inside > the resolver library: > > >>(gdb) run -i eth0 mt http ftp scan >>Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan >> >>Program received signal SIGSEGV, Segmentation fault. >>0x0000000000561ef5 in __ns_initparse () >>(gdb) bt >>#0 0x0000000000561ef5 in __ns_initparse () >>Cannot access memory at address 0xffd2a510 > > > This may be a longshot, but in the past folks have worked around resolver > problems on Linux but linking to /usr/lib/libresolv.a directly. Worth > giving a try. > > FWIW, we run without problems on Red Hat 2.4.21. But we're not running > 64-bit native, which it looks like you are. (Our glibc is a slightly older, > but I don't imagine that matters.) > > Scott, do you recall any other fixes? > > Vern > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro Unfortunately I suggested that our discussion get punted back to the list since I have no experience with the 64 bit libs on linux. I suspect that you may be correct about the linking. If that does not work you may want to explore forcing the issue of compiling & running in 32 bit mode. If this continues to be a problem, I can ask around here and see what other peoples suggestions are. scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org iD8DBQFDxASmK2Plq8B7ZBwRAoiaAJ9UuwMZxMCkFw3EohEzYras/o8C1QCfX4eE DWza1FS7TGjOej5uK0OBOCo= =nj3z -----END PGP SIGNATURE----- From robin at icir.org Tue Jan 10 11:28:17 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 10 Jan 2006 11:28:17 -0800 Subject: [Bro] bro segfaults on startup In-Reply-To: <43C404A6.1040608@lbl.gov> References: <200601101842.k0AIgYEx079129@jaguar.icir.org> <43C404A6.1040608@lbl.gov> Message-ID: <20060110192817.GA10466@net.informatik.tu-muenchen.de> On Tue, Jan 10, 2006 at 11:01 -0800, Scott Campbell wrote: > list since I have no experience with the 64 bit libs on linux. I > suspect that you may be correct about the linking. If that does not > work you may want to explore forcing the issue of compiling & running in > 32 bit mode. Ah, 64 bit and resolver-problems, that rings a bell: I've seen core-dumps on a 64bit SUSE Linux which were caused by linking in the 32bit version of the resolver-library. However, I recall that there was a corresponding warning during compiling/linking (which was easy to miss though). David, do you see anything like this? Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org From dmvasil at ornl.gov Tue Jan 10 11:53:46 2006 From: dmvasil at ornl.gov (David Vasil) Date: Tue, 10 Jan 2006 14:53:46 -0500 Subject: [Bro] bro segfaults on startup In-Reply-To: <20060110192817.GA10466@net.informatik.tu-muenchen.de> References: <200601101842.k0AIgYEx079129@jaguar.icir.org> <43C404A6.1040608@lbl.gov> <20060110192817.GA10466@net.informatik.tu-muenchen.de> Message-ID: <43C410CA.3050500@ornl.gov> Robin Sommer wrote: > Ah, 64 bit and resolver-problems, that rings a bell: I've seen > core-dumps on a 64bit SUSE Linux which were caused by linking in the > 32bit version of the resolver-library. However, I recall that there > was a corresponding warning during compiling/linking (which was easy > to miss though). David, do you see anything like this? Yes, during the compile of bro the following message is seen: g++ -g -O2 -o bro dce_rpc_pac.o ncp_pac.o smb_pac.o main.o net_util.o util.o parse.o scan.o re-parse.o re-scan.o rule-parse.o rule-scan.o Active.o Anon.o Attr.o BackDoor.o Base64.o BPF_Program.o BroString.o CCL.o ChunkedIO.o CompHash.o Conn.o ConnCompressor.o DCE_RPC.o DFA.o DNS.o DNS_Mgr.o DbgBreakpoint.o DbgHelp.o DbgWatch.o Debug.o DebugCmds.o DebugLogger.o Desc.o Dict.o Discard.o EquivClass.o Event.o EventHandler.o EventRegistry.o Expr.o FTP.o File.o Finger.o Frag.o Frame.o Func.o Gnutella.o HTTP.o Hash.o ICMP.o ID.o Ident.o IntSet.o InterConn.o IOSource.o IRC.o List.o Logger.o Login.o MIME.o NCP.o NFA.o NFS.o NTP.o NVT.o Net.o NetVar.o NetbiosSSN.o Obj.o OSFinger.o PacketFilter.o PacketSort.o PersistenceSerializer.o PktSrc.o PolicyFile.o POP3.o Portmap.o PrefixTable.o PriorityQueue.o Queue.o RE.o RPC.o Reassem.o RemoteSerializer.o Rlogin.o RSH.o Rule.o RuleAction.o RuleCondition.o RuleMatcher.o ScriptAnaly.o SMB.o SmithWaterman.o SMTP.o SSH.o Scope.o SerializationFormat.o SerialObj.o Serializer.o Sessions.o StateAccess.o Stats.o SteppingStone.o Stmt.o TCP.o TCP_Contents.o TCP_Endpoint.o TCP_Rewriter.o Telnet.o Timer.o Traverse.o TwoWise.o Type.o UDP.o Val.o Var.o XDR.o bsd-getopt-long.o cq.o md5.o patricia.o setsignal.o version.o strsep.o nb_dns.o X509.o SSLCiphers.o SSLInterpreter.o SSLProxy.o SSLv2.o SSLv3.o SSLv3Automaton.o -Llibedit -ledit -L../aux/libpcap-0.7.2 -lpcap -lresolv -lz /usr/lib/libresolv.a -lssl -lcrypto /usr/lib/libresolv.a -ltermcap -lm /usr/bin/ld: warning: i386 architecture of input file `/usr/lib/libresolv.a(ns_parse.o)' is incompatible with i386:x86-64 output I assume that is the error we are looking for. Unfortunately, it seems that removing the references to /usr/lib/libresolv.a in each of the Makefiles causes ns_initparse to go undefined and make fails: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -I/include -c `test -f nb_dns.c || echo './'`nb_dns.c gcc -g -O2 -I/include -o hf hf.o setsignal.o version.o nb_dns.o -L../../aux/libpcap-0.7.2 -lpcap -lresolv -lz -lssl -lcrypto -ltermcap nb_dns.o(.text+0x671): In function `nb_dns_activity': /raid/work/bro-1.0/aux/hf/nb_dns.c:476: undefined reference to `__ns_initparse' nb_dns.o(.text+0x7ae):/raid/work/bro-1.0/aux/hf/nb_dns.c:519: undefined reference to `_ns_flagdata' nb_dns.o(.text+0x7ca):/raid/work/bro-1.0/aux/hf/nb_dns.c:519: undefined reference to `_ns_flagdata' nb_dns.o(.text+0x93c):/raid/work/bro-1.0/aux/hf/nb_dns.c:561: undefined reference to `__ns_parserr' collect2: ld returned 1 exit status make[4]: *** [hf] Error 1 make[4]: Leaving directory `/raid/work/bro-1.0/aux/hf' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/raid/work/bro-1.0/aux' make[2]: *** [all] Error 2 make[2]: Leaving directory `/raid/work/bro-1.0/aux' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/raid/work/bro-1.0' make: *** [all] Error 2 I'll look into it more, figured you might like an update though. -- | David Vasil | Oak Ridge National Laboratory NCCS Division | High Performance Computing Systems Administrator | Bldg: 5600-A115 Phone: (865)241-5562 From robin at icir.org Tue Jan 10 20:04:28 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 10 Jan 2006 20:04:28 -0800 Subject: [Bro] bro segfaults on startup In-Reply-To: <43C410CA.3050500@ornl.gov> References: <200601101842.k0AIgYEx079129@jaguar.icir.org> <43C404A6.1040608@lbl.gov> <20060110192817.GA10466@net.informatik.tu-muenchen.de> <43C410CA.3050500@ornl.gov> Message-ID: <20060111040428.GA12002@net.informatik.tu-muenchen.de> On Tue, Jan 10, 2006 at 14:53 -0500, David Vasil wrote: > `/usr/lib/libresolv.a(ns_parse.o)' is incompatible with i386:x86-64 output That sounds indeed familiar. On the SUSE system, this hack solved the problem: (1) Patching configure.in: --- configure.in~ 2005-12-22 01:12:21.000000000 +0100 +++ configure.in 2005-12-22 01:12:21.000000000 +0100 @@ -241,7 +241,7 @@ dnl Specifying a specific resolver library seems to work/be necessary dnl on all OSs, but Darwin needs -lresolv instead of /usr/lib/libresolv.a dnl We define the default here and overwrite below. --ck -bro_libresolv="/usr/lib/libresolv.a" +bro_libresolv="/usr/lib64/libresolv.a" case "$target_os" in (2) Running ./autogen.sh (3) LDFLAGS=-L/usr/lib64/termcap/ ./configure Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org From dmvasil at ornl.gov Wed Jan 11 05:52:24 2006 From: dmvasil at ornl.gov (David Vasil) Date: Wed, 11 Jan 2006 08:52:24 -0500 Subject: [Bro] bro segfaults on startup In-Reply-To: <20060111040428.GA12002@net.informatik.tu-muenchen.de> References: <200601101842.k0AIgYEx079129@jaguar.icir.org> <43C404A6.1040608@lbl.gov> <20060110192817.GA10466@net.informatik.tu-muenchen.de> <43C410CA.3050500@ornl.gov> <20060111040428.GA12002@net.informatik.tu-muenchen.de> Message-ID: <43C50D98.9060606@ornl.gov> Robin Sommer wrote: > On Tue, Jan 10, 2006 at 14:53 -0500, David Vasil wrote: > > >>`/usr/lib/libresolv.a(ns_parse.o)' is incompatible with i386:x86-64 output > > > That sounds indeed familiar. On the SUSE system, this hack solved > the problem: > > (1) Patching configure.in: > > --- configure.in~ 2005-12-22 01:12:21.000000000 +0100 > +++ configure.in 2005-12-22 01:12:21.000000000 +0100 > @@ -241,7 +241,7 @@ > dnl Specifying a specific resolver library seems to work/be necessary > dnl on all OSs, but Darwin needs -lresolv instead of > /usr/lib/libresolv.a > dnl We define the default here and overwrite below. --ck > -bro_libresolv="/usr/lib/libresolv.a" > +bro_libresolv="/usr/lib64/libresolv.a" > > case "$target_os" in > > (2) Running ./autogen.sh > > (3) LDFLAGS=-L/usr/lib64/termcap/ ./configure > > Robin This did indeed fix my problems. Thank you very much. Bro now successfully initializes and begins running. -- | David Vasil | Oak Ridge National Laboratory NCCS Division | High Performance Computing Systems Administrator | Bldg: 5600-A115 Phone: (865)241-5562 From bltierney at lbl.gov Tue Jan 24 13:17:46 2006 From: bltierney at lbl.gov (Brian Tierney) Date: Tue, 24 Jan 2006 16:17:46 -0500 Subject: [Bro] short Bro User Survey References: Message-ID: Hi All: We'd like to get a better feel for who is using Bro and how. Please send me an email stating which of the following best describes your use of Bro: - Using Bro as the primary production network IDS for your site/group - Using Bro as the secondary production network IDS for your site/group - Using Bro for off-line analysis for forensics, etc. - Using Bro for traffic characterization studies only - just playing around with Bro. Thanks for your reply. From adayadil.thomas at gmail.com Tue Jan 24 13:54:29 2006 From: adayadil.thomas at gmail.com (Adayadil Thomas) Date: Tue, 24 Jan 2006 16:54:29 -0500 Subject: [Bro] short Bro User Survey In-Reply-To: References: Message-ID: Will you be publishing that info ? I would like to know how popular bro is :) On 1/24/06, Brian Tierney wrote: > > Hi All: > > We'd like to get a better feel for who is using Bro and how. Please send > me an email stating which of the following best describes your use of > Bro: > > - Using Bro as the primary production network IDS for your site/group > - Using Bro as the secondary production network IDS for your site/group > - Using Bro for off-line analysis for forensics, etc. > - Using Bro for traffic characterization studies only > - just playing around with Bro. > > Thanks for your reply. > > > _______________________________________________ > 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/20060124/85afe0f3/attachment.html From bltierney at lbl.gov Wed Jan 25 07:05:54 2006 From: bltierney at lbl.gov (Brian Tierney) Date: Wed, 25 Jan 2006 10:05:54 -0500 Subject: [Bro] short Bro User Survey In-Reply-To: References: Message-ID: <10682204-F374-4ABB-807E-6FB4B1BAE9DB@lbl.gov> On Jan 24, 2006, at 4:54 PM, Adayadil Thomas wrote: > Will you be publishing that info ? > I would like to know how popular bro is :) > Sure, I plan to post anonymized results. From adayadil.thomas at gmail.com Thu Jan 26 09:52:44 2006 From: adayadil.thomas at gmail.com (Adayadil Thomas) Date: Thu, 26 Jan 2006 12:52:44 -0500 Subject: [Bro] Bro: TCP reassembly question Message-ID: Greetings. I have a couple of questions about BRO's tcp stream reassembly. Please reply if you have answers. When does bro allocate memory for doing reassembly (putting the different blocks of data together) ? Does it append to this same buffer when subsequent stream data comes ? What is the size of the reassembly buffer ? Does that grow ? till what size does it grow ? Any information or pointers is appreciated. Thanks a lot Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20060126/08f87ee7/attachment.html From rpang at cs.princeton.edu Thu Jan 26 11:12:11 2006 From: rpang at cs.princeton.edu (=?HZ-GB-2312?Q?Ruoming_Pang_=28~{ESHtCy~}=29?=) Date: Thu, 26 Jan 2006 14:12:11 -0500 Subject: [Bro] Bro: TCP reassembly question In-Reply-To: References: Message-ID: <734728ec8e0afbe215e77d0c0262092b@cs.princeton.edu> Hi Thomas, I'd like to first clarify that the TCP reassembler does not have to putting different blocks in a single buffer. Instead, its job is to deliver the bytes in order, no matter how many bytes it delivers at a time. On top of that, some ASCII protocol analyzers (such as HTTP) employ a line reassembler, while binary protocol analyzers (such as RPC) have their own frame reassembler. Therefore, the TCP reassembler uses a linked list, instead of a single buffer, for TCP reassembly. > When does bro allocate memory for doing reassembly (putting the > different blocks of data together) ? In theory, the TCP reassembler only needs to copy segments that arrive out of order. In practice, though, Bro makes a copy of every segment, and deallocate the copy once it is delivered. > What is the size of the reassembly buffer ? Does that grow ? till what > size does it grow ? That's a great question. I'm not aware of any cap on the total size of reassembly buffers. I hope that I answered your questions. Ruoming On Jan 26, 2006, at 12:52 PM, Adayadil Thomas wrote: > Greetings. > > I have a couple of questions about BRO's tcp stream reassembly. > Please reply if you have answers. > > When does bro allocate memory for doing reassembly (putting the > different blocks of data together) ? > Does it append to this same buffer when subsequent stream data comes ? > What is the size of the reassembly buffer ? Does that grow ? till > what size does it grow ? > > > Any information or pointers is appreciated. > > Thanks a lot > Thomas From vern at icir.org Fri Jan 27 00:52:40 2006 From: vern at icir.org (Vern Paxson) Date: Fri, 27 Jan 2006 00:52:40 -0800 Subject: [Bro] Bro: TCP reassembly question In-Reply-To: Your message of Thu, 26 Jan 2006 14:12:11 EST. Message-ID: <200601270852.k0R8qeEH000320@jaguar.icir.org> > > What is the size of the reassembly buffer ? Does that grow ? till what > > size does it grow ? > > That's a great question. I'm not aware of any cap on the total size of > reassembly buffers. Indeed, there isn't, other than exhausting memory. In a USENIX Security paper last year with Sarang Dharmapurikar, we showed that in the absence of an adversary attempting to exhaust this memory, the actual consumption in operation is quite modest (10s to 100s of KBs). With an adversary, though, it gets harder, and Bro at present is vulnerable to such an attack. Vern From christian at whoop.org Sat Jan 28 11:00:00 2006 From: christian at whoop.org (Christian Kreibich) Date: Sat, 28 Jan 2006 19:00:00 +0000 Subject: [Bro] Questions about signature regexes Message-ID: <1138474800.12602.251.camel@localhost> Hi, a few quick questions about the regular expressions used in rule content conditions. - Are they PCREs? I see a lot of "# Not supported: pcre" in scripts/23b/example_bro_files/signatures.sig and wanted to make sure. - When I want a pattern to match at the beginning of the payload, I presume I have to say "payload /^", right? - Can I match on fixed TCP stream content of a given length by giving the whole string surrounded by ^ and $, i.e., this: payload /^foo$/ Thanks! Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From christian at whoop.org Sat Jan 28 12:52:40 2006 From: christian at whoop.org (Christian Kreibich) Date: Sat, 28 Jan 2006 20:52:40 +0000 Subject: [Bro] Persistent state and bro_init(). Message-ID: <1138481561.12602.258.camel@localhost> Hi, I have two policy files: one that builds up persistent state and one that uses this previously generated persistent state. I want to ensure that in repeated invocations of the first script, the persistent data structure is cleared. I could do this in bro_init(). Is persistent state all set up and ready by the time bro_init event handlers are executed? Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From robin at icir.org Sat Jan 28 20:23:12 2006 From: robin at icir.org (Robin Sommer) Date: Sat, 28 Jan 2006 20:23:12 -0800 Subject: [Bro] Questions about signature regexes In-Reply-To: <1138474800.12602.251.camel@localhost> References: <1138474800.12602.251.camel@localhost> Message-ID: <20060129042312.GC27900@net.informatik.tu-muenchen.de> On Sat, Jan 28, 2006 at 19:00 +0000, you wrote: > - Are they PCREs? I see a lot of "# Not supported: pcre" in They are regexps but not PCREs; they use Bro's syntax which is slightly different. (That reminds me that I've a prototypical pcre->bro converter lying around somewhere. But actually there doesn't seem to be much interest in automatically converting Snort sigs these days.) > - When I want a pattern to match at the beginning of the payload, I > presume I have to say "payload /^", right? Right. Alternatively you can just leave the "^" out as the regexps are implictly anchored at the first byte. To match at arbitrary positions, a wildcard is required, e.g., "/.*foo/. > - Can I match on fixed TCP stream content of a given length by giving > the whole string surrounded by ^ and $, i.e., this: Yes. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sat Jan 28 20:24:31 2006 From: robin at icir.org (Robin Sommer) Date: Sat, 28 Jan 2006 20:24:31 -0800 Subject: [Bro] Persistent state and bro_init(). In-Reply-To: <1138481561.12602.258.camel@localhost> References: <1138481561.12602.258.camel@localhost> Message-ID: <20060129042431.GA28086@net.informatik.tu-muenchen.de> On Sat, Jan 28, 2006 at 20:52 +0000, Christian Kreibich wrote: > I could do this in bro_init(). Is persistent state all set up and ready > by the time bro_init event handlers are executed? Yes. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org From jp.luiggi at free.fr Mon Jan 30 05:41:48 2006 From: jp.luiggi at free.fr (Jean-Philippe Luiggi) Date: Mon, 30 Jan 2006 08:41:48 -0500 Subject: [Bro] Some questions and Netflow. Message-ID: <20060130134147.GA178@armada.mynetwork.net> Hello everybody. I've some questions... Do there's a GUI or something likes this in order to see the various alerts ? I saw there's perhaps "Brooery" but is it available ? A tool likes this is very valuable if we plan to install the IDS to people with a minimum of background with computers. I recently 'sacrified' an old laptop with an old distro and installed it with access to Internet (ssh input allowed) behind my gateway, some very easy login/password after i got a very nice IRC bot... What i now want to do is to raise up alerts if connections come from the inside. Sound likes a "nbad.bro" or something else likes this may be helpful ? We talked in the past of Netflow, the good concept used by "Cisco", how do you see working with it ? At least, two choices : - Using Bro as a Netflow concentrator. - Using a dedicated tool to capture the flows and then use "Bro" to inspect data. I work all the day with the "flow-tools" package from "OSU" but there are several others floating around and each one with different format. And what about the future things to come (the famous TODO) ? Thank you. Best regards. From aashish at uiuc.edu Mon Jan 30 09:19:05 2006 From: aashish at uiuc.edu (Aashish Sharma) Date: Mon, 30 Jan 2006 11:19:05 -0600 Subject: [Bro] Questions about signature regexes In-Reply-To: <20060129042312.GC27900@net.informatik.tu-muenchen.de> Message-ID: <20060130171905.GA19174@uiuc.edu> Hi Robin : > (That reminds me that I've a prototypical pcre->bro converter lying > around somewhere. But actually there doesn't seem to be much > interest in automatically converting Snort sigs these days.) > We have been using snort2bro script, but it has quite a few limitations. A better, more comprehensive automatic conversion tool would definitely be something I would be interested in to use with our bro installation. Just thought I should put it on the table. Thanks Aashish Sharma -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20060130/6e93c969/attachment.bin From bltierney at lbl.gov Mon Jan 30 10:59:42 2006 From: bltierney at lbl.gov (Brian Tierney) Date: Mon, 30 Jan 2006 10:59:42 -0800 Subject: [Bro] summary of short Bro User Survey results In-Reply-To: <20060126070328.GA11030@uiuc.edu> References: <20060126070328.GA11030@uiuc.edu> Message-ID: <21FAB984-939B-4098-9453-CB888545414B@lbl.gov> Here are the summarized results so far. If you haven't replied yet, please do! - Using Bro as the primary production network IDS for your site/group 4 (LBL, NERSC, NCSA, 1 small business net) - Using Bro as the secondary production network IDS for your site/group 1 - Using Bro for off-line analysis for forensics, etc. 1 - Using Bro for traffic characterization studies only 2 - just playing around with Bro. 1 - currently just playing around with Bro, but hoping to use it in production soon 2 Other replies: - using Bro as part of a NIDS product - using Bro for research purposes From christian at whoop.org Mon Jan 30 13:21:04 2006 From: christian at whoop.org (Christian Kreibich) Date: Mon, 30 Jan 2006 21:21:04 +0000 Subject: [Bro] Some questions and Netflow. In-Reply-To: <20060130134147.GA178@armada.mynetwork.net> References: <20060130134147.GA178@armada.mynetwork.net> Message-ID: <1138656064.4161.154.camel@localhost> Hi, On Mon, 2006-01-30 at 08:41 -0500, Jean-Philippe Luiggi wrote: > Hello everybody. > > I've some questions... > > Do there's a GUI or something likes this in order to see the various alerts ? > I saw there's perhaps "Brooery" but is it available ? > A tool likes this is very valuable if we plan to install the IDS to people > with a minimum of background with computers. the Brooery was an experimental prototype and not in shape for everyday use, sorry. > And what about the future things to come (the famous TODO) ? Papers, PhD theses, fame, startups, ... :) Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From gfreeman at ucdavis.edu Mon Jan 30 14:45:12 2006 From: gfreeman at ucdavis.edu (Graham Freeman) Date: Mon, 30 Jan 2006 14:45:12 -0800 Subject: [Bro] Questions about signature regexes In-Reply-To: <20060130171905.GA19174@uiuc.edu> References: <20060130171905.GA19174@uiuc.edu> Message-ID: <094F5275-CCC5-47D6-8DF3-09AC5BDFBB50@ucdavis.edu> On Jan 30, 2006, at 9:19 AM, Aashish Sharma wrote: > Hi Robin : > >> (That reminds me that I've a prototypical pcre->bro converter lying >> around somewhere. But actually there doesn't seem to be much >> interest in automatically converting Snort sigs these days.) >> > > We have been using snort2bro script, but it has quite a few > limitations. A better, more comprehensive automatic conversion tool > would definitely be something I would be interested in to use with > our bro installation. > > Just thought I should put it on the table. > > Thanks > Aashish Sharma > Although we're likely to significantly re-architect our IDS infrastructure soon, we would be happy with a more comprehensive and modern snort2bro functional equivalent. Being stuck with the Snort v2.2 ruleset is one of the downsides that would be nice to fix. If we end up modifying snort2bro or writing our own (unlikely), I'll advocate that we contribute it to the Bro project. Graham Freeman Datacenter Security Administrator IET - Datacenter & Client Services University of California at Davis gfreeman at ucdavis.edu GPG Key 0xFEE4DF44 From jp.luiggi at free.fr Tue Jan 31 05:52:16 2006 From: jp.luiggi at free.fr (Jean-Philippe Luiggi) Date: Tue, 31 Jan 2006 08:52:16 -0500 Subject: [Bro] Some questions and Netflow. In-Reply-To: <1138656064.4161.154.camel@localhost> References: <20060130134147.GA178@armada.mynetwork.net> <1138656064.4161.154.camel@localhost> Message-ID: <20060131135216.GB14021@armada.mynetwork.net> Hello, On Mon, Jan 30, 2006 at 09:21:04PM +0000, Christian Kreibich wrote: > the Brooery was an experimental prototype and not in shape for everyday > use, sorry. > So it may be time to think to a tool... :-)) > > And what about the future things to come (the famous TODO) ? > > Papers, PhD theses, fame, startups, ... :) :-) Why not ? Do there's informations about next releases and what they will bring up ? Best regards. From robin at icir.org Tue Jan 31 16:29:35 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 31 Jan 2006 16:29:35 -0800 Subject: [Bro] Questions about signature regexes In-Reply-To: <094F5275-CCC5-47D6-8DF3-09AC5BDFBB50@ucdavis.edu> <20060130171905.GA19174@uiuc.edu> References: <20060130171905.GA19174@uiuc.edu> <094F5275-CCC5-47D6-8DF3-09AC5BDFBB50@ucdavis.edu> <20060129042312.GC27900@net.informatik.tu-muenchen.de> <20060130171905.GA19174@uiuc.edu> Message-ID: <20060201002935.GA8973@net.informatik.tu-muenchen.de> On Mon, Jan 30, 2006 at 11:19 -0600, Aashish Sharma wrote: > would definitely be something I would be interested in to use with > our bro installation. On Mon, Jan 30, 2006 at 14:45 -0800, Graham Freeman wrote: > infrastructure soon, we would be happy with a more comprehensive and > modern snort2bro functional equivalent. Let's do another poll: are there more readers of this list who'd be interested in an updated Snort2Bro which can work with current Snort signatures? In case there is demand, is there perhaps even somebody who'd be able to contribute some time to developing an updated converter? While I'll probably won't be able to work much on this myself, I could contribute the pieces which I have as well as, e.g., extend Bro's signature engine somewhat if this turn out to be neccessary. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Tue Jan 31 16:44:18 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 31 Jan 2006 16:44:18 -0800 Subject: [Bro] Some questions and Netflow. In-Reply-To: <20060130134147.GA178@armada.mynetwork.net> References: <20060130134147.GA178@armada.mynetwork.net> Message-ID: <20060201004418.GC8973@net.informatik.tu-muenchen.de> On Mon, Jan 30, 2006 at 08:41 -0500, Jean-Philippe Luiggi wrote: > - Using Bro as a Netflow concentrator. > - Using a dedicated tool to capture the flows and then use "Bro" to inspect data. Both approaches seem to be reasonable. There has been some discussion of integrating NetFlow into Bro for some time now but, as far as I'm aware of, nothing concrete has materialized yet. It's on our radar though and indeed part of a planned future project (with no concrete time schedule yet though). Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org