[Bro] Triplicate Entries in CONN Log
Seth Hall
seth at corelight.com
Wed Jan 3 08:58:56 PST 2018
Your node.cfg is slightly complicated since you're sniffing a number of
interfaces. I wouldn't be surprised if you're accidentally seeing the
same traffic on multiple interfaces. Add this little blurb into your
local.bro...
#### begin ####
@load base/protocols/conn
export {
redef record Conn::Info += {
## The name of the node where this connection was analyzed.
node: string &log &optional;
};
}
event connection_state_remove(c: connection) &priority=2
{
c$conn$node = peer_description;
}
#### end ####
That will let you see which node each of your conn log entries was being
written by. Look at three of the same connections to see if they're
coming from different workers and let us know.
.Seth
On 2 Jan 2018, at 14:39, Philip Romero wrote:
> All,
>
> I did a quick search, but did not see any threads on this type of
> subject, so forgive me if this has already been discussed. We have a
> new
> bro server being stood up that looks to be creating multiple (3)
> entries
> for every conn log. Below is a sample of what I'm speaking of. We have
> 4
> monitoring interfaces with varying numbers of CPU cores assigned to
> the
> 4 workers they are associated with. The number of entries appears to
> be
> related to the number pf_ring workers created because I changed the
> nodes from 3 lb_procs each to the below node.cfg config this morning
> and
> I am now seeing 1 to 5 entries for each log entry.
>
> Would this be an indication that there is a problem with our pf_ring
> setup? How might we confirm what may be causing this?
>
> $ zcat /usr/local/logs/2018-01-01/conn.01\:00\:00-02\:00\:00.log.gz
> |bro-cut -d |grep '101.124.88.146'
> 2018-01-01T01:16:50-0800 CxcveSg78Iow3jix
> 101.124.88.146
> 33589 137.164.29.67 53 udp dns
> 0.000383 44 162
> SF F T 0 Dd 72 1 190
> (empty)
> 2018-01-01T01:16:50-0800 CbvYq642taiDEEPLwc
> 101.124.88.146
> 33589 137.164.29.67 53 udp dns
> 0.000383 44 162
> SF F T 0 Dd 72 1 190
> (empty)
> 2018-01-01T01:16:50-0800 CEc8UA2AyEKYDSNiw9
> 101.124.88.146
> 33589 137.164.29.67 53 udp dns
> 0.000383 44 162
> SF F T 0 Dd 72 1 190
> (empty)
> 2018-01-01T01:17:44-0800 Clg6KI2hLQBShRUxal
> 101.124.88.146
> 54683 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 72 0 0 (empty)
> 2018-01-01T01:17:44-0800 CN1WXh1ae3r9FzXA7d
> 101.124.88.146
> 54683 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 72 0 0 (empty)
> 2018-01-01T01:17:44-0800 C7s9Qp4LPByzC6Gm53
> 101.124.88.146
> 16779 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 82 0 0 (empty)
> 2018-01-01T01:17:44-0800 CHBMNSB9eOhekrAS6
> 101.124.88.146
> 54683 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 72 0 0 (empty)
> 2018-01-01T01:17:44-0800 Cmnrmh2ivDksWcJXLl
> 101.124.88.146
> 16779 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 82 0 0 (empty)
> 2018-01-01T01:17:44-0800 CTCK4qkRHhDz4jLqk
> 101.124.88.146
> 16779 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 82 0 0 (empty)
> 2018-01-01T01:17:45-0800 CZ90QS3RGjHqck8zvc
> 101.124.88.146
> 26774 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 82 0 0 (empty)
> 2018-01-01T01:17:45-0800 C96L6a1YTuUCsvbHRk
> 101.124.88.146
> 26774 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 82 0 0 (empty)
> 2018-01-01T01:17:45-0800 CnP2AnwrmyniFfDBe
> 101.124.88.146
> 26774 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 82 0 0 (empty)
> 2018-01-01T01:17:46-0800 CB5iF7f4hoqrQWiq2
> 101.124.88.146
> 25389 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 72 0 0 (empty)
> 2018-01-01T01:17:46-0800 CkZEAp0saM0cEaTSf
> 101.124.88.146
> 25389 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 72 0 0 (empty)
> 2018-01-01T01:17:46-0800 CQx4sVzjmGlPnAa51
> 101.124.88.146
> 25389 137.145.204.10 53 udp dns -
> - - S0 F
> F 0 D 1 72 0 0 (empty)
>
> $ cat /usr/local/etc/node.cfg
> # Example BroControl node configuration.
> #
> # This example has a standalone node ready to go except for possibly
> changing
> # the sniffing interface.
>
> # This is a complete standalone configuration. Most likely you will
> # only need to change the interface.
>
> #[bro]
> #type=standalone
> #host=localhost
> #interface=ens2f0
>
> ## Below is an example clustered configuration. If you use this,
> ## remove the [bro] node above.
>
> #[logger]
> #type=logger
> #host=localhost
> #
> [manager]
> type=manager
> host=localhost
> #
> [proxy-1]
> type=proxy
> host=localhost
> #
> [worker-1]
> lb_method=pf_ring
> lb_procs=1
> #pin_cpus=2,3
> type=worker
> host=localhost
> interface=ens2f0
> #
> [worker-2]
> lb_method=pf_ring
> lb_procs=2
> #pin_cpus=4,5
> type=worker
> host=localhost
> interface=ens2f1
> #
> [worker-3]
> lb_method=pf_ring
> lb_procs=4
> #pin_cpus=2,3
> type=worker
> host=localhost
> interface=ens2f2
> #
> [worker-4]
> lb_method=pf_ring
> lb_procs=5
> #pin_cpus=4,5
> type=worker
> host=localhost
> interface=eno2
>
> --
> Philip Romero, CISSP, CISA
> Sr. Information Security Analyst
> CENIC
> promero at cenic.org
> Phone: (714) 220-3430
> Mobile: (562) 237-9290
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
--
Seth Hall * Corelight, Inc * www.corelight.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180103/ca151352/attachment.html
More information about the Bro
mailing list