Jeff Geiger <jeff.geiger <at> gmail.com> writes:
I don't know if anything has changed in the last few years, but I know it
used to be the case that you could not put an AWS interface into promiscuous
mode. To get around this, you had to use a tool like daemonlogger to dump
packets from the external interface to a tap, tun, or bridge interface and
monitor that. For larger scale implementations, you can use openvpn
internally to route all the traffic back to your sensor. I set up a PoC
doing similar with Snort a few years back.
(https://github.com/jeffgeiger/CloudSnort) Hopefully that helps, if this is
still the case.
On Thu, Apr 7, 2016 at 6:04 PM, Mike Dopheide <dopheide <at> gmail.com>
wrote:I want to say that's likely because AWS disables promiscuous mode so
getting Bro to work requires some additional tricks. Can anyone verify?
I have a Bro cluster setup in the AWS cloud, currently just with one node.
My problem is that Bro is not producing the notice.log, it should just log
successful SSH logins but it doesn't. I have tried SSH and FTP bruteforcing
the worker node and exceeding the limit of failed connections, again no
notice.log. I can see the detect-bruteforcing.bro scripts loaded in the
loaded_scripts.log. I am pretty new to Bro, so I am not sure what I am doing
Bro mailing listbro <at>
Bro mailing list
bro <at> bro-ids.org
So lets say I bridge an interface and start to monitor br0 instead of eth0,
the br0 interface will not be in promiscuous mode and will allow to produce
the notice.log? I am asking because you said you have done it few years ago,
therefore wondering whether anything has changed in AWS.
I still can't understand it why is it not producing the notice.log. I have
all the other logs (conn, http, ssl, x509 etc) and they are working fine. I
am not sure how Bro exactly works but if there is more than 30 rejected FTP
requests in the conn.log why doesn't it raise a notice if that's what the
FTP-bruteforce is looking for.