Greetings.
Does bro detect SSH brute force login attempts?
I saw that there was ssh and ssh-stepping policies, and they do not seem to be
looking for any kind of brute force detection, but I wanted to ask the group
about this.
Thanks for the reply,
Thomas
My ssh-ext.bro script at the following link does, but it could certainly be improved.
http://github.com/sethhall/bro_scripts/tree/master
.Seth
Thanks for the info, Seth
Can you point me to any info/document/link that you may have used for
your approach.
for e.g. about how you set
authentication_data_size = 5500
I am trying to understand how a brute force attempt can be
distinguished from a normal
client server communication since both are encrypted?
It heuristically makes a guess about a successful login based on the amount of data returned from the server (the default is 5k). It's far from 100% accurate, but in my environment has been extremely useful. Recently, I've been looking through some SSH traces trying to find a more refined heuristic because if someone logs in and then logs out again right away, it's likely the server will cross the byte count threshold and a successful connection will be marked as unsuccessful. If you have any ideas for how to make that happen, I'd be glad to hear.
.Seth
Oops, make that "...will *not* cross the byte count..."
.Seth
The worker node is on an amd system with 4 cores running linux, it is just a starter system made from spare part and will be expanded at some future date to a full bro cluster with maniple work machines. It has two dual port 10 GigE interfaces.
Here are few thing that I think need a little work in the bro cluster setup.
* The interface definition needs to allow multiple interfaces to be specified. In my the output of a tap is feed in a dual port 10 GigE card so I have to have bro read from two network interfaces. Right now you can work around the problem by just adding -I <second interface> on the node interface configuration line but I think it deserves a more formal solution.
* One of my 10 GigE circuits has 3 vlans on it which show up as 6 interfaces. With the non cluster version of bro I just ran with 3 different configuration files and kept logs and reports in three separate directories. One important side affect was that it allowed 3 separate instances of bro so that the system could spread the load across multiple cpus instead of one. With bro cluster I could not run 3 bro works on one machine due to the way the works and server talk to each other. I think it would be an important enhancements to bro cluster to allow multiple bro work instances on the same machine.
Bill Jones
* The interface definition needs to allow multiple interfaces to be specified. In my the output of a tap is feed in a dual port 10 GigE card so I have to have bro read from two network interfaces. Right now you can work around the problem by just adding -I <second > on the node interface configuration line but I think it deserves a more formal solution.
I've thought about asking Robin to add this feature too, but it's probably better to bind your interfaces together at a lower level. The easy way of doing it is to create a bridge and bind all of the interfaces you want to sniff attached to the bridge. Then you only need to define a single interface in your Bro configuration. You could also do it with the netgraph subsystem FreeBSD too, but that's a bit more complicated.
* One of my 10 GigE circuits has 3 vlans on it which show up as 6 interfaces. With the non cluster version of bro I just ran with 3 different configuration files and kept logs and reports in three separate directories. One important side affect was that it allowed 3 separate instances of bro so that the system could spread the load across multiple cpus instead of one. With bro cluster I could not run 3 bro works on one machine due to the way the works and server talk to each other. I think it would be an important enhancements to bro cluster to allow multiple bro work instances on the same machine.
That already works. In your node.cfg file, you just need to define multiple workers and give them the same host option, but give them each their own interface to sniff. I'm using this on my cluster now to help make better use of the available cores until the multi-core work is functional.
.Seth
Thanks your node configuration suggestion did work. I am not sure what my earlier problem was, probably just an a typo.
Bill Jones
Found my earlier problem. If a name the works "work1,work2,..,worknn" the node configuration works. If I name the works "I2,NLR and internet" I run into my communication problem.
Bill Jones
Interesting. If you can make it break reliably, please file a ticket at http://tracker.icir.org/bro
Thanks!
.Seth
* The interface definition needs to allow multiple interfaces to be
specified. I
There's already a feature request filed for this in the tracker. I'm
planning to add it soon.
With bro cluster I could not run 3 bro works on one machine due to the way the works and server talk to each other.
As Seth already wrote, this is supposed to work. Please file a
ticket with the details of the effect you're seeing.
Robin