zeek May 2012

zeek@lists.zeek.org

22 participants
22 discussions

by Dave Angelo

Hello, I am trying to add BRO the ability to ignore traffic from certain IP ranges dynamically. I have a DB with IP addresses (that chances once in a while) and I would like to write a BRO script that will query the DB once in a while, grab those IP addresses and drop new connections with these IP's. Question: 1. Is it possible to query a DB from BRO scripts? is there any examples? 2. Assuming yes, should i implement this logic at the 'new_connection' event? (I would like to drop connections from these IP's as soon as possible). Thank You Dave

8 years, 10 months

[Bro] broctl Email Reports

by Chris Crawford

I like that broctl will roll logs over every hour. My default broctl.cfg file includes: # Rotation interval in seconds for log files on manager/standalone node. LogRotationInterval = 3600 I don't like getting an email from broctl every hour, though. Is there a way to get a daily report, instead of an hourly report? Related -- The Bro README [1] claims: "BroControl sends four types of mails to the address given in MailTo: 1. When logs are rotated (per default once a day), a list of all alarms during the last rotation interval is sent. This can be disabled by setting MailAlarms=0." But elsewhere in the README: "LogRotationInterval (int, default 3600) The frequency of log rotation in seconds for the manager/standalone node." This is confusing to me -- maybe someone can help me understand. Are they talking about two different things? [1] http://www.bro-ids.org/documentation/components/broctl/README.html

9 years

[Bro] pcap_next Question

by Chris Crawford

Bro 2 has been crashing for me regularly and frequently for several months. [ http://bit.ly/JJQVVf ] Although I configured Bro in a way that works for me, it would still be nice to use it as it is intended to be used. I studied a number of crash dumps, and have looked through the code. I was seeing crashes with the Bro 2.0 release, but I am now using a version of Bro 2.0 from the git repositories that I checked out on April 30. I saw very similar crashes in both versions. Line 78 in PktSrc.cc is consistently related to issues in the backtraces I'm getting from bro core dumps. I really haven't written much code with libpcap, so there's probably a good reason to use pcap_next() there. I'm just wondering, why not use pcap_next_ex() there and do a bit of error checking before passing packet data along? The way it is right now, it looks like the code just trusts that pcap_next() read a packet successfully and then hands it off. I think that in my case, something is going wrong with the call to pcap_next() -- it's returning a pointer that doesn't make any sense. If there was a little error checking around pcap_next() by using pcap_next_ex() instead, maybe that would prevent the crash I'm seeing. On the other hand, maybe there is some code that does some error checking on if the value returned by pcap_next() makes sense and I'm just not finding it. Can anyone help me understand the choice to use pcap_next() vs pcap_next_ext()?

9 years, 1 month

[Bro] Dropped Packets

by Will Havlovick

Hi all, I recently upgraded 3 standalone Bro nodes. 2 of them are Ubuntu and one of them is CentOS 6.2. On the 2 Ubuntu 11.10 boxes I have a lot of dropped packets in the notice.log --- PacketFilter::Dropped_Packets 476 packets dropped after filtering, 52258 received, 52258 on link PacketFilter::Dropped_Packets 4914 packets dropped after filtering, 52785 received, 52785 on link PacketFilter::Dropped_Packets 3061 packets dropped after filtering, 35701 received, 35702 on link PacketFilter::Dropped_Packets 3371 packets dropped after filtering, 30573 received, 30591 on link --- broctl netstats bro: 1326394056.309957 recvd=958721774 dropped=67351350 link=1026073125 I then tried to add this line to the broctl.cfg from http://comments.gmane.org/gmane.comp.security.detection.bro/4146 broargs = -l 9800 Which does not appear to be part of the final release and did not work. The CentOS box is dropping packets, but not the amounts that the 2 Ubuntu boxes are. Is there a way to reduce the amount of dropped packets? Also, I can provide more data if necessary. Thank you in advance, Will

9 years, 3 months

[Bro] Debugging Policies and Print Statement

by Chris Green

Good day, I'm using bro version 2.0-372 with a new git checkout from master as of 2012-05-27 on Centos6. I'm having an issue where the print statement in the policy debugger displays nothing. Breakpoints and stack tracks seem to work correctly but not being able to inspect variables is making playing with policies frustrating. Is this a known issue or is there some type of preprocessing make inspection work? Thanks, Chris In bro_init() at /usr/local/bro/share/bro/base/utils/site.bro:155 155 local_dns_suffix_regex = set_to_regex(local_zones, "(^\\.?|\\.)(~~)$"); (Bro [0]) break http_entity_data Setting breakpoint on http_entity_data: There are multiple definitions of that event handler. Please choose one of the following options: [1] /usr/local/bro/share/bro/base/protocols/http/./file-ident.bro:79 [2] /usr/local/bro/share/bro/base/protocols/http/./file-hash.bro:37 [3] /usr/local/bro/share/bro/base/protocols/http/./file-extract.bro:32 [4] /usr/local/bro/share/bro/base/protocols/http/./file-ident.bro:85 [a] All of the above [n] None of the above Enter your choice: 2 Breakpoint 1 set at http_entity_data at /usr/local/bro/share/bro/base/protocols/http/./file-hash.bro:37 (Bro [1]) c Continuing. Breakpoint 1, http_entity_data(c = '[id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], orig=[size=121, state=4, num_pkts=4, num_bytes_ip=216, flow_label=0], resp=[size=3095, state=4, num_pkts=4, num_bytes_ip=1963, flow_label=0], start_time=1338087055.218736, duration=0.27459, service={ }, addl=, hot=0, history=ShACad, uid=cTLeNAfgQo2, dpd=<uninitialized>, conn=[ts=1338087055.218736, uid=cTLeNAfgQo2, id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], proto=tcp, service=<uninitialized>, duration=<uninitialized>, orig_bytes=<uninitialized>, resp_bytes=<uninitialized>, conn_state=<uninitialized>, local_orig=T, missed_bytes=121, history=<uninitialized>, orig_pkts=<uninitialized>, orig_ip_bytes=<uninitialized>, resp_pkts=<uninitialized>, resp_ip_bytes=<uninitialized>], extract_orig=F, extract_resp=F, dns=<uninitialized>, dns_state=<uninitialized>, ftp=<uninitialized>, http=[ts=1338087055.413572, uid=cTLeNAfgQo2, id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], trans_depth=0, method=<uninitialized>, host=<uninitialized>, uri=<uninitialized>, referrer=<uninitialized>, user_agent=<uninitialized>, request_body_len=0, response_body_len=0, status_code=200, status_msg=OK, info_code=<uninitialized>, info_msg=<uninitialized>, filename=<uninitialized>, tags={ }, username=<uninitialized>, password=<uninitialized>, capture_password=F, proxied=<uninitialized>, mime_type=application/x-dosexec, first_chunk=T, md5=<uninitialized>, calc_md5=F, calculating_md5=F, extraction_file=<uninitialized>, extract_file=F], http_state=[pending={ [0] = [ts=1338087055.413572, uid=cTLeNAfgQo2, id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], trans_depth=0, method=<uninitialized>, host=<uninitialized>, uri=<uninitialized>, referrer=<uninitialized>, user_agent=<uninitialized>, request_body_len=0, response_body_len=0, status_code=<uninitialized>, status_msg=<uninitialized>, info_code=<uninitialized>, info_msg=<uninitialized>, filename=<uninitialized>, tags={ }, username=<uninitialized>, password=<uninitialized>, capture_password=F, proxied=<uninitialized>, mime_type=<uninitialized>, first_chunk=T, md5=<uninitialized>, calc_md5=F, calculating_md5=F, extraction_file=<uninitialized>, extract_file=F], [1] = [ts=1338087055.413572, uid=cTLeNAfgQo2, id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], trans_depth=0, method=<uninitialized>, host=<uninitialized>, uri=<uninitialized>, referrer=<uninitialized>, user_agent=<uninitialized>, request_body_len=0, response_body_len=0, status_code=200, status_msg=OK, info_code=<uninitialized>, info_msg=<uninitialized>, filename=<uninitialized>, tags={ }, username=<uninitialized>, password=<uninitialized>, capture_password=F, proxied=<uninitialized>, mime_type=application/x-dosexec, first_chunk=T, md5=<uninitialized>, calc_md5=F, calculating_md5=F, extraction_file=<uninitialized>, extract_file=F] }, current_request=0, current_response=1], irc=<uninitialized>, smtp=<uninitialized>, smtp_state=<uninitialized>, ssh=<uninitialized>, ssl=<uninitialized>, syslog=<uninitialized>, known_services_done=F]', is_orig = 'F', length = '1500', data = 'MZ\x90\0^C\0\0\0^D\0\0\0\xff\xff\0\0\xb8\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x80\0\0\0^N\x1f\xba^N\0\xb4^I\xcd!\xb8^AL\xcd!This program cannot be run in DOS mode.^M^M^J$\0\0\0\0\0\0\0PE\0\0L^A^C\0`\xdf\x9cO\0\xe2!\0\0\0\0\0\xe0\0/^C^K^A^B^V\0\xd0^I\0\0\0^A\0\0\xc0^Y\0^P\x85#\0\0\xd0^Y\0\0\xa0#\0\0\0@\0\0^P\0\0\0^B\0\0^D\0\0\0^A\0\0\0^D\0\0\0\0\0\0\0\0\xa0$\0\0^P\0\0\0\0\0\0^B\0\0\x80\0\0 \0\0^P\0\0\0\0^P\0\0^P\0\0\0\0\0\0^P\0\0\0\0\0\0\0\0\0\0\0^T\x9a$\0l^B\0\0\0\xa0#\0^T\xfa\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xf0\x90#\0^X\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0UPX0\0\0\0\0\0\xc0^Y\0\0^P\0\0\0\0\0\0\0^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x80\0\0\xe0UPX1\0\0\0\0\0\xd0^I\0\0\xd0^Y\0\0\xc2^I\0\0^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0@ \0\0\xe0.rsrc\0\0\0\0\0^A\0\0\xa0#\0\0\xfe\0\0\0\xc4^I\0\0\0\0\0\0\0\0\0\0\0\0\0@\0\0\xc03.07\0UPX!^M^I^N^G\x8c*]\xc2\xf4\x96\xc3\xc8\xd3e#\0\xf2\xb4^I\0\x1d\xe2!\0&\x1e\0\xb0^Z^C\0*\xa2X\xa54\x1ec\x1d\xbe^Wo\xc6UdK\xb5\xd9/kuB"\x9e^Q\xa5e\xe73\x1f\xc6Z\x91^Q\x8e\xd8\x97^BF\xba^P\xbdp\x92\xb4"7/\x92,\xf3\x9eg\x90\xfe^T\xfa|\xb7\xba\x8d0^T,\xf6K\x9a\xdf`:\x9e\xceJ\xe8\x98u\xa4(\xe2(\xd0H)^C\x90\x95>q\xca \xfa^D\x963\xff2\x86QD'\xe0\xf5\x9a,\x9d^H4V\xda\xd5\xd0\xb5[^E|\x8e\xfd\x83\xd8^U\xa9\xd7^F^S\xa7\xe9\x91\xc7 ~\xd3\xc7^B\x90\x1en\xbb\xe6\xa2\xb5\x8e\xe7\xf7\xbe\xc5\x86g\xe2^W\xff\xd2RG\xd6\xb2P\xd9\x8a\x8f\xf5^D]B|i\x9c\x97W\xf8^NL\x8a\x9dsk\xdac\xb5^V\xe3\xa0\xf14\x94^K\xb8\xff^ER\xfa\xe4\xf8\x955\xdd\xa1\xa8\0^Y^Qr/^E\x9a\xb4\xee}\xde\xb7@ \xf2\x92^N/\xe4L\xc5\xd3\xebT\xcb\xa1&\x90^A\xbcC\xd9\xdaW\x9f^A^Vbt\x9f\xb1\x81\x1dX^Mx^\xeb6^H{v\xeeA\xeeAA\x9eD\x81E\xe1\xdeA\xa8\x1f^U\xe6\xd2\xbcr\xf1cIc\xac^TB\x8d\xd8\x8a\xf5\xd1L\xac\xd9\xad\xbb%\xc8=^J\x87\x1b\x89\xa46\x8d;d\xfd\xd8$\xf7=Y^I\xdev\x85]h^BNT\x9c^UL8\xb9%M^Y\x83\xc0C^G\xa1\xd9L^S\x854\xdfi^A\xf8;\xe9\x90^Hj@ ^\x1fO^S:\xfc%\xf9*\\x98\x1e\xf2b\xcc\xb3^Y^Ga\xa0\xf5tw;\xddg^?^CG\x8f\x88\xef^B\xbb\xcd=^Thn\x1b\xa3^O\xf1^E\xb5\xa1\0@ \x85\xe0\x8b\xf5^GW\xc0\x94\x8a\xee\xa7^T\x99\xd7qq'6\xa9X\xe4#;\xefg4D\x82^G\l\xbbH\x82\xbc\xc2G\xf7\xca\x9f\xa5K@ \x1e\xe7lB^O\xe3\xbd+\xf4\xa1\x89\xd1@ \xc4\xc6\xd6\x1b^U^Fpf\x89h\xc3G\xf3\x88o^Fg\xe7#q\x9d\x1d\xd9\xa1,\x81\xc6\x9bF^R^P^\xd5H)()^T8\xebT\x86\xc0\xd8\x1c_\x95\xe6\xab\x82l=\x82v\x90\xb2g\xf6O\xecE(\xa0\xceR\6)^OX[\xea\xcf\x89^Qd\xbeg^Q\xc7\xc0\xed\x90FG\x80:/!b\x1d^S\xa8\x89\x95\x8e>\xea\xe1s|^?,\xf2\xe6d\xb8\xee)\xd9Ti\xefO\xa2\xdb\xab\xeb\xf1\xe6\xc70W\x89\xdam\xbd\x8ewiS\xc5\x95^G^C\xadM\xbf^K\xdb\xed\xa0\x97K\xe9\x1c\xf2^?\x92k\x92Vk\x89>\xb9l\xff\x80\x97^UXN\xbf\x90[\xe6AH)X\xe99\xce\xb5\xf0>^E'\xb1C^J\xe0\x82\xc1\xffj3u\xe8\xbb\xaeyE#\xb8\xbe\xa7\xa9\xeb\x93{\xa3\x90^Y\xe1,[.Y\xf3^Z\xa8\xa5\x99\x96\xc5sI=\xa5\xf0~\xc1^M\xe2\xc7RK^XF\x80\x1bhX\xdc\xc4P\xcb^P^W^Z\xe2\x8a\xdb'@a ;\xa9\xa0^G"+d\x9f\xa0\xd1j\x993\x83^A\xaa\x80\xfc\xc3\x8f\xf3\xf2\xd1\x96kG\xa8\xf7\xb1\xf4\xe6\xd4\x9d\xc4Y\xbc\xd9\xc1\xaf^D^N\xce^Q\xf6\xd9H^E^?\xe6\xfc\xe6\x8210\x1f\x86yrO\x96s\xffU^R3^V\xa6^UD\xb3^Nt\xed"\x92\xa3``\xd4^Fn\xdb^Lf\xd5\xc2^K1^E\xdf\xa6\xe7\xbc\xb8'=\xa9\xeft\xeb;O1R\x1er\xccC&\x99\xba\x85t\xfa\xc8\xe7^D\xdc5\x1bN@M\x8cFrB2\xe3\x83^So^U\xcf\x9cu\xde9\xe7xV"$Q\^K\xef^U^M\xbd\x99\xd5I^EgS\xfe\xaf\xa3^I\x80P\xad!\x88\x97;\x85\xf1\x95\xed^Y^Im\xd9\x93\x9e4O\xe4Y^S\x88\x88^F\xa8'^U_}\xa1\xcbh.;\xe6\xc7\xac^KSGvF<\xe4i\xe7GN\0rV\xbd\xcf}`\x84\xa5^G\xe6\xa1U\xc6\x91,^Ct\xe0A\x99\x9d^O\xffj\xe8\xf4n\x86^^J\xf1\x91.\xaa\xc0^Y?\x8bV^N\xc1\x8aJPhh\xfa\xbc\xf3\x9e\xd1yX\0\x1f$^Ml(\xe6\xbd^Ji\xd9') at /usr/local/bro/share/bro/base/protocols/http/./file-hash.bro:37 In http_entity_data(c = '[id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], orig=[size=121, state=4, num_pkts=4, num_bytes_ip=216, flow_label=0], resp=[size=3095, state=4, num_pkts=4, num_bytes_ip=1963, flow_label=0], start_time=1338087055.218736, duration=0.27459, service={ }, addl=, hot=0, history=ShACad, uid=cTLeNAfgQo2, dpd=<uninitialized>, conn=[ts=1338087055.218736, uid=cTLeNAfgQo2, id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_h=209.132.180.131, resp_p=80/tcp], proto=tcp, service=<uninitialized>, duration=<uninitialized>, orig_bytes=<uninitialized>, resp_bytes=<uninitialized>, conn_state=<uninitialized>, local_orig=T, missed_bytes=121, history=<uninitialized>, orig_pkts=<uninitialized>, orig_ip_bytes=<uninitialized>, resp_pkts=<uninitialized>, resp_ip_bytes=<uninitialized>], extract_orig=F, extract_resp=F, dns=<uninitialized>, dns_state=<uninitialized>, ftp=<uninitialized>, http=[ts=1338087055.413572, uid=cTLeNAfgQo2, id=[orig_h=192.168.1.13, orig_p=50402/tcp, resp_ 37 if ( is_orig || ! c?$http ) return; (Bro [2]) print c (Bro [3]) print is_orig -- Chris Green <greencm(a)gmail.com>

9 years, 3 months

[Bro] Using expire attributes for nested compound types

by Kamran Riaz Khan

Hello, If I have a table of set, it's pretty straight-forward to add expiring timers for the parent table: -- global test_table: table[count] of set[string] &read_expire = 1 day &expire_func = test_expire; -- However, I can't figure out a way to define {read,write,create}_expire attributes for the *child*, i.e., set[string]. I have tried defining the timers when adding the table entry: -- test_table[0] = set("Hello", "World") &create_expire = 1 usec; -- But the string entries do not expire 1 usec after creation. Any ideas on how to accomplish this? Regards, -- Kamran Riaz Khan. http://inspirated.com/

9 years, 3 months

[Bro] Event for syn-ack packet

by Sheharbano Khattak

Hi, I want to identify hosts within our monitored network that reply to certain external IP addresses. The reply could be as short as a syn-ack. The event connection_established is too late as it doesn't matter whether the connection was established. All that matters is whether any of our hosts replied to the external IP even if that means a single syn-ack packet. Do we have an event that could be used to capture this information? Regards, -- Sheharbano Khattak http://etheryell.com

9 years, 4 months

[Bro] Bro Exchange 2012!

by Seth Hall

http://blog.bro-ids.org/2012/05/announcing-bro-exchange-2012.html .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/

9 years, 4 months

Re: [Bro] http response encoded length ?

by Seth Hall

On May 16, 2012, at 4:56 PM, Dalton Porter wrote: > One of the requirements for my project is to measure the bytes sent and received on the wire. I'm thinking there must be a counter - maybe in conn that could be used for this.resp_ip_bytes looks promising, but I have not figured out how to use it yet. Ah! Ok, that's available but you have to be aware of what you are measuring. In your conn.log there are several fields that represent the data you're looking for. orig_bytes, resp_bytes These are payload bytes for data sent by the originator and responder. orig_ip_bytes, resp_ip_bytes These are byte counts including the IP header. If you are looking for the total amount of data being sent across your border to the "internet", then this is likely the measurement you want. These fields available several ways, one easy way that is a nice analog to log processing is to access it through the logging framework event as the data is being logged. event Conn::log_conn(rec: Conn::Info) { print rec$orig_ip_bytes + rec$resp_ip_bytes; } .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/

9 years, 4 months

[Bro] saving the binary information at pcap

by Oguz Yarimtepe

Hi, I set the default_extract variable as const default_extract = T &redef; at the contents.bro script to get the dat files including tcp reassembly contents. Is there a way at the Python binding side so that i can save the binaries as seperate files in the created files? The dat files include many responses. I can read the file and try to parse the content out of by looking at the orig file. But maybe there is a better way at the binding side Cheers. -- Oguz Yarimtepe <oguzyarimtepe(a)gmail.com> http://about.me/oguzy

9 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

zeek May 2012