[ https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.p… ]
Johanna Amann commented on BIT-1535:
------------------------------------
topic/johanna/bit-1535 updates the documentation of RSTR to "Responder sent a RST"
> conn.log conn_state field or documentation is wrong
> ---------------------------------------------------
>
> Key: BIT-1535
> URL: https://bro-tracker.atlassian.net/browse/BIT-1535
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: 2.4
> Reporter: Justin Azoff
> Assignee: Vern Paxson
>
> There is an issue where the conn.log conn_state field will contain RSTR, which according to the documentation means "Established, responder aborted."
> The problem that I notice is that I see log entries where conn_state is RSTR, but conn_history does not contain an 'h'. Additionally, the resp_h is absolutely not running a service on resp_p and the orig_h is usually in the process of a tcp scan.
> Here are the top frequencies of RSTR without an h over about a weeks worth of conn logs:
> {code}
> 38193 RSTR Fr
> 3662 RSTR DFr
> 1801 RSTR DFdrR
> 1248 RSTR DRr
> 432 RSTR DrF
> 232 RSTR Far
> 128 RSTR DdAFrR
> 79 RSTR DFadrR
> 64 RSTR DrR
> 58 RSTR DdAFarR
> {code}
> Compared to histories that did contain an h:
> {code}
> 425398 RSTR ShADadFr
> 204149 RSTR ShADadFrR
> 156303 RSTR ShADdFar
> 141795 RSTR ShADadFRRr
> 105704 RSTR ShADadfr
> 79697 RSTR ShADadr
> 63493 RSTR ShADaFr
> 51704 RSTR ShADadFrrrr
> 42075 RSTR ShADdar
> 37678 RSTR ShADadfRr
> {code}
> I don't have a pcap for this, but I believe many of the weird connections are related to scans or backscatter.
> I'm not sure if the code is wrong or the documentation is wrong, but I don't see how a fin+reset connection could be classified as established.
> Also, One thing that would be a nice documentation addition is the answer to this question:
> Given a conn.log entry, how do determine if there was a connection established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO RSTR', but RSTR is problematic...
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)
[ https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.p… ]
Johanna Amann updated BIT-1535:
-------------------------------
Status: Merge Request (was: Open)
Assignee: (was: Vern Paxson)
> conn.log conn_state field or documentation is wrong
> ---------------------------------------------------
>
> Key: BIT-1535
> URL: https://bro-tracker.atlassian.net/browse/BIT-1535
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: 2.4
> Reporter: Justin Azoff
>
> There is an issue where the conn.log conn_state field will contain RSTR, which according to the documentation means "Established, responder aborted."
> The problem that I notice is that I see log entries where conn_state is RSTR, but conn_history does not contain an 'h'. Additionally, the resp_h is absolutely not running a service on resp_p and the orig_h is usually in the process of a tcp scan.
> Here are the top frequencies of RSTR without an h over about a weeks worth of conn logs:
> {code}
> 38193 RSTR Fr
> 3662 RSTR DFr
> 1801 RSTR DFdrR
> 1248 RSTR DRr
> 432 RSTR DrF
> 232 RSTR Far
> 128 RSTR DdAFrR
> 79 RSTR DFadrR
> 64 RSTR DrR
> 58 RSTR DdAFarR
> {code}
> Compared to histories that did contain an h:
> {code}
> 425398 RSTR ShADadFr
> 204149 RSTR ShADadFrR
> 156303 RSTR ShADdFar
> 141795 RSTR ShADadFRRr
> 105704 RSTR ShADadfr
> 79697 RSTR ShADadr
> 63493 RSTR ShADaFr
> 51704 RSTR ShADadFrrrr
> 42075 RSTR ShADdar
> 37678 RSTR ShADadfRr
> {code}
> I don't have a pcap for this, but I believe many of the weird connections are related to scans or backscatter.
> I'm not sure if the code is wrong or the documentation is wrong, but I don't see how a fin+reset connection could be classified as established.
> Also, One thing that would be a nice documentation addition is the answer to this question:
> Given a conn.log entry, how do determine if there was a connection established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO RSTR', but RSTR is problematic...
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)
[ https://bro-tracker.atlassian.net/browse/BIT-1539?page=com.atlassian.jira.p… ]
Johanna Amann updated BIT-1539:
-------------------------------
Resolution: Solved
Status: Closed (was: Open)
Since there was no further comment on this, I assumed that solved your problem.
Feel free to re-open if you still think there is anything wrong in Bro.
> Adding intel to intel framework Bro is not loading the file
> -----------------------------------------------------------
>
> Key: BIT-1539
> URL: https://bro-tracker.atlassian.net/browse/BIT-1539
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: 2.4
> Environment: CentOS 7.2. 1511 kernel version 3.10
> Reporter: Lu Goon
> Labels: Framework, IP, Intel, addresses, data, files, text
>
> We wanted to get our intel ( bad IPs) in to bro for alerting using the intel framework. I crafted a file of BAD IPs based on the documentation on the site. Also based this on the critical stack implementation as well.
> I provided the following fields: indicator, indicator_type, meta.source, meta.desc, meta.do_notice.
> thus a sample entry would be
> 1.2.3.4 \t Intel::ADDR \t MY INTEL \t My bad IP list \t F
> Per the documentation it should write all that into the intel.log file if activated in the local.bro file
> either using broctl or bro -i ens33 local.bro. There is no indication in loaded scripts that the files loads.
> Also in my local.bro file I include.
> @load policy/frameworks/intel/seen
> @load policy/frameworks/intel/do_notice
> redef Intel::read_files += { "/usr/local/bro/upload/intel.dat"};
> Any help on debugging why this file is not loading or indication of if it is loaded?
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)
[ https://bro-tracker.atlassian.net/browse/BIT-1529?page=com.atlassian.jira.p… ]
Johanna Amann updated BIT-1529:
-------------------------------
Status: Merge Request (was: Open)
> Base SIP scripts missing SUBSCRIBE and NOTIFY
> ---------------------------------------------
>
> Key: BIT-1529
> URL: https://bro-tracker.atlassian.net/browse/BIT-1529
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master
> Reporter: Seth Hall
> Fix For: 2.5
>
>
> The base/protocols/sip/main.bro script has a set in `sip_methods` which needs to have SUBSCRIBE and NOTIFY added. They're defined in RFC 3265.
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)
[ https://bro-tracker.atlassian.net/browse/BIT-1529?page=com.atlassian.jira.p… ]
Johanna Amann commented on BIT-1529:
------------------------------------
I added subscribe in topic/johanna/bit-1529. Notify was already added in 4a56a17817fc4eed2a3a6c10ecb5140df4f2dfc5
No tests since I don't have traffic (but since this is only used to generate weirds, it should be ok).
> Base SIP scripts missing SUBSCRIBE and NOTIFY
> ---------------------------------------------
>
> Key: BIT-1529
> URL: https://bro-tracker.atlassian.net/browse/BIT-1529
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master
> Reporter: Seth Hall
> Fix For: 2.5
>
>
> The base/protocols/sip/main.bro script has a set in `sip_methods` which needs to have SUBSCRIBE and NOTIFY added. They're defined in RFC 3265.
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)
[ https://bro-tracker.atlassian.net/browse/BIT-1540?page=com.atlassian.jira.p… ]
Jon Schipp reassigned BIT-1540:
-------------------------------
Assignee: Jon Schipp
> Ifconfig is hardcoded in BroControl
> -----------------------------------
>
> Key: BIT-1540
> URL: https://bro-tracker.atlassian.net/browse/BIT-1540
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: BroControl
> Affects Versions: git/master
> Reporter: Johanna Amann
> Assignee: Jon Schipp
> Fix For: 2.5
>
>
> From the mailing list:
> {quote}
> Hi Folks,
> On later versions of Linux distros iproute2 replaces ifconfig with ip
> Starting at line 601 at
> https://github.com/bro/broctl/blob/master/BroControl/config.py
> It looks like ifconfig is hard-written into the logic. Probably needs a
> patch to check for the ip command.
> Cheers,
> Harry
> {quote}
> We should probably check for the presence of the ip utility and use that, if present.
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)
Aaron Eppert created BIT-1541:
---------------------------------
Summary: Crash in SocketComm::Run - RemoteSerializer.cc:3493
Key: BIT-1541
URL: https://bro-tracker.atlassian.net/browse/BIT-1541
Project: Bro Issue Tracker
Issue Type: Problem
Components: Bro
Affects Versions: 2.4
Reporter: Aaron Eppert
This has been happening on a few sensors, both standalone and not. On each sensor, there is broctl cron running as well as periodic polling being the Python interface to the netstats data.
{quote}#0 0x0000000000607d47 in SocketComm::Run (this=0x1) at /mnt/hgfs/src/psdev/bro/src/RemoteSerializer.cc:3493
#1 0x0000000000608021 in RemoteSerializer::Fork (this=0x2590000)
at /mnt/hgfs/src/psdev/bro/src/RemoteSerializer.cc:687
#2 0x000000000060813f in RemoteSerializer::Enable (this=0x2590000)
at /mnt/hgfs/src/psdev/bro/src/RemoteSerializer.cc:575
#3 0x00000000005d52b3 in BifFunc::bro_enable_communication (frame=<optimized out>, BiF_ARGS=<optimized out>)
at bro.bif:4480
#4 0x00000000005d2cdd in BuiltinFunc::Call (this=0x2ae1180, args=0x16255be0, parent=0x4ada990)
at /mnt/hgfs/src/psdev/bro/src/Func.cc:586
#5 0x00000000005b7af6 in CallExpr::Eval (this=0x315e900, f=0x4ada990)
at /mnt/hgfs/src/psdev/bro/src/Expr.cc:4544
#6 0x000000000062b8d4 in ExprStmt::Exec (this=0x315e8b0, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT)
at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:352
#7 0x0000000000629b94 in IfStmt::DoExec (this=0x31533c0, f=0x4ada990, v=<optimized out>,
flow=@0x7ffe64462c50: FLOW_NEXT) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:456
#8 0x000000000062b8f1 in ExprStmt::Exec (this=0x31533c0, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT)
at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:356
#9 0x0000000000629c31 in StmtList::Exec (this=0x31534e0, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT)
at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1696
#10 0x0000000000629c31 in StmtList::Exec (this=0x3153120, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT)
at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1696
#11 0x00000000005decfe in BroFunc::Call (this=0x2743b80, args=<optimized out>, parent=0x0)
at /mnt/hgfs/src/psdev/bro/src/Func.cc:403
#12 0x000000000059d95a in EventHandler::Call (this=0x2476c80, vl=0x15db0b60, no_remote=no_remote@entry=false)
at /mnt/hgfs/src/psdev/bro/src/EventHandler.cc:130
#13 0x000000000059cb65 in Dispatch (no_remote=false, this=0x16193120) at /mnt/hgfs/src/psdev/bro/src/Event.h:50
#14 EventMgr::Dispatch (this=this@entry=0xc07840 <mgr>) at /mnt/hgfs/src/psdev/bro/src/Event.cc:111
#15 0x000000000059cd00 in EventMgr::Drain (this=0xc07840 <mgr>) at /mnt/hgfs/src/psdev/bro/src/Event.cc:128
#16 0x000000000054c659 in main (argc=<optimized out>, argv=<optimized out>)
at /mnt/hgfs/src/psdev/bro/src/main.cc:1147
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-010#72000)