[Bro] Bro and amplifications attacks
michalpurzynski1 at gmail.com
Mon Sep 15 09:17:57 PDT 2014
On Mon, Sep 15, 2014 at 3:24 PM, Seth Hall <seth at icir.org> wrote:
> On Sep 8, 2014, at 7:50 PM, Michał Purzyński <michalpurzynski1 at gmail.com>
> > Let's say I wanted to detect an amplification attack using DNS/SNMP/NTP.
> Kind of just in case the edge filters and careful configuration and
> scanning for vulnerabilities didn't catch everything.
> Generically detecting amplification attacks seems too broadly scoped to
> me. I'm not sure that I'd even know how to approach that in way that would
> work well. Do you have any more concrete ideas?
A ratio of data sent by me in response to a request I've got from a client
A. If one packet generates 10 and that's UDP we might have a problem.
That requires tracing a flow in progress, and that's not something I'm
brave enough to do.
> > I think it might be a good use of a SumStat framework.
> I know you've been playing with SumStats a bit recently, have you tried to
> tackle amplification attack detection?
I was thinking about the UDP events but they are per packet, and frankly
it's hard to change that, due to a very nature of the protocol. UDP session
done does not give me information about amount of the data transmitted,
unless I'm wrong?
> > The key would be a client who has number of packets towards him counted
> and expired early and frequently. I see a problem here - a large number of
> Regarding the large number of keys, that's already happening with
> scan.bro. Unfortunately I think it's mostly unavoidable but doesn't seem
> to cause too much trouble in practice. Although I can see it causing
> problems in certain circumstances.
Having all problematic protocols rate limited to <wontsayhowmuch> Mbit/sec
this might or might not be an issue that I would go for per packet
analysis, but I don't know if the side effects are worth the effort.
Still thinking about it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro