The Direction type (defined in base/utils/directions-and-hosts.bro)
currently has directions for:
- remote orig, local resp
- local orig, remote resp
- bidirectional ("Only one endpoint is within the locally-monitored
network, meaning the connection is either outbound or inbound.")
- no_direction ("This value doesn't match any connection.")
Does it make sense to add LOCAL == local orig, local resp? Similarly, do we
want to add EXTERNAL == remote orig, remote resp?
I'm looking at this for the SSH log in particular.
--Vlad
[ https://bro-tracker.atlassian.net/browse/BIT-1231?page=com.atlassian.jira.p… ]
hui updated BIT-1231:
---------------------
Status: Merge Request (was: Open)
> DNP3 Analyzer Supports for DNP3-over-UDP
> ----------------------------------------
>
> Key: BIT-1231
> URL: https://bro-tracker.atlassian.net/browse/BIT-1231
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Affects Versions: 2.3
> Reporter: hui
> Assignee: hui
> Labels: DNP3, analyzer
>
> Two major changes are made for the DNP3 analyzer
> 1. Make the analyzer support both the DNP3-over-UDP and the DNP3-over-TCP.
> The changes are made in DNP3.cc, DNP3.h and dpd.sig
> 2. Fix a bug in the binpac codes of the DNP3 analyzer
> The changes are made in dnp3-protocol.pac. The changes results in different baseline results of testing/btest/Baseline/scripts.base.protocols.dnp3.dnp3_link_only
>
--
This message was sent by Atlassian JIRA
(v6.4-OD-04-006#64001)
[ https://bro-tracker.atlassian.net/browse/BIT-1231?page=com.atlassian.jira.p… ]
hui commented on BIT-1231:
--------------------------
I define a base class for both tcp and udp analyzer and include all the repeated codes there. In order to call the functions defined in analyzer::Analyzer (such as Weird), I just pass the this pointer back to this base class.
At the same time, I fix a bug found in the DNP3.cc.
All these changes do not introduce different test baseline results.
> DNP3 Analyzer Supports for DNP3-over-UDP
> ----------------------------------------
>
> Key: BIT-1231
> URL: https://bro-tracker.atlassian.net/browse/BIT-1231
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Affects Versions: 2.3
> Reporter: hui
> Assignee: hui
> Labels: DNP3, analyzer
>
> Two major changes are made for the DNP3 analyzer
> 1. Make the analyzer support both the DNP3-over-UDP and the DNP3-over-TCP.
> The changes are made in DNP3.cc, DNP3.h and dpd.sig
> 2. Fix a bug in the binpac codes of the DNP3 analyzer
> The changes are made in dnp3-protocol.pac. The changes results in different baseline results of testing/btest/Baseline/scripts.base.protocols.dnp3.dnp3_link_only
>
--
This message was sent by Atlassian JIRA
(v6.4-OD-04-006#64001)
[ https://bro-tracker.atlassian.net/browse/BIT-1237?page=com.atlassian.jira.p… ]
Jon Siwek commented on BIT-1237:
--------------------------------
Thanks. It is a bit of a quirk of the parser -- it expects no statement to precede a declaration (at the global scope). In this case, the function definition and redef are types of declarations while locals are considered statements. For now, maybe a habit to pick up in order to avoid the situation is only using locals inside functions/events.
> Bro script declaration ordering
> -------------------------------
>
> Key: BIT-1237
> URL: https://bro-tracker.atlassian.net/browse/BIT-1237
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: 2.3
> Environment: Bro con training VM
> Reporter: Peter Kaloroumakis
> Priority: Trivial
> Labels: BroScript
>
> During one of the scripting exercises I noticed odd behavior with items declared in the global scope:
> ############################# error.bro
> not working:
> ------------------------------------------------
> local test_var = "test_var";
> function test_1()
> {
> print "test_1";
> }
> print test_var;
> test_1();
> >>> Output:
> error in ./test.bro, line 3: syntax error, at or near "test_1"
> ############################# working.bro
> working:
> ------------------------------------------------
> function test_1()
> {
> print "test_1";
> }
> local test_var = "test_var";
> print test_var;
> test_1();
> >>> Output:
> test_var
> test_1
> #############################
> To declare a function, bro 2.3 forced me to do it at the top of the file. On the exercise with the redef of the grid ftp size variable I noticed the same issue with redef, it required me to put the redef at the very top of the file.
> Robin asked me to open a ticket and mentioned this was low priority.
--
This message was sent by Atlassian JIRA
(v6.4-OD-04-006#64001)
[ https://bro-tracker.atlassian.net/browse/BIT-1235?page=com.atlassian.jira.p… ]
Brian O'Berry commented on BIT-1235:
------------------------------------
I ran your topic branch and got perfect results! We have more testing to do and will update this if we see any issues over the next couple weeks. I went for the quick fix and didn't think of SetCRLFAsEOL(0), but it's clear I need to learn the analyzer parent/child processing flow to help in this area. Thanks very much for the fast response, and I'll keep you posted!
> HTTP multipart POST request alters file contents
> ------------------------------------------------
>
> Key: BIT-1235
> URL: https://bro-tracker.atlassian.net/browse/BIT-1235
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: 2.3
> Environment: CentOS 6.5, file extract analyzer
> Reporter: Brian O'Berry
> Fix For: 2.4
>
> Attachments: bro-2.3-HTTP.patch, gdb.log, upload-api-http.pcap
>
>
> HTTP POST multipart processing converts bare CR or LF chars to CRLF pairs, corrupting most files when extracted with Files::ANALYZER_EXTRACT. This is clear in the attached gdb.log, which has a backtrace that shows a buffer with the start of a PDF file entering MIME/HTTP entity processing at frame 25, and emerging with LF chars converted to CRLF at frame 6.
> Also attached are the pcap file associated with the backtrace, and an initial patch that we've barely begun to test. A point of concern with the patch is that it changes a weird.log entry from "line_terminated_with_single_CR" to "http_no_crlf_in_header_list". It does enable Files::ANALYZER_EXTRACT to correctly extract the PDF file from the attached pcap.
> Please let me know if we can provide anything else to help with this.
--
This message was sent by Atlassian JIRA
(v6.4-OD-04-006#64001)
Peter Kaloroumakis created BIT-1237:
---------------------------------------
Summary: Bro script declaration ordering
Key: BIT-1237
URL: https://bro-tracker.atlassian.net/browse/BIT-1237
Project: Bro Issue Tracker
Issue Type: Problem
Components: Bro
Affects Versions: 2.3
Environment: Bro con training VM
Reporter: Peter Kaloroumakis
Priority: Trivial
During one of the scripting exercises I noticed odd behavior with items declared in the global scope:
############################# error.bro
not working:
------------------------------------------------
local test_var = "test_var";
function test_1()
{
print "test_1";
}
print test_var;
test_1();
>>> Output:
error in ./test.bro, line 3: syntax error, at or near "test_1"
############################# working.bro
working:
------------------------------------------------
function test_1()
{
print "test_1";
}
local test_var = "test_var";
print test_var;
test_1();
>>> Output:
test_var
test_1
#############################
To declare a function, bro 2.3 forced me to do it at the top of the file. On the exercise with the redef of the grid ftp size variable I noticed the same issue with redef, it required me to put the redef at the very top of the file.
Robin asked me to open a ticket and mentioned this was low priority.
--
This message was sent by Atlassian JIRA
(v6.4-OD-04-006#64001)
[ https://bro-tracker.atlassian.net/browse/BIT-1236?page=com.atlassian.jira.p… ]
Jon Siwek updated BIT-1236:
---------------------------
Assignee: (was: Robin Sommer)
> topic/jsiwek/flip-on-syn-ack
> ----------------------------
>
> Key: BIT-1236
> URL: https://bro-tracker.atlassian.net/browse/BIT-1236
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Affects Versions: git/master
> Reporter: Jon Siwek
>
> This branch is in bro and bro-testing-private.
> The goal is the same as https://github.com/bro/bro/pull/11, but I have it flip roles at an even earlier point in the code path or else I notice some inconsistencies in things like connection history strings or the connsize analyzer counters (which were probably also issues w/ the old flipping method).
--
This message was sent by Atlassian JIRA
(v6.4-OD-04-006#64001)