On 27 Sep 2006, at 00:06, Steven wrote:
On Tue, 2006-09-26 at 17:02 -0500, Jason Parker wrote:
----- Kevin P. Fleming <[EMAIL PROTECTED]> wrote:
A community member has communicated to me a couple of issues
where if
he sends large volumes of correctly-formatted (but otherwise
invalid)
packets at Asterisk channel drivers, Asterisk behaves quite
poorly. In
general it does not crash, but it will lose calls, respond very
slowly, etc.
I have been loath to start trying to build remediation for this into
Asterisk itself, since that's a very slippery slope and we could end
up spending the next six months trying to come up with new attack
vectors and then coding to deal with them. In addition, at least
in my
opinion, there are good, free tools already to do this sort of thing
(rate limiting of incoming traffic), as well as solid commercial
products.
However, I'd like to get the opinions of our developer
community... do
you think this is something we should attempt to address within
Asterisk itself, or we are better off to post some 'best practices'
documents that demonstrate ways that existing tools can be used to
combat these attacks?
Let's look at other apps (say, apache) for an example of something
similar. What happens if you throw thousands of requests at apache
per second? It's going to die. And why shouldn't it? Stuff like
this, in my opinion, is best handled at the firewall level, or
perhaps
with a load balancer of sorts. Sure, we can (and definitely should)
continue to improve, so that we can *PROPERLY* handle higher call
volumes, but in this case, what happens if they just resort to a good
old packet flood?
No, apache won't die. Apache will stop answering new requests till a
child process is able to process the request. From the outside it
might
look like apache has died as it is possible that the DOS is
continually
eating the children's time, but apache is trying it's best to keep
above
water by not answering anymore than it was configured to.
So I guess if you want to use apache as an example, should we set
up the
VoIP channels to have a max possible channels in use? Doesn't seem
like
it would be wise with non call related messaging still being
attackable.
Even with an external app making sure no one host is sending too many
packets, how many hosts would it take to generate enough packets to
still get the same effect?
--
Steven <[EMAIL PROTECTED]>
What's more apache has an optional module
(mod_dos ?) which applies some extra defensive strategies
when it thinks it is being dos'd. We had to enable this on
a server for a customer a while back.
In general I think these things should be handled at the
layer that has the most ability to deal with that class of attack.
So routers and firewalls should deal with spoofed and malformed
packets. Gateway devices should deal with filtering
'untrusted/unpermitted' (but otherwise valid) requests and
core systems should deal with fine-grain permission/resource
allocation.
Asterisk is a 'core system' but some of us also use it as a gateway
device too.
I'd guess that means that we could/should look at adding some
(optional) defensive code to do request filtering.
Tim Panton
www.mexuar.com
_______________________________________________
--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
