#478: Move BinPAC docs over to new server
----------------------------+--------------------
Reporter: robin | Owner: seth
Type: Problem | Status: new
Priority: Normal | Milestone: Bro1.6
Component: Website / Wiki | Version:
Keywords: |
----------------------------+--------------------
There's some BinPAC documentation in the old Wiki that we should move
over.
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/478>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#660: Initializing a table with a record as an index does not work
--------------------+---------------------
Reporter: amannb | Type: Problem
Status: new | Priority: Normal
Milestone: | Component: Bro
Version: | Keywords:
--------------------+---------------------
The following code
{{{
type irecord: record {
resp_h: addr;
};
global my_table: table[irecord] of int = {
[[$resp_h=1.2.3.4]] = 12,
};
}}}
results in an error:
{{{
error in ./bug2.bro, line 7: illegal initializer ([[$resp_h=1.2.3.4]] =
12)
}}}
It probably should return an initialized table.
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/660>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#690: GTP de-tunneling
------------------------+---------------------
Reporter: robin | Type: Problem
Status: new | Priority: Normal
Milestone: 2.1 | Component: Bro
Version: git/master |
------------------------+---------------------
----- Forwarded message from "Langer, Carsten (NSN - DE/Duesseldorf)"
-----
From: "Langer, Carsten (NSN - DE/Duesseldorf)"
[...]
I lately developed a GTP (GPRS Tunneling Protocol) de-tunneling
functionality for bro-ids, which I want to share with you in the hope
that you might find it helpful.
[...]
Please find attached a patched version of the Sessions.cc, where from
line 601 to 701 I have introduced the de-GTP stuff. This is based on
bro-ids v1.5.3. I found that patching this one single location was
good enough for my purpose.
It works for me, however I could only test it against a couple of
network traces that I have, so if you are interested to re-use the
patch, please give it a try against other sets of data as well. I
added 3 weird-warnings (lines 614, 674, 691) if something goes wrong
within the patch, but haven't updated anything in the weird.bro
script.
[...]
As I'm not using the bro-ids for network security analysis but for
application performance analysis, [...] I did
not take any measures against recursive GTP tunnels.
----- End forwarded message -----
[attachment:"Sessions_patched_for_gtp-detunneling.cc"]
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/690>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#579: Syslog logging writer
---------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: Normal | Milestone: Bro1.7
Component: Bro | Version: git/master
Keywords: |
---------------------+------------------------
Martin has completely convinced me of the need for this. I don't know
about timeline we should put on it though. The one thought I have about
it is that it needs to use TCP due to extremely long lines that Bro logs
tend to have. I think it would be ok for it to have the same output
rendering that the LogAscii writer has.
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/579>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#584: DNS TXT record lookup bif
-----------------------------+--------------------
Reporter: seth | Owner:
Type: Feature Request | Status: new
Priority: Normal | Milestone: Bro1.7
Component: Bro | Version:
Keywords: |
-----------------------------+--------------------
We need a lookup_txt bif like the lookup_name and lookup_host bifs. It
would make two things possible:
1. Improved integration with Team Cymru's malware hash registry.
2. Integration with Google's Certificate Catalog to find "bad" certs.
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/584>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#634: CouchDB writer
-------------------------+-----------------------------
Reporter: jeff.baumes | Type: Feature Request
Status: new | Priority: Normal
Milestone: | Component: Bro
Version: | Keywords:
-------------------------+-----------------------------
Attached is a git patch for logging information to CouchDB. It has a new
dependence on libcurl which it searches for with a find_package CMake
command, and JsonCpp (MIT license), whose code is included directly in the
source tree.
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/634>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#578: Add ICMPv6 support to Bro
---------------------+------------------------
Reporter: gregor | Owner:
Type: Problem | Status: new
Priority: Normal | Milestone: Bro1.7
Component: Bro | Version: git/master
Keywords: IPv6 |
---------------------+------------------------
Bro currently does not handle ICMPv6 at all (one reason being that Bro
ignore IP protocol 58 which is ipv6-icmp)
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/578>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
#700: PacketSorter
-------------------------+--------------------
Reporter: gregor | Owner:
Type: Problem | Status: new
Priority: Normal | Milestone: Bro2.1
Component: Bro | Version:
Keywords: BroV6, IPv6 |
-------------------------+--------------------
(from an e-mail I sent a while ago)
Might relevant for IPv6 so setting milestone to 2.1
Hi,
I was wondering about Bro's packet sorter. From a quick glance it
appears that it's only enabled if packet_sort_window is set to a non
zero value. When enabled it will sort packets
a) based on timestamps and
b) for TCP packets based on SEQ/ACK numbers (I presume to ensure that
ACKs are delivered after the data packet)
Note, this is independent from Bro's ability to process multiple trace
files (or multiple interfaces) in order. So I was wondering about the
use cases for PacketSorter, especially (a)
If the packet sorter is enabled Bro's behavior will slightly change: It
won't pass ARP packets to the ARP analyzer, and it won't create a weird
if it's not an IP packet.
I was just wondering whether anybody has recently used the packet
sorter. If not I'm wondering whether we should test this code path to
see whether it works correctly esp wrt IPv6.
Or, actually, whether the packet sorter is worth keeping or whether we
should remove the code.
And another question would be if the TCP sorting would better be handled
by the TCP analyzer?
Opinions?
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/700>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker