Kevin P. Fleming wrote:
I'm sorry it took me so long to get back to this thread... there have been many
good points raised and I'm happy to see that the general sense in the community
is along the same lines as my original thinking :-)
The issue that started this discussion is NOT an extreme volume of proper/valid
signaling; instead, it is properly-formatted but otherwise bogus signaling that
Asterisk has to respond to because the RFCs require it (in general). There is
some evidence that if you send enough of this stuff at Asterisk, it will start
to drop calls and otherwise behave badly.
While we can do some work to try to make this have less drastic side effects,
there are always going to be limits to how much traffic we can handle before
falling over. If we can improve the code to handle 100 packets per second, is
that really an improvement since the attacker can just send 200 packets per
second instead?
It seems that maybe the best proposal at this time is to just provide a method
for counting the number of improper/bogus signaling packets received in a given
time frame (per second, per minute, etc.) and then dropping (without response)
any signaling that is not known to be valid beyond that limit.
Would it be a large load on the system to "count the number of
improper/bogus signaling packets received in a given time frame" by
souce IP address, and then dropping (without response) any signaling.
Notice I inserted "by source IP address" into your statement. Its not a
lot different then what some firewalls do.
Even if someone tried a DDoS, the above would catch it and reduce the
load on the asterisk box.
I'd suggest making two important tunable parameters accessible from some
conf file though;
1. number of improper/bogus signaling packet threshold
2. amount of time before clearing the able
Something like... after 10 bogus attempts, add the IP address in the
table and stop responding. Then after 60 seconds, clear that IP address
from the table (and start over).
Obviously, it would be nice to see some sort of log entry that indicated
the above action was taken.
Rich
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
