Hello,
I have a question regarding how the connections are created in conn.log.
I thought that the combination tuple o (src_ip, src_port, dest_ip, dest_port)was used to define one connection but this is not the case.
The first connection is the one that establishes the ssl connection and the other 5 are identified as OTH which is No SYN seen, just midstream traffic (a “partial connection” that was not later closed).
Are they not all included in the same connection because bro did not identify the ssl connection closing? If so, does this mean that bro considers a flow as a unique connection if there is a problem protocol beggining and ending?
Kind Regards,
Michael
Hello bro community,
are all connection attempts recorded in conn.log? Let us assume I am monitoring interface eth0, will I see every connection in this log file …
- …independent of the transport layer protocol (udp,tcp,mptcp…) and its properties (ports)
- …independent of firewalls like iptables blocking incoming packets on eth0
- …independent of firewalls like iptables forwarding incoming packets on eth0 to special targets like NFQUEUE and libnetfilter_queue
Regards, Marcin
Hello,
I have a question regarding how the connections are created in conn.log.
I thought that the combination tuple o (src_ip, src_port, dest_ip,
dest_port)was used to define one connection but this is not the case.
It generally kind of should be the case (with certain gotchas).
Connections are only held in memory for a certain amount of time (so you
can get the same 5-tuple after a period of time passes; the period of time
depends on the packets that were seen and on the protocol and can be as
low as a few seconds and as high as a few hours).
In addition, if you are running a Bro cluster, each worker node logs
connections separately.
The first connection is the one that establishes the ssl connection and the
other 5 are identified as *OTH *which is No *SYN seen, just midstream
traffic (a “partial connection” that was not later closed).*
Is this a long-lived connection? Is there a chance that a few minutes
passed without any data inbetween? That would cause Bro to flush out the
connection, forget about it, and then recognize the following packets as a
new connection.
The second possibility is that you have a cluster and that packet
distribution is somehow misconfigured.
That would be my ideas, I hope that helps,
Johanna
Hello bro community,
are all connection attempts recorded in conn.log? Let us assume I am
monitoring interface eth0, will I see every connection in this log file ...
* ...independent of the transport layer protocol (udp,tcp,mptcp...) and
its properties (ports)
Kind of. The underlying transport protocol has to be supported by Bro, so
you are limited to udp and tcp.
* ...independent of firewalls like iptables blocking incoming packets on
eth0
Bro will log information about the packets that are delivered to it.
Hence, this depends on your system configuration; if you use a mechanism
that delivers packets to Bro even if iptables has block rules on the
interface, yes; if no then no. That being said, I think that iptables
rules are generally ignored in promiscuous mode.
* ...independent of firewalls like iptables forwarding incoming packets on
eth0 to special targets like NFQUEUE and libnetfilter_queue
Same answer as to the last question - Bro sees whatever libpcap (or
whatever packet source you use) feeds to it.
I hope this helps,
Johanna