Hello.
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.
Bro has analyzers for DNS/SNMP/NTP. A few months ago it was monlist it NTP, someone might come up with something else another day.
I think it might be a good use of a SumStat framework. 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 keys.
Also, I don’t mind when a single client sends me 100 requests and gets 150 packets of answers, but I do if he sends 1 packet and gets 10 in return every time.
Quite a field for false positives here.
Any ideas how to correlate it?
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?
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?
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 keys.
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.
.Seth
> 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
keys.
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.